Are you designing for people or the system shaping them? (Q&A)

Today we’re digging into an article by @Nikhil_Mahen], Systems Thinking vs Design Thinking — a spectrum misunderstood. He lays out how design thinking and systems thinking differ in perspective and intent, and why understanding those differences matters when choosing an approach.

Design thinking starts with people. It breaks problems into parts like needs, behaviors, motivations, and pain points. The goal is to understand humans deeply and design around that understanding.

Systems thinking steps back. It looks at the whole system rather than individual parts. It focuses on how elements interact, how value moves through the system, and how feedback loops create patterns over time. Instead of asking what one person needs, it asks how the system behaves and what makes it stable or unstable.

You suggest these approaches work differently depending on the problem you are solving with your team.

  • Design thinking works best when you are focused on user experience, behavior change, or improving outcomes for specific groups. It is human-centered and zooms in.

  • Systems thinking fits problems with many moving parts, where causes and effects are hard to trace. It is ecosystem-centered and zooms out to see relationships, patterns, and dynamics.

Let’s jump into the discussion

Most real work does not live in just one of these modes. Teams borrow from both, often without naming it. With AI reshaping how products are built, how decisions are made, and how teams collaborate, I’m excited to dive into how we approach problems today.

So here’s the question I want to open up: as the complexity of the problems we are solving keeps rising, how should our thinking change?

Looking forward to digging into this with Nikhil Mahen, a thoughtful contributor to the forum who brings a sharp perspective on AI, systems, and design.

2 Likes

Great to be with you in this discussion Nikhil! I’d love to set some context for people.

Design thinking is a well-known concept, but its origins and evolution are less commonly understood.

Engineers primarily developed the methods that underpin design thinking as we know it today. David Kelley (my advisor and boss at Stanford) played a pivotal role in popularizing the term in the 1970s. He aimed to redefine the perception of designers, who were often seen merely as stylists brought in at the end of a process to enhance aesthetics. He made a very successful business from this idea.

However, the roots of design thinking extend further back. Pioneers like John Arnold from Stanford and James Webb Young laid the groundwork for this approach. Throughout the last century, the design field has experienced significant shifts, marked by various influences and changes in direction.

Much of early design thinking focused on shortening long product cycles by addressing human needs. User-centered design grew out of this, but it is more closely tied to systems thinking than most people realize. Its roots are grounded in engineering.

Let’s start with your interest in both topics. Why are these interesting to you in your work?

1 Like

Thanks a lot for having me Bryan.

I think the foundational bent of analysis is the philosophical approach to problem solving. Systems thinking and design thinking provide me those and I found both have relevance based on the problem you solve. That also means that they should not be used interchangeably. I think understanding this is critical when we try to map out value chains as the incentives which drive both differ greatly.

Why this interests me - i guess i like paradoxical or competing approaches and like to hold both of them in my head at the same time. thought admittedly my natural inkling is to approach from a systems thinking mindset but am better trained on the tactical elements of design.

2 Likes

Addressing your opening question second - complexity of problems is actually not rising as much in my opinion. I guess they are in the number of parameters but the approach to solving them remains largely unchanged in the last 200 or so years. I believe the large major change in the way we look at problem solving was inculcating analytics into medicine (Florence Nightingale’s rose diagram). After which the methods have been repeated over and over again. the methods keep getting better, and the number of parameters keep increasing, but so do the tools we have at our disposal.

1 Like

Love it. People have be struggling to reconcile the forces of systems and people for decades.

In R.J. McCrory’s 1963 introduction to “The Design Method,” the title suggests a decisive and confident approach. However, the actual beginning of the text appears surprisingly tentative.

“Just as in Great Britain, the designer in the USA has been in danger of becoming the forgotten practitioner of technology. Because he must, almost by definition, be a generalist, the designer has been discounted in favour of the specialists in more tangible areas. But in the USA this tendency to undervalue the designer seems now to be reversing in both industrial and academic circles. In industry, the designer as systems manager is being rediscovered as the man who can grasp and accomplish a comprehensive programme with all of its involved and nebulous problems. Universities are realizing that design is, if anything, more intellectually and academically demanding then many of the more specialized areas of study.“

I’m excited to learn more about this statement:

complexity of problems is actually not rising as much in my opinion.

Tell me more!

