Design Thinking in Technology: From User Research to Real World Execution
Design thinking can help teams understand people, frame the right problem, explore alternatives, and test assumptions early. It creates value when those insights are converted into requirements, technical choices, accessible interfaces, delivery priorities, operational workflows, and measurable outcomes.
Scope: This article discusses product discovery, service design, user research, software delivery, accessibility, and human-centred AI. It is not legal, privacy, accessibility-compliance, medical, financial, safety, engineering, employment, regulatory, or other professional advice. Research involving vulnerable people, sensitive information, high-impact decisions, or regulated services requires appropriate expertise and safeguards.
Technology teams can ship software that is functional, secure, and technically sophisticated while still failing the people or operation it was intended to support.
The problem is not always a lack of empathy or creativity. Products may also fail because of weak market demand, an unsustainable business model, inaccessible design, technical limitations, poor data, missing integrations, weak change management, or inadequate support.
Human-centred design helps teams discover those conditions earlier. It does not replace product strategy, engineering, security, architecture, delivery management, or operational accountability.
Quick Answer: How Should Technology Teams Use Design Thinking?
Start with a clearly bounded problem and the people affected by it. Observe real work, combine qualitative and quantitative evidence, map the complete service, define measurable outcomes and constraints, explore several solution types, prototype the riskiest assumptions, test with representative users, and convert the evidence into an executable product and operating plan.
Continue research after launch. Measure whether users complete the task, whether the service produces the intended outcome, and whether new burdens or exclusions appear elsewhere in the workflow.
Design thinking should reduce uncertainty before expensive commitments—not become a workshop that delays ownership, decisions, or delivery.
What Design Thinking Means in a Technology Environment
IDEO describes design thinking as a human-centred approach that brings together what is desirable for people, feasible with technology, and viable for organizations.
ISO 9241-210 describes human-centred design as an approach to interactive systems that focuses on users, their needs, and their context of use while applying human-factors, ergonomics, usability, and accessibility knowledge.
In practice, a technology team should examine:
- What people are trying to accomplish
- The environment in which the work occurs
- Existing tools, policies, incentives, and workarounds
- Technical and operational constraints
- Business or public-service viability
- Security, privacy, accessibility, safety, and regulatory requirements
- Who benefits and who carries new work or risk
- How the product will be delivered, operated, supported, and changed
Design thinking is not only interface design
The solution may involve:
- A policy change
- A clearer service process
- A removed approval
- A new staff role
- Better data
- An integration
- An automation
- A software feature
- Training or communication
- A combination of several changes
The goal is not to build the interface people request. It is to understand the outcome they need and design the smallest complete service that can produce it.
The Five Modes Are One Framework—not the Design Process
Stanford d.school’s Design Thinking Bootleg identifies five modes:
- Empathize
- Define
- Ideate
- Prototype
- Test
The d.school explicitly notes that teams can start wherever useful. Its later writing also cautions against treating a simplified five-step workshop as the single design process.
The Design Council’s Double Diamond uses four phases:
- Discover
- Define
- Develop
- Deliver
The two diamonds represent divergent exploration followed by convergent decisions. The model includes delivery rather than ending at a tested concept.
| Framework | Useful emphasis | Common misuse |
|---|---|---|
| Five modes | Understanding people, framing, generating ideas, prototyping, and testing | Treating the modes as a mandatory linear checklist |
| Double Diamond | Diverging and converging across problem and solution spaces | Assuming each phase happens once |
| Human-centred design | Users, context, usability, accessibility, multidisciplinary work, and lifecycle | Reducing it to interviews or interface polish |
| Service design | Frontstage and backstage processes across channels, people, systems, and policies | Designing only the digital screen |
| Agile delivery | Incremental delivery, feedback, learning, and adaptation | Shipping small increments without validating the problem |
Use the language that helps the team work. Do not spend more time defending a framework than investigating the problem.
Start With the Right Scope
Some design initiatives begin with a solution already selected: “design an AI chatbot,” “build a mobile app,” or “create a dashboard.” That removes the most valuable question: what change is actually needed?
A strong initial scope identifies
- The user or affected group
- The task or outcome
- The current service or workflow
- The business or public-service pressure
- Known constraints
- The decision owner
- The evidence available
- The consequence of failure
- The part of the system that can realistically change
Problem statements should remain testable
Weak:
- Users need a better dashboard
- We need an AI assistant
- The onboarding experience should feel modern
Stronger:
- New customers cannot identify which documents are required before submitting an application
- Dispatchers spend time re-entering job details because the CRM and scheduling system do not share a reliable record
- Clinicians cannot locate the current approved policy within the time available for the task
Set non-negotiable constraints early
- Budget
- Delivery window
- Existing systems
- Data access
- Privacy and security
- Accessibility
- Safety
- Regulation
- Operational capacity
- Support and ownership
A narrow scope should reduce the number of unknowns—not hide critical parts of the service outside the project boundary.
Research With Real Users and in the Real Context
The original article correctly challenged conference-room design, but “leave the office” is not always literal or sufficient.
User research can involve:
- Contextual observation
- Interviews
- Diary studies
- Support-ticket analysis
- Call and chat review
- Workflow shadowing
- Accessibility research
- Analytics
- Search logs
- Usability tests
- Service complaints
- Field visits
- Participatory workshops
The Government of Canada’s digital guidance recommends researching with users to understand their needs and conducting ongoing testing to guide design and development. GOV.UK’s Service Manual similarly places user research, service design, accessibility, measurement, and technology within one delivery approach.
Observe the complete task
Document:
- Trigger
- Goal
- Information needed
- Tools and channels
- Handoffs
- Decisions
- Waiting
- Errors
- Workarounds
- Environmental conditions
- Accessibility needs
- Emotional and cognitive load
- Outcome
Do not treat users as one group
Research should include relevant variation in:
- Role and authority
- Experience and digital skill
- Language and literacy
- Disability and assistive technology
- Device and connectivity
- Location and environment
- Volume and complexity of work
- Customer, employee, administrator, and support perspectives
Protect participants
Use appropriate consent, privacy, confidentiality, data minimization, recording controls, incentives, safeguarding, and research governance. Research in healthcare, employment, education, finance, government, or with vulnerable people may require additional review.
Empathy is not intuition about another person. It is disciplined evidence gathering, interpretation, and continued humility about what the team does not know.
Define the Problem Without Erasing Complexity
Research produces observations, quotes, journeys, statistics, incidents, and contradictions. The define stage converts that evidence into a problem the organization can own and act on.
Useful synthesis methods
- Journey map
- Service blueprint
- Process map
- Affinity analysis
- Jobs-to-be-done analysis
- Root-cause analysis
- Task analysis
- Failure-mode review
- Accessibility barrier analysis
- Assumption map
A complete problem definition includes
- Who experiences the problem
- What they are trying to accomplish
- Where and when the problem occurs
- Evidence of frequency and severity
- Current workarounds
- Operational and business impact
- Root causes and contributing conditions
- Constraints
- Unknowns
- Desired outcome and measurement
Separate symptoms from causes
“Users do not complete the form” may result from:
- Ineligible users reaching the form
- Unclear terminology
- Unknown document requirements
- Accessibility barriers
- Account or identity failure
- No save-and-return function
- Fear about how information will be used
- A process that should not require a form
Do not force one problem statement when several systems are involved
A single user experience may reveal separate policy, data, staffing, software, and communication problems. Assign each to an owner and decide what the current product can address.
Generate and Compare Options—not Features
Ideation should expand the solution space before the organization commits to one form.
Options might include:
- Remove the step
- Change the policy
- Move the decision earlier
- Improve the information
- Connect two systems
- Give a staff member better tools
- Create self-service
- Add assisted service
- Automate a bounded task
- Build software
- Buy or configure an existing product
Cross-functional participation
Include the people needed to evaluate desirability, feasibility, viability, accessibility, safety, and operation:
- Users and affected people
- Product and design
- Engineering and architecture
- Operations and support
- Data and AI
- Security and privacy
- Accessibility
- Legal, compliance, or safety
- Sales, service, or customer success where relevant
- Finance and procurement
Do not suspend judgement entirely
Early divergence is useful, but ideas that require unlawful data use, unsafe behaviour, unavailable technology, or an impossible operating model should be identified.
Compare options systematically
| Dimension | Question |
|---|---|
| User value | Does the option improve the user’s ability to complete the task or achieve the outcome? |
| Operational value | Does it reduce delay, error, rework, cost, risk, or capacity constraints? |
| Feasibility | Can it be built, integrated, secured, maintained, and supported? |
| Viability | Is there a sustainable business, funding, or service model? |
| Accessibility and inclusion | Can relevant people use it, with appropriate alternatives? |
| Risk | What privacy, safety, security, fairness, legal, or reputational harm could occur? |
| Evidence | Which critical assumption can be tested quickly? |
| Time to value | Can the option produce meaningful evidence before a large commitment? |
Prototype to Learn, Not to Simulate Completion
A prototype is a representation used to answer a question. Its fidelity should match the uncertainty.
Examples
- Paper interface
- Clickable wireframe
- Storyboard
- Service role-play
- Concierge service
- Wizard-of-Oz prototype
- Spreadsheet model
- Technical spike
- API proof of concept
- Data sample
- AI prompt and evaluation harness
- Operational pilot
Match the prototype to the question
| Question | Suitable prototype |
|---|---|
| Do users understand the sequence? | Paper or clickable flow |
| Can staff deliver the service? | Role-play, service rehearsal, or concierge pilot |
| Can the system access the required data? | API spike or representative data test |
| Can AI perform the bounded task? | Representative evaluation set and controlled prototype |
| Will customers pay or adopt? | Offer, landing page, sales conversation, or limited paid pilot |
| Can the organization support it? | Operational simulation with queues, exceptions, and runbooks |
| Will it meet performance and scale needs? | Technical proof, load test, architecture spike, or staged production test |
Label simulated functions
If a person is manually producing a result that appears automated, record the hidden labour. A successful Wizard-of-Oz test validates the experience or demand—not technical feasibility or cost.
Prototype the failure path
- Invalid input
- Unavailable service
- Missing permission
- Incorrect AI output
- Payment failure
- Human escalation
- Data conflict
- Accessibility barrier
- Offline or slow connection
A prototype should make uncertainty cheaper to resolve. It should not create false confidence through visual polish.
Test the Product Without Selling It to the Participant
Usability testing examines whether representative users can complete realistic tasks with the product or prototype.
Good test practice
- Define the research question
- Recruit relevant participants
- Use realistic tasks and data
- Avoid leading instructions
- Observe behaviour
- Ask neutral follow-up questions
- Record assistance and errors
- Include accessibility needs
- Protect participant information
- Separate findings from stakeholder opinion
Do not rely on preference alone
“I like it” does not establish usability, demand, safety, or value. Observe whether participants:
- Understand what the service does
- Know what to do next
- Complete the task
- Recognize an error
- Recover
- Trust the correct information
- Reject incorrect information
- Understand consequences
- Can use the service with their device or assistive technology
Testing does not prove the market or operation
A usability test can show whether people can use a proposed flow. Separate evidence is needed for:
- Willingness to pay
- Market size
- Implementation cost
- Technical scale
- Security
- Operational capacity
- Long-term adoption
- Business outcome
Testing should challenge the design. The team is responsible for protecting participants—not for making the prototype look successful.
Combine Qualitative and Quantitative Evidence
Design research is strongest when different methods answer different questions.
| Evidence | Useful for | Common limitation |
|---|---|---|
| Interviews | Goals, perceptions, context, terminology, and remembered experience | What people say may differ from what they do |
| Observation | Actual workflow, environment, workarounds, coordination, and hidden labour | The observed period may not represent all conditions |
| Support records | Repeated friction, failure, language, and unresolved needs | Represents people who contact support |
| Product analytics | Volume, sequence, abandonment, errors, and repeated behaviour | Shows what happened, not necessarily why |
| Operational data | Cycle time, backlog, rework, service level, cost, and exceptions | Definitions and data quality may be weak |
| Usability testing | Task completion, comprehension, errors, and recovery | Does not establish long-term demand or production performance |
| Experiment | Effect of a defined change under measured conditions | Requires appropriate design and interpretation |
| Market evidence | Demand, willingness to pay, alternatives, procurement, and competitive context | Interest is not a signed or retained customer |
Maintain an evidence register
For each product assumption, record:
- Assumption
- Risk if wrong
- Evidence available
- Evidence strength
- Test
- Decision
- Owner
- Date for review
Do not turn one quote, one customer request, one executive opinion, or one prototype session into proof of a general need.
Turn Research Insights Into Buildable Requirements
Design insight becomes execution when the team converts it into explicit product, technical, operational, and assurance requirements.
Requirement categories
- User and service outcomes
- Functional behaviour
- Workflow and business rules
- Data inputs and outputs
- Integrations
- Roles and permissions
- Accessibility
- Privacy and security
- Safety and high-impact controls
- Performance and reliability
- Reporting and audit
- Support and administration
- Migration and rollout
- Acceptance criteria
- Assumptions and exclusions
Trace the requirement to evidence
Example:
- Observation: Field staff lose connectivity at customer sites.
- Need: Staff must continue critical work without a live connection.
- Requirement: The mobile workflow must support specified offline tasks and synchronize safely when connectivity returns.
- Acceptance: A user can complete the defined tasks offline, retain an audit record, resolve conflicts, and recover from interrupted synchronization.
Prioritize by outcome and risk
Use:
- Must have for the first outcome
- Required control
- Evidence-building feature
- Later enhancement
- Explicitly excluded
A research finding is not a backlog item. Product and engineering must translate it into a requirement with a reason, owner, priority, and test.
Accessibility and Inclusion Must Start Before the Interface Is Finished
W3C’s Web Content Accessibility Guidelines explain how to make web content more accessible to people with disabilities. WCAG applies to dynamic content, mobile web experiences, multimedia, and AI-enabled web interfaces.
Technical conformance is essential, but inclusive design also requires research with people who use different devices, input methods, assistive technologies, communication modes, and service channels.
Consider
- Keyboard use
- Screen readers
- Magnification and zoom
- Voice input
- Captions and transcripts
- Colour and contrast
- Cognitive load
- Plain language
- Motor control
- Time limits
- Error recovery
- Language and literacy
- Device and bandwidth
- Assisted and non-digital alternatives
Accessibility is a service property
An accessible webpage can still lead to an inaccessible service if:
- Identity verification excludes users
- Required documents are inaccessible
- Support is available only by voice
- Deadlines cannot be extended
- The process requires precise motor interaction
- An AI assistant cannot transfer context to a person
- A user cannot correct automated output
Do not design for an average user who does not exist. Design the service to handle relevant variation and provide appropriate alternatives.
Connect Discovery to Delivery and Operation
Design thinking is sometimes separated from software delivery. Researchers and designers produce findings, journeys, and prototypes, then hand them to a team that did not participate in the evidence.
Keep a multidisciplinary team through delivery
- Product owner
- Design and research
- Engineering and architecture
- Quality assurance
- Data and analytics
- Operations and support
- Security and privacy
- Accessibility
- Domain expertise
- Change and communications
Use a continuous discovery cadence
During delivery:
- Test risky stories before full implementation
- Review production analytics
- Observe support cases
- Run accessibility checks
- Validate data and technical assumptions
- Test completed increments with users
- Revisit the problem when evidence changes
Do not confuse agility with lack of commitment
The team still needs:
- Product vision
- Scope
- Architecture direction
- Security and privacy controls
- Data contracts
- Acceptance criteria
- Release gates
- Budget and timeline
- Operational ownership
Design the backstage service
For every visible user action, identify:
- Staff task
- System action
- Data update
- Approval
- Exception
- Notification
- Support path
- Audit record
Design Thinking for AI-Enabled Products
AI introduces uncertain output, changing performance, probabilistic errors, data dependence, user over-reliance, and new forms of automation.
Microsoft’s Guidelines for Human-AI Interaction organize design recommendations around initial use, normal interaction, what happens when AI is wrong, and how the system changes over time. Google’s People + AI Guidebook provides practical guidance for defining user needs, success, mental models, explanations, and feedback.
Begin with the human decision
- What is the user trying to decide or accomplish?
- Which information is available?
- What does AI add that rules, search, or ordinary software cannot?
- What errors can occur?
- Can the user recognize those errors?
- Who remains accountable?
- What should happen when confidence is low?
Design for failure
- Set realistic expectations
- Show relevant limitations
- Allow correction
- Make the source or evidence visible where appropriate
- Provide undo and override
- Escalate high-impact or uncertain cases
- Collect feedback without using it blindly
- Monitor changes over time
Prototype AI with representative examples
A prompt demonstration is not enough. Test:
- Normal cases
- Edge cases
- Incomplete inputs
- Different languages and formats
- Unsupported requests
- Incorrect source material
- Adversarial instructions
- Tool or API failure
- Relevant accessibility and subgroup cases
Do not use user delight as the only AI metric
A fluent or fast system may still be wrong, unfair, insecure, or difficult to contest. Measure task quality, human judgement, error detection, workload, safety, accessibility, and outcomes.
Human-centred AI is not an AI feature with a friendly interface. It is a controlled relationship between people, data, models, tools, decisions, and accountability.
Applications Across Sectors
Healthcare
Observe clinicians, administrative staff, patients, caregivers, and support teams in the actual care or service context. Design around interruptions, infection control, privacy, professional accountability, accessibility, downtime, and patient safety.
Do not treat “less documentation” or “faster decisions” as sufficient outcomes. Measure quality, omissions, workload transfer, clinical review, patient experience, and harm.
Finance and insurance
Map underwriting, application, claims, fraud, service, complaints, notices, and human review. Research the experience of customers, employees, brokers, compliance teams, and affected people.
A smoother interface cannot cure an unfair criterion, inaccurate model, unclear policy, or inaccessible recourse process.
Logistics and field service
Research dispatchers, drivers, technicians, customers, warehouse staff, and support teams. Design for connectivity, safety, weather, vehicle constraints, real-time exceptions, physical effort, and customer access.
A five-second dashboard response may be less important than a workflow that remains safe and usable while moving, offline, under time pressure, or with protective equipment.
Construction and manufacturing
Observe work at the site, line, machine, office, and handoff. Include supervisors, operators, trades, maintenance, quality, safety, estimators, and project staff.
Do not move an office workflow onto a tablet without redesigning it for gloves, dust, noise, lighting, connectivity, shared equipment, and actual decision authority.
Public services and smart infrastructure
Include residents, staff, community organizations, people with disabilities, assisted-digital users, field workers, policy owners, privacy and security teams, and the people affected by enforcement or eligibility decisions.
Public services need transparency, accessibility, alternatives, procedural fairness, records, and accountability beyond ordinary consumer-product usability.
Context is not decoration around the user. It determines whether the technology can be used safely, lawfully, and effectively.
Where Design Thinking Fails
| Failure mode | What happens | Correction |
|---|---|---|
| Workshop theatre | Teams create sticky notes and journey maps without changing priorities or ownership | Define decisions, owners, evidence, deliverables, and implementation gates |
| Persona substitution | Invented profiles replace direct research | Use evidence-based segments and maintain traceability to real research |
| Research without power | Users provide evidence but leadership has already selected the solution | Clarify which decisions research can change before recruiting participants |
| Solution bias | The project is framed around an app, dashboard, chatbot, or AI tool | Reframe around the task and compare non-technical options |
| Prototype confusion | A polished prototype is treated as a nearly finished product | Label simulated functions and separately test feasibility, security, scale, and operation |
| Confirmation testing | Participants are guided toward approval | Use neutral tasks, observe behaviour, and record failure without defending the design |
| Accessibility late | Barriers are found after architecture and components are fixed | Include disabled users, standards, assistive technology, and alternatives from discovery |
| No business model | The product is desirable but cannot be funded, sold, supported, or maintained | Test willingness to pay, procurement, cost, ownership, and service model |
| No technical model | The prototype assumes unavailable data, integrations, performance, or AI capability | Run architecture, data, security, and technical feasibility spikes early |
| No service operation | The interface launches without staff, queues, support, exception, or fallback design | Build a service blueprint and operating model |
| Research bias | Only easy-to-recruit or enthusiastic users participate | Use a sampling plan and seek relevant variation and exclusion risks |
| Endless discovery | The team repeatedly researches without making a decision | Set evidence thresholds, decision dates, and a bounded next experiment |
| Outcome overclaim | Usability improvements are assumed to increase retention, revenue, safety, or productivity | Measure the downstream business or service outcome directly |
Design thinking is not a guarantee
It can reduce specific uncertainties and improve decision quality. It cannot guarantee:
- Product-market fit
- Technical success
- Faster development
- Higher retention
- Lower cost
- Organizational alignment
- Ethical or lawful outcomes
Those outcomes depend on execution, evidence, market conditions, governance, and the complete operating system.
A Practical Operating Model for Human-Centred Technology
User, task, service, business pressure, owner, constraints, risk, and measurable outcome.
Questions, participants, methods, privacy, accessibility, analysis, and evidence quality.
Journey, workflow, environment, tools, policies, data, decisions, workarounds, and affected groups.
Evidence, causes, constraints, unknowns, opportunity, success measure, and ownership.
Policy, process, service, integration, automation, buy, build, and no-build alternatives.
Desirability, viability, feasibility, accessibility, safety, security, data, and operational assumptions.
Learning question, fidelity, participants, scenario, measures, finding, and next decision.
Functional, data, integration, permission, accessibility, security, performance, support, and acceptance requirements.
Architecture, channels, frontstage, backstage, staff, systems, queues, exceptions, fallback, and lifecycle.
Prioritized releases, evidence, quality, assurance, rollout, training, migration, and change.
Task, usability, accessibility, service, adoption, business, risk, support, and operational outcomes.
Research, analytics, complaints, incidents, support, experiments, releases, and retirement.
A Twelve-Stage Roadmap From Discovery to Operation
Define the user or service outcome, business pressure, owner, boundaries, constraints, and decision the work will support.
Identify research questions, participants, evidence sources, privacy, accessibility, risks, timeline, and decision dates.
Observe real work, interview relevant people, review analytics, tickets, complaints, operational records, and existing alternatives.
Synthesize the journey, workflow, root causes, barriers, inclusion needs, evidence, unknowns, and measurable problem.
Generate policy, process, service, integration, automation, product, buy, build, and no-build alternatives.
Compare user value, operational value, feasibility, viability, accessibility, risk, time to evidence, and strategic fit.
Build the lowest-fidelity representation that can test the highest-risk assumption, including failure and exception paths.
Use representative participants and scenarios. Measure comprehension, task success, error, recovery, accessibility, and operational fit.
Convert evidence into product, data, architecture, integration, security, privacy, accessibility, operational, and acceptance requirements.
Build incrementally, test continuously, manage scope and quality, and maintain traceability from evidence to implementation.
Complete readiness gates, migration, training, accessibility, support, fallback, communications, measurement, and staged rollout.
Monitor outcomes, research real use, resolve complaints and incidents, improve the service, and retire features that do not create value.
Delivery Readiness Gates
| Gate | Evidence required |
|---|---|
| Problem | Named users, task, context, evidence, owner, baseline, desired outcome, and known causes |
| User evidence | Relevant participants, methods, analysis, limitations, accessibility, and affected-group coverage |
| Value | Evidence that the proposed change improves a user, service, operational, or commercial outcome |
| Feasibility | Architecture, data, integrations, performance, technical spike, dependencies, and maintenance |
| Viability | Funding, pricing or public-service model, cost, procurement, ownership, support, and lifecycle |
| Accessibility | Applicable standards, inclusive research, assistive-technology testing, alternatives, and remediation |
| Privacy and security | Data flow, authority, minimization, access, threat model, vendors, retention, incident, and user communication |
| Safety and high impact | Hazards, human authority, validation, escalation, contestability, professional review, and stop conditions |
| Usability | Representative task completion, errors, recovery, comprehension, assistance, and unresolved severity |
| Operation | Staff, queues, service levels, administration, support, exceptions, fallback, monitoring, and ownership |
| Delivery | Prioritized scope, acceptance criteria, environments, quality, migration, rollout, training, and rollback |
| Measurement | Baseline, instrumentation, outcome definitions, privacy, review cadence, decision thresholds, and owner |
A failed gate should create a decision: change the concept, reduce the scope, gather evidence, add a control, defer, or stop.
Measure Outcomes, Not Workshop Activity
The original article claimed that design thinking increases development speed, retention, renewal, collaboration, and stakeholder alignment. Those outcomes are possible but not guaranteed, so the revised framework requires direct measurement.
| Category | Useful measures |
|---|---|
| User task | Completion, time, error, assistance, recovery, comprehension, and confidence |
| Accessibility | Barrier severity, assistive-technology completion, alternative-channel use, accommodation, and unresolved issues |
| Service | Wait, handoff, first-contact resolution, backlog, abandonment, complaints, and service-level performance |
| Adoption | Eligible users, first use, repeat use, feature use, bypass, shadow process, and support demand |
| Business | Revenue, conversion, retention, cost, capacity, risk, or other outcome attributable to the change |
| Operational | Touches, duplicate entry, cycle time, rework, exceptions, workload, and administration |
| Product discovery | Critical assumptions tested, decisions changed, ideas stopped, time to evidence, and research coverage |
| Delivery | Rework, escaped defects, scope change, lead time, blocked work, and acceptance quality |
| Reliability | Availability, latency, failure, recovery, offline use, data loss, and support incidents |
| AI-enabled experience | Output quality, user correction, over-reliance, refusal, escalation, explanation, and model drift |
| Inclusion and harm | Outcome variation, exclusion, privacy complaints, safety issues, unfair burden, and redress |
| Economics | Research, design, engineering, software, operations, support, compliance, rework, and retirement cost |
Illustrative design value formula
Net design value = verified user and service improvement + avoidable rework and support reduced + operational or commercial value − research − design − development − change − support − new burden or exclusionDo not count a prototype, workshop, interview, journey map, or usability test as a business outcome. These are evidence-building activities.
A feature can be easy to use and still fail commercially. A profitable product can still be inaccessible or harmful. Maintain separate measures for usability, value, risk, and operation.
Common Risks and Recommended Controls
| Risk | Example | Recommended control |
|---|---|---|
| Preselected solution | The project begins with a mandatory chatbot, app, or dashboard | Reframe around the outcome and compare policy, process, integration, buy, build, and no-build options |
| Non-representative research | Only power users, internal staff, or easy recruits participate | Sampling plan, relevant variation, accessibility, affected groups, and research limitations |
| Research harm | Sensitive information is collected without appropriate controls | Consent, minimization, safeguarding, secure handling, review, and appropriate expertise |
| Leading research | The team explains the product until participants approve it | Neutral questions, realistic tasks, independent moderation, observation, and recorded assistance |
| False validation | Positive feedback from a few people is treated as market proof | Separate usability, demand, willingness-to-pay, technical, operational, and outcome evidence |
| Prototype deception | Hidden manual work appears automated | Label simulation, measure hidden labour, and test technical feasibility separately |
| Accessibility exclusion | The tested flow works only for users without disabilities or with high digital skill | Inclusive recruitment, WCAG, assistive-technology tests, service alternatives, and remediation gates |
| Technical fantasy | The concept depends on unavailable data, performance, integration, or AI capability | Technical spikes, data samples, architecture review, security testing, and explicit assumptions |
| Operational fantasy | The service assumes staff, approvals, queues, and support that do not exist | Service blueprint, workforce review, runbooks, capacity model, fallback, and owner |
| AI over-reliance | A fluent assistant causes users to accept incorrect output | Expectation setting, evidence, uncertainty, correction, override, escalation, and output evaluation |
| Endless iteration | The team repeatedly explores without committing to delivery or stopping | Evidence thresholds, decision owner, timebox, next experiment, and stop criteria |
| Insight handoff | Delivery teams receive findings without context or participation | Multidisciplinary ownership, traceable requirements, design reviews, and continuous discovery |
| Local optimization | A smoother user screen creates more work for staff or another user group | End-to-end service blueprint, workload measurement, affected-group research, and outcome monitoring |
| False ROI | Retention, speed, revenue, or cost improvement is attributed to design thinking without evidence | Baseline, defined intervention, complete cost, outcome measurement, and conservative attribution |
FAQs About Design Thinking in Technology
Is design thinking the five-stage process?
The five Stanford d.school modes are a useful introductory framework. Design work is iterative and can begin in different places. Other valid frameworks include the Design Council’s Double Diamond, human-centred design, service design, participatory design, and discipline-specific methods.
Is design thinking the same as UX design?
No. UX design focuses on the experience of using a product or service. Design thinking is a broader problem-solving approach. Human-centred and service design also include context, operations, policies, channels, accessibility, and lifecycle.
Do we need user interviews for every project?
Use the evidence appropriate to the uncertainty. Interviews may be valuable, but observation, analytics, support records, accessibility research, operational data, experiments, and usability testing may answer different questions. Do not interview people when the organization already has strong current evidence and a more specific test is needed.
How many users should test a prototype?
There is no universal number. It depends on the research question, user variation, risk, study method, and whether findings are repeating. A small formative study can identify obvious issues; high-impact, segmented, or statistically evaluated decisions require broader evidence.
Does design thinking make development faster?
It may reduce avoidable rework by testing assumptions early. Research and prototyping also require time. Measure the complete delivery and outcome rather than assuming that the method automatically accelerates development.
Should engineers participate in user research?
Yes, where appropriate. Direct exposure helps engineers understand context and identify technical implications. Research should still be planned and facilitated with appropriate methods so participants are not led and sensitive information is protected.
How does design thinking apply to AI?
Begin with the human task and decide whether AI adds unique value. Design expectations, uncertainty, evidence, correction, override, escalation, feedback, and changes over time. Test representative failures and measure human-AI team performance rather than model output alone.
When should a design-thinking project stop?
Stop or change direction when the problem lacks sufficient value, the team cannot access relevant users or data, evidence contradicts the concept, the solution is not feasible or viable, risks cannot be controlled, or a simpler process change solves the problem.
Sources
- IDEO: Design Thinking and human-centred innovation
- IDEO U: What is human-centred design?
- ISO 9241-210: Human-centred design for interactive systems
- NIST: Human-Centered Design
- NIST: Human factors and accessibility
- Stanford d.school: Design Thinking Bootleg
- Stanford d.school: Let’s stop talking about the design process
- Stanford d.school: Building your design muscles
- Design Council: The Double Diamond
- Design Council: Framework for Innovation
- Design Council: History of the Double Diamond
- GOV.UK: Service Manual
- GOV.UK: User research guidance
- GOV.UK: Service design guidance
- Government of Ontario: Service Design Playbook
- Government of Canada: Design with users
- W3C Web Accessibility Initiative: WCAG overview
- W3C: Web Content Accessibility Guidelines 2.2
- Microsoft Research: Guidelines for Human-AI Interaction
- Microsoft HAX Toolkit: Human-AI interaction guidelines
- Microsoft Research: Human-AI interaction design guidance
- Google People + AI Guidebook
- Google PAIR: User needs and defining success
- Google PAIR: Mental models and expectations
- Google PAIR: Crafting helpful explanations
Start With One User and One Workflow
Web Inventix AI can help map your current workflow, user needs, service barriers, assumptions, data, systems, accessibility, risks, technical options, MVP scope, operating model, and measurement plan. The first step should clarify the problem and test the riskiest assumption before the organization commits to a large build.
Book a Product and Workflow Discovery Review