AWS Builder Center

Builder Center

What Solution Architects Can Steal from UX Design Thinking

What Solution Architects Can Steal from UX Design Thinking

The Best Architectures Are Designed WITH Users, Not FOR Users

Kanta

Solutions Architect

The Framework at a Glance

Traditional SA vs. Design Thinking SA

The Uncomfortable Truth About Why Architectures Fail

Here's something nobody puts in the post-mortem: most architectures don't fail because of technology choices. They fail because they were designed in a room full of architects, for a room full of architects.
I've sat through dozens of architecture reviews where the diagrams were pristine, the patterns were textbook, and the solution was technically elegant. And then it hit production. And the people who actually had to live with it — the developers, the ops teams, the end users — looked at it like a foreign object that had landed in their workflow uninvited.
Sound familiar?
After running 8+ workshops that blend architecture practice with design methodology, I've come to a conclusion that will annoy purists on both sides: Solution Architects need to steal from UX designers. Not the wireframes. Not the sticky notes (okay, maybe the sticky notes). The mindset.
The core insight is simple: the best architectures are designed WITH users, not FOR users.
Let me show you what I mean.

The Parallel: Design Thinking Meets Solution Architecture

If you've never seen the Design Thinking pipeline, it looks like this: Empathize → Define → Ideate → Prototype → Test. UX designers have been using this for decades to build products people actually want to use.
Here's the thing — Solution Architects are also building products. We just call them "systems" and pretend the humans aren't part of the equation. They are. They always were.
Let me walk you through each phase, translated into SA practice.

1. Empathize → Discovery & Customer Immersion

The UX version: Sit with your users. Watch them work. Shut up and observe.
The SA version: Sit with your actual users — not just the stakeholders who signed the SOW.
This is where most architecture engagements go sideways before they even start. You show up, you meet with the VP of Engineering, the CTO, maybe a product manager. They tell you what they think the problem is. You nod. You write it down. You go design something.
But here's what I've learned the hard way: stakeholders describe the problem they want solved. Users reveal the problem that actually exists.
In multiple engagements I've seen the stated problem be "we need to modernize our monolith" when the actual problem was "deployments take three weeks because of a manual approval chain that nobody will admit is the bottleneck." No amount of microservices fixes that.
What this looks like in practice:
  • Shadow the on-call team for a rotation. Watch what actually pages them at 2 AM.
  • Sit with developers during their deployment process. Don't ask "how does it work?" — ask "show me."
  • Attend the sprint retro, not the steering committee meeting.
  • Talk to the person who writes the runbooks, not the person who approves them.
🧰 UX Tools to Steal for This Phase:
User Interviews → Schedule 30-min 1:1s with the people who actually live with the system — operators, SREs, junior devs, the person who onboards new hires. Ask open-ended questions ("Tell me about your worst day with this system") and shut up. The magic is in the silences.
Contextual Inquiry → Don't just interview people about their work — watch them DO it. Sit behind an SRE during an incident. Watch a developer push a deployment. The things people forget to mention in interviews become visible when you observe in real-time.
Empathy Maps → Create a 4-quadrant map: what does the user SAY about the system vs. what do they actually DO? What do they THINK (goals, beliefs) vs. how do they FEEL (frustrations, fears)? I guarantee the "say" and "do" quadrants won't match — that gap is where your architecture should focus.
Personas → Build "operator personas" for your system. Who's the on-call engineer at 3 AM? Who's the junior dev onboarding in week one? Who's the auditor checking compliance quarterly? Who's the data scientist querying the platform? Each persona has different needs from the same architecture. Design for all of them, not just the VP who signed the contract.
The goal isn't to become best friends with every engineer. It's to build an architecture that acknowledges real constraints, real workflows, and real pain — not the sanitized version that makes it into the slide deck for leadership.

2. Define → Problem Framing (The ADR Nobody Writes)