3 Likes

When broken down, all problems (social or business) can be measured in an output which matters. Those outputs can be driven by the values of the time. For instance, being able to measure throughput of a factory was of immense importance when the modern industrial process came up. A gazillion methods were introduced until Toyota settled the debate. Today this is evolved into an autonomous system so productivity is now measured by traceability from factories. Its constant optimization. The math doesnt change. How people handle it does. Similarly, general design problems are always focused on improving customer experience, reducing pain and stress, and increasing access. Of course there are more, but the problems have not really changed. The playing field and dynamics of constituent elements has. We just need the same tools which can handle scale more effectively.

3 Likes

Here is an example of the change that we have brought in for my team - essentially the same process of any design consulting - you conduct a discovery, identify challenges, brainstorm and prototype. this is the ballpark of all design practices with more tools thrown in. Given my world is AI focused, we now add a step called reimagine - where we reimage the steps as if run by a magic want without constraints. This is basically an additional step where we check for a user journey before we spend time designing a full solution. And all we have to do is run the research value chain and identified (felt) problems through a prompt. So same process, new tools - and it reduces our ideation to solution design time by a lot with a lot less pain.

2 Likes

I agree here, that fundamentally the big buckets of problems are still the same. Innovation is often misused to describe successful creative people , product and design teams…“they’re so innovative.” It’s lost much of its meaning.

When broken down, all problems (social or business) can be measured in an output which matters.

Right, and “outputs that matter” are solid outcomes. This is where the best teams thrive, when they have the systems in place to work at scale, but the collaborative sense to create great outcomes.

It feels like we’re at a bit of a speed bump these days, where the tooling is overwhelming teams… knocking the organization’s maturity down a notch and making it harder to visualize outcomes. Some teams are thriving, others are stuck. What are you seeing?

2 Likes

I can’t speak for other teams. I am building my own and we are continuously refining our process. As the old adage goes - fall in love with the problem - not the solution. We don’t care about the tools as much. However, as soon as we find a tool that works, we templatize it. Our approach is to minimize time spend on gathering and understanding information and maximizing synthases of the data. So we have designed templates that do exactly this.

Let’s say the work you have to do pre-project. You have to

  1. do your secondary research
  2. identify your stakeholders
  3. for us - identify an average value chain (industry standard)
  4. build questions which we want answered.

Each of these now is an internal AI tool - initially as a set prompt with a large context window where we dump as much information about the company as we can - soon to become actual tools which are built in a workflow such that we and the client can track the full progess and depending on our discretion - follow specific research outputs and reimaginatons and brainstorming and can comment along the way. (new feature to be added soon).

2 Likes

I guess we are less afraid about outsourcing the major effort of a design team as long as there is a diligent human present to review the output of an AI tool. We find we get fairly good output with the process and we save a lot of time and mental bandwidth.

2 Likes

Love this. It captures a big part of the problem we’re trying to help teams solve with Glare. I see a lot of teams chasing “design on demand” through AI prompting. It’s useful for generating outputs, but it doesn’t solve the orchestration problem of bringing everything together. That part is still deeply human.

Where it gets interesting is when orchestration is paired with clear intent. Understanding the needs of users, agents, and systems together is what creates real impact. In my view, design leaders need to own that influence.

I like the way you are thinking about these problems. You are seasoned and have great balance. How do you think leaders entrenched in existing systems should go about pushing for these changes?

1 Like

In a line - be metric backward. Let’s step away from design as a process or whatever it is - assume it as any problem solving methodology. In the past I have worked on projects on designing new healthcare systems, new microfinance systems, even new ai application concepts. While there is value in using design towards those approaches - where design fails at times is its insistence on showing how smart and differentiated it is. There is value in that, but not at the cost of lacking focus on the bottom line. Very rarely we see a designer going to a company and directly talking about shaving 3% off your expenditure, or adding a % to the company’s EBITA. The one’s who do, and know how to deliver it (better yet - tie their compensation to delivering it) are the teams which will really build faith.

There is a secondary reason why its important to be more metric focused. In any design or systems project - there are a lot of leadership folks you have to deal with. I have not worked in this field in the US, but in India, UK, and middle east - I have without exception found one naysayer who can derail your full project because he/ she/ they dont like your work.

They can always find faults or loss perspectives often due to poor understanding of the intent. However, with a metric - this will be harder to fight against. Not that they don’t but you still have more proof to fall back on or a agreed path to move towards.

2 Likes

Agreed. You are speaking my language. When you own the data, the nuances don’t limit design, they strengthen it.

That’s what we’re trying to do with UX metrics. Take a fuzzy need and shape it into something the business can understand in concrete terms. Tying this back to systems and design thinking, the goal is to systematize the effort so teams are not starting from zero every time.

Here’s where it starts to get interesting with agents and users… the way we measure has to evolve and change. What are your thoughts here and how is your team thinking about this?

2 Likes

How and when to measure is critical. It determines if your project will be considered a success or worse - you have been wasting everyone’s time (which is way worse than being a failure). This is how we do it, and admittingly, its still not perfect:

  1. We distance ourselves from usecases. Usecase based efficiency will very rarely create a big impact. A simple example of an idea which we ourselves junked because we couldn’t justify a 4X ROI was a AI screener job interview. The aim was for AI to take the first round of technical interviews for a company which has managed services as a big part of its business. They have to hire a lot and very quickly and getting senior technical folks to do this is time consuming. It might sound like a big problem, till we realised the price of using such agents to build and the user experience for the same. You bring the ROI to about 3-4X. However, what happens when your interviews are shorter, or you are hiring just based on profile or if the candidate is a terrible communicator and the JD doesnt need as much client exposure. It failed the viability test.
  2. Now a place where this is successful. A real estate company is managing weekly reporting, updated and changes to their development plans etc and releasing tenders linearly. One PM manages the flow of the information - from planning to procurement to estimations and all over the place. Plus if the leadership wants changes, your process breaks and you start all over again wasting weeks. When discussing the impact of delays, one gentleman asked back if we wanted the numbers if weeks or years. We realigned every departments’ core KPI to the delay from the department in the industry. We converted a linear process to a star process designing a simple collaborative PM tool where the role of AI was just completeness checks, automated nudges and prescriptive decision making. Simple AI use changes the user experience completely. We demoed the solution and it was unanimously loved. We are in the execution phase and have strict mechanisms to measure the success of the solution by baselining prior delays. Hoping we hit it big with this one.
2 Likes

We have a secondary advantage which has given us a powerful ability to prototype simple solutions to execute them quickly. We have our own AI orchestration tool which has a lot of powerful agentic functionality which we leverage to quickly prototype solutions. This helps reduce time to reach a shared understanding with the clients and helps get a greater buy-in.

Some amazing golden nuggets in this answer and thread. So good @nikhil_mahen.

I want to thank you for spending time with us and sharing your insights. There’s an amazing future to create!

Random aside: please tell me you have this saved somewhere on your computer and that you use it whenever you get the chance :rofl: @nikhil_mahen (iRobot is one of my all-time favorites)

Question: what do you think about designers who find themselves unable to think systematically (or they simply don’t want to)? Are they at a huge disadvantage? Or does it make sense to lean into one area turning them into a design specialization?

I’m sure there is a space for the wild creativity of designers who go all over the place - but most really good one’s I have met have a systematic methodology in place where they follow controlled chaos to its advantage. Disadvantages of the unstructured processes are plenty - potential delays, hard to explain how its an important step for clients, resources pushed in directions which might not yield anything positive - these are just to start. Some want the cross connection of happy accidents but the value vs effort in my opinion often doesnt make sense. Though I would preface my comments by saying that it is a personal preference - I might for sure be missing up sides in the uber-creative methods.

1 Like

@nikhil_mahen I like the real-world examples you provide for the ideal use of DT vs ST. What types of problems in web design would each of these types of thinking work best for?

1 Like

In web design a typical user journeys are best suited by design thinking techniques in most scenarios. However, one place I would use a systems approach (with elements of design approach for visual design) is for digital governance, or essential services perspective. Most government websites are impossible to design for because of the sheer quantum of information which has to be navigated. In such a situation flipping the requirement of how discovery happens and how the discovery is part of a larger value chain is essential. Moreover users of this can be from all walks of life so doing a targeted user research will be quite a challenge.

A potential outcome could be to convert all government websites to just a single chatbot and nothing else! Discoverability is through asking the requirement. features and user journeys appear as and when needed.

2 Likes