The UX version: Synthesize your research into a clear problem statement. "How might we...?"
The SA version: Write the Architecture Decision Record before you start solving. Frame the actual problem, not the first solution that popped into your head.
I have a theory: the Architecture Decision Record (ADR) is the most powerful document in our profession, and approximately 4% of teams actually write them before making decisions. The rest write them retroactively as a justification exercise, which is about as useful as writing your diet plan after Thanksgiving dinner.
A good problem frame sounds like: "The current system cannot process more than 10,000 events per second, and projected load for Q3 is 45,000 eps, with 95th percentile latency requirements of <200ms."
A bad problem frame sounds like: "We need Kafka." That's a solution, not a problem. And I hear it in discovery calls constantly.
What this looks like in practice:
  • Write the constraints before you write the solution. All of them. Budget. Team skills. Compliance. Timeline. The legacy system nobody's allowed to touch.
  • State what success looks like in measurable terms. "Better performance" isn't measurable. "P99 latency under 150ms at 50K TPS" is.
  • Identify who gets to say "this is done" — and make sure they were in the room during Empathize.
  • Document what you're explicitly not solving. Scope is a gift. Give it to yourself.
🧰 UX Tools to Steal for This Phase:
Affinity Diagramming → Take everything you heard during Empathize — quotes, observations, pain points, workarounds — and cluster them into themes on a wall (or a Miro board). Patterns emerge that you'd never spot in a linear notes document. "Oh, five different people all mentioned the deployment approval chain" becomes visible only when you see the clusters.
"How Might We" Statements → Reframe every constraint as an opportunity question. Instead of "the approval process takes 3 weeks" → "How might we deploy safely without a 3-week approval chain?" Instead of "we can't touch the legacy database" → "How might we serve new requirements without modifying the existing data model?" These questions open design space instead of closing it.
User Journey Mapping → Map the developer/operator experience end-to-end: onboarding → first commit → deploy → monitor → incident → post-mortem → iterate. Where are the pain points? Where do they wait? Where do they get confused? This is NOT a system architecture diagram — it's a MAP of human experience through your system. The architectural insights come from the friction points you discover.
Problem Statement Canvas → Use a structured template: WHO has the problem? WHAT is the problem? WHY does it matter (business impact)? WHEN does it happen (trigger conditions)? Write this on a single page. If you can't, you don't understand the problem well enough yet. Go back to Empathize.
One enterprise team I worked with spent two weeks in Define and felt like they were "behind." They shipped three months ahead of a comparable team that jumped straight to implementation. Problem framing isn't a delay. It's a cheat code.

3. Ideate → Architecture Options & Trade-off Analysis

The UX version: Generate as many ideas as possible. No judgment yet. Diverge before you converge.
The SA version: Stop falling in love with the first pattern that matches. Generate at least three options, and make yourself argue for each one.
This is where experienced architects are actually more dangerous than junior ones. We've seen patterns work before. We have a mental library of "this problem → that solution" mappings. And so we skip straight to the answer.
The problem? Your mental library is built from your past contexts. This context is different. The team is different. The constraints are different. The budget is different.
What this looks like in practice:
  • For every architecture problem, sketch at least three approaches. Yes, even if one of them is "obviously" right.
  • For each option, write down: what's great about it, what's terrible about it, and what would have to be true for it to succeed.
  • Include the "boring" option. Sometimes a well-configured managed service beats a custom distributed system. Sometimes a spreadsheet beats a data platform. I said what I said.
  • Invite someone who will disagree with you to the review. Not for politics — for perspective.
🧰 UX Tools to Steal for This Phase:
Competitive Audit → UX designers research what competitors are doing before designing anything. SAs should too. How did OTHER companies solve this problem? Look at open-source architectures on GitHub. Read AWS case studies. Check reference architectures on the AWS Architecture Center. You're not copying — you're learning from the entire industry's mistakes before making your own.
Crazy 8s → This is my favorite technique. Set a timer for 8 minutes. Sketch 8 different architecture options — one per minute. No judgment. No "that won't work." Just draw. You'll get 3 bad ideas, 3 obvious ideas, and 2 ideas you'd never have reached through logical deduction. Those last 2 are gold. The time pressure forces you past your first instinct.
Storyboarding → Draw the user's journey THROUGH the proposed architecture. Not the system diagram — the HUMAN experience. "Day in the life of a developer deploying to this system." Panel 1: developer opens PR. Panel 2: CI kicks off. Panel 3: tests run. Panel 4: approval needed. Panel 5: waiting... waiting... Panel 6: deployed. This reveals UX gaps that no architecture diagram catches.
Dot Voting → After presenting 3+ options to the team, let everyone vote instead of defaulting to the highest-paid person's opinion (the HiPPO problem). Give each person 3 dots. They place them on the options they prefer. It's fast, democratic, and surfaces disagreements that would otherwise simmer underground for months.
I once watched a team nearly build a custom event-driven orchestration platform when a properly configured state machine service would have handled their use case with zero operational overhead. They'd ideated exactly one option. Don't be that team.

4. Prototype → POC, Spike, Reference Architecture

The UX version: Build something cheap and fast to test your hypothesis. Paper prototypes. Clickable mockups. Anything that lets you learn without committing.
The SA version: Build cheap experiments before big bets. A POC isn't a mini-production system — it's a question with code.
Every architect I respect has a story about the POC that saved them from disaster. The load test that revealed the database couldn't handle the write pattern. The integration spike that proved the vendor's API didn't actually support the feature listed in their documentation. The cost model that showed the "serverless" approach would cost $40K/month at projected scale.
The ones who don't have that story? They found out in production. It cost more.
What this looks like in practice:
  • Frame every POC as a question: "Can service X sustain 10K writes/second with our data model?" not "Build a prototype of the new system."
  • Time-box aggressively. A POC that takes three months is a project, not an experiment.
  • Kill prototypes that succeed. They are not production code. They are answers. Throw away the code, keep the knowledge.
  • Test the scary part first. Not the part you already know works. The part that keeps you up at night.
🧰 UX Tools to Steal for This Phase:
Paper Prototyping → Before writing a single line of POC code, create an architecture "paper prototype": an ADR + sequence diagram + cost estimate on paper (or a whiteboard). Walk someone through it. "If we built this, here's what the request flow looks like, here's the cost at scale, here's where it breaks." You just validated (or invalidated) an option in 20 minutes instead of 2 weeks of coding.
Wizard of Oz → In UX, a "Wizard of Oz" prototype fakes the backend — the user thinks it's working but a human is operating it behind the scenes. For SAs: fake the expensive or uncertain parts. Mock the ML model. Stub the third-party API. Use a hardcoded response where the real service would go. You're not testing if you CAN build it — you're testing if the integration pattern WORKS. Validate the shape first, fill in the substance later.
Walking Skeleton → UX has "clickable prototypes" — the thinnest possible thing you can click through end-to-end. For architecture, this is the "walking skeleton": the thinnest possible end-to-end path that proves the architecture works. One API → one function → one database write → one response. No error handling. No auth. No logging. Just: does the signal get from A to Z? If yes, you've proven the architecture. Everything else is implementation detail.
A reference architecture is a prototype too — it's a prototype of an idea. Make it concrete enough to critique, incomplete enough that nobody tries to deploy it as-is.

5. Test → Well-Architected Review, Load Test, Cost Model Validation

The UX version: Put your prototype in front of real users. Watch what breaks. Iterate.
The SA version: Prove it before you ship it. Not "it works on my laptop" — prove it at scale, at cost, and against the actual quality attributes that matter.
This is the phase that separates architectures that survive first contact with reality from architectures that become cautionary tales in conference talks.
Testing an architecture isn't just load testing (though please, for the love of all that is holy, do load test). It's validating that the thing you built actually solves the problem you defined in Phase 2, for the people you talked to in Phase 1.
What this looks like in practice:
  • Run a Well-Architected Review (or equivalent framework review) before go-live, not after the first incident.
  • Load test with realistic data patterns, not synthetic happy paths. If your users send 50KB JSON payloads with nested arrays, test with 50KB JSON payloads with nested arrays.
  • Build a cost model at projected scale and 3x projected scale. Surprises at scale are expensive surprises.
  • Put the operations team in front of the monitoring dashboards during load test. Ask them: "Could you debug this at 3 AM?" If they hesitate, you have work to do.
  • Circle back to your users from Phase 1. Show them the system. Does it actually address their pain? You'd be amazed how often the answer is "sort of, but..."
🧰 UX Tools to Steal for This Phase:
Usability Testing → UX designers watch real users try to complete tasks with their product. SAs should do the same. Put an operator in front of the system: Can they deploy? Can they troubleshoot? Can they find the relevant logs during an incident at 2 AM? Can a new hire onboard in less than a day? If any answer is "no" or "only if they already know where to look," your architecture has a usability problem that no amount of documentation will fix.
Heuristic Evaluation → UX has Nielsen's 10 heuristics (visibility, error prevention, consistency, etc.). Apply the Well-Architected Framework's six pillars the same way — as evaluation LENSES, not checkboxes. Operational Excellence = is this operable by real humans? Security = does this build trust? Reliability = does this degrade gracefully? Performance = does this feel responsive to the user? Cost = is this sustainable? Sustainability = is this responsible? Each lens reveals different flaws in the same architecture.
A/B Testing → For UX, A/B testing means running two versions simultaneously and measuring which performs better. For architecture: run the old and new path in parallel. Shadow traffic. Compare real metrics — latency, error rates, cost per transaction. Don't just THEORIZE that the new architecture is better. PROVE it with data before you cut over. This eliminates the most expensive architectural mistake: committing to a new path based on vibes.
Card Sorting → In UX, card sorting helps organize information architecture by having users group items. For SAs: have the team prioritize non-functional requirements by forced ranking. Give them cards labeled "latency," "cost," "reliability," "time-to-market," "team familiarity," "security." Force them to stack-rank. You cannot optimize for everything — this exercise makes the REAL priorities explicit instead of pretending everything is "critical."

Why This Matters More Now — The AI/GenAI Factor

"Okay," I hear you saying, "this is nice philosophy, but I've got a backlog of GenAI features to architect. I don't have time for empathy workshops."
Here's why you're wrong: AI makes the human-centered lens more critical, not less.
When we're integrating large language models, building RAG pipelines, deploying AI agents — we're introducing systems that are fundamentally unpredictable in ways that traditional architectures aren't. A REST API either returns 200 or it doesn't. An LLM might return a hallucinated answer that looks correct and passes every automated check.
Who catches that? Humans. Users. The people you should have talked to in Phase 1.
GenAI architectures need Design Thinking more than any other type of system because:
  • Empathize: You need to understand what "good enough" means for AI-generated output in this specific context. A summarization error in an internal wiki is annoying. A summarization error in a medical record is dangerous. Same technology, different human stakes.
  • Define: "Add AI to our product" is not a problem statement. What task are you augmenting? What does failure look like? What's the human fallback?
  • Ideate: The solution space for AI is enormous and shifting monthly. If you're not generating options, you're building last quarter's architecture.
  • Prototype: AI prototypes are cheap and fast. You can test a prompt strategy in hours. Do it. Test twelve approaches before you pick one.
  • Test: How do you validate an architecture whose outputs are non-deterministic? You test with users. You build feedback loops. You design for graceful degradation when the model gets it wrong.
The architectures that will age well in the AI era are the ones designed around human judgment, human oversight, and human feedback loops. Design Thinking gives you that naturally.

What You Can Do Monday Morning

You don't need a two-day offsite to start. Here are five things you can do this week:

1. Add One User Interview to Your Next Discovery

Not a stakeholder meeting — a user interview. Find the person who will operate, deploy to, or consume your system daily. Buy them coffee. Ask them to show you their workflow. Shut up and watch.

2. Write the ADR Before the Diagram

Before you open your diagramming tool, open a text editor. Write: What is the problem? What are the constraints? What does success look like? Who decides? I promise this will save you more time than it costs.

3. Sketch Three Options (Even When You "Know" the Answer)

Force yourself to generate alternatives. Make one option wildly simple. Make one option maximally flexible. Make one option optimized for the constraint you think matters most. Then compare.

4. Frame Your Next POC as a Question

Not "build a prototype" — "answer this specific question." Write the question on a sticky note. When you've answered it, stop. Resist the gravitational pull toward building more.

5. Invite an Operator to Your Architecture Review

Not to present. To listen and react. Ask them: "If you got paged at 3 AM because this system was broken, what would you need to see? What would you do first?" Design for that answer.

Templates & Checklists

Architecture Decision Record (ADR) Template

Copy this for your next architecture decision:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# ADR-001: [Title of Decision]

## Status
[Proposed | Accepted | Deprecated | Superseded]

## Context
What is the problem? What forces are at play?
Include: current state, constraints, stakeholders affected.

## Decision
What is the change we're making? Be specific.

## Options Considered

### Option A: [Name]
- ✅ Pros: ...
- ❌ Cons: ...
- 💰 Cost: ...
- 🧑‍💻 Team readiness: ...

### Option B: [Name]
- ✅ Pros: ...
- ❌ Cons: ...
- 💰 Cost: ...
- 🧑‍💻 Team readiness: ...

### Option C: [Name]
- ✅ Pros: ...
- ❌ Cons: ...
- 💰 Cost: ...
- 🧑‍💻 Team readiness: ...

## Consequences
What becomes easier? What becomes harder?
What do we need to watch out for?

## Review Date
When should we revisit this decision?

Discovery Questions Checklist (Empathize Phase)

Use these in your next customer immersion:
Understanding the Problem:
  1. Walk me through what happens when [the thing that's broken] occurs. Show me.
  2. How often does this happen? Daily? Weekly? Only during peak?
  3. What do you do as a workaround right now?
  4. Who else is affected when this goes wrong?
  5. What have you already tried that didn't work?
Understanding the People:
6. Who gets paged when this breaks at 2 AM?
7. What does their first 5 minutes look like during an incident?
8. What tools do they have open when debugging?
9. What information do they wish they had but don't?
10. If you could fix ONE thing about the current system, what would it be?
Understanding the Constraints:
11. What can't change? (Legacy systems, contracts, compliance, politics)
12. What's the team's current skill set? What's adjacent?
13. What's the real timeline — not the slide deck timeline?
14. What's the budget ceiling nobody will say out loud?
15. Who has veto power over technical decisions?

Architecture Option Comparison Table

CriterionOption A: [Name]Option B: [Name]Option C: [Name]
Meets functional requirements?✅ / ⚠️ / ❌✅ / ⚠️ / ❌✅ / ⚠️ / ❌
Performance at target scale
Operational complexity (1-5)
Team readiness (1-5)
Monthly cost at projected load
Monthly cost at 3x projected
Time to implement
Vendor lock-in riskLow / Med / HighLow / Med / HighLow / Med / High
Failure mode
Recovery time (RTO)
Can we POC this in <1 week?Yes / NoYes / NoYes / No

Quick Self-Check: Which Phase Am I In?

Here's My Challenge to You

This week — not next quarter, not when the current project ends — this week — I want you to do exactly one thing differently:
Before your next architecture meeting, schedule 30 minutes with someone who will operate the thing you're about to design. Not the PM. Not the engineering manager. The person who will deploy it, monitor it, debug it, and get woken up when it breaks.
Ask them one question: "What does your worst day look like?"
Then design your architecture to make that day less terrible.
That's Design Thinking. That's empathy. That's the whole blog in one action.
Do it and tell me what you learned. I bet it changes your design.

Resources & Further Reading

Books

AWS Resources

Design Thinking Resources

Articles & Further Reading

Written by a Solutions Architect who believes the best diagrams start with conversations, not boxes.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article