The document discusses the integration of design thinking, specifically the Design for Delight (D4D) methodology, into agile frameworks for engineers to better understand customer needs and improve problem-solving. It emphasizes the importance of empathy, rapid experimentation, and refining solutions through collaborative brainstorming and feedback throughout the software development lifecycle (SDLC). Key takeaways include prioritizing customer issues, utilizing cheap prototypes for testing, and maintaining an iterative mindset to enhance product development.

1. An Engineer’s Essential Tool in Agile:
Design Thinking

2. Aliza Carpio
Principal Tech Evangelist,
Innovation Catalyst
San Diego, USA
https://www.linkedin.com/in/alizacarpio/
Sonia May-Patlán
Software Engineer,
Innovation Catalyst
Edmonton, CA
https://www.linkedin.com/in/sonia-may-patlan/

3. What we’ll cover
The Case for Change
Design Thinking Overview
Deep Dive on Design for Delight (D4D): Design Thinking Methodology
Connecting Agile Framework & D4D: Applying in our Day-to-Day
Walk Through a Sample Use Case (End to End)
Your Goody Bag: Key Takeaways

4. I’m a backend engineer. Why do I
need to know and practice Design
Thinking? Our product manager is the
one who tells us about the
customer and the problem we
need to solve. Do I need to
know anything else?
Design thinking is for
designers. I’m an engineer.

5. What is Design Thinking
The Interaction Design Foundation explains that Design Thinking…
● Is an iterative process that helps understand users (customers), challenge assumptions, and redefine problems.
● Is a way of thinking and working, as well as a collection of hands-on methods.
● Provides a solution-based approach to solving problems.
● Develops understanding of and empathy for people for whom we’re designing products or services.
● Helps us question: question the problem, assumptions, and implications.
● Is useful for problems that are ill-defined or unknown:
○ Re-frames problems in human-centric ways,
○ Creates ideas through brainstorming,
○ Adopts a hands-on approach in prototyping and testing.
● Involves ongoing experimentation: sketching, prototyping, testing, and trying out concepts and ideas.

6. Design For Delight (D4D)
Deep Customer Empathy
● Create shared
understanding, insights to
improve customers’ lives
● Gain empathy by observing
people where & when they
are experiencing pains or
problems
Rapid Experiments with
Customers
● Test our solution quickly
● Quickly learn what works,
what doesn’t
● Saves valuable time &
resources when making
next decision
Go Broad to Go Narrow
● Focus on what is most
important
● Go broad by using
creativity to explore many
potential solutions
● Go narrow by focusing on
bold solutions that delight
customers

7. Design For Delight
=
Customer Obsessed
Problem Solving
“I try to make sure that my team knows the
problem we are focused on and not go straight to
solutions. This is so important for all engineers to
do - it’s the first thing we all need to do before we
think about solutions.
I learned D4D when I was a co-op and I still use this
today and I tell other engineers”
Deepen Mehta,
Sr Software Engineer,
Machine Learning

8. Redefining the customer
Who consumes my work?
Customer =
End customer who consumes product
|| Front-end engineers
|| Coworkers who need infrastructure service
|| Manager who needs to present project progress to stakeholders ...
● If your problem statement solves for more than one customer, you must identify your primary
customer. If there are many primary customers, it’s too broad.
● If you don’t have a customer, no one needs your work.

9. How does Design Thinking (D4D)
connect to SDLC and Agile?

10. 1 2
3

11. Using D4D principles across each
phase of the SCRUM process

12. AgileTeamCharter
PLANNING
ANALYSIS
DESIGN IMPLEMENTATION
TESTING & INTEGRATION
MAINTENANCE
Scope PBL grooming Design
Sprint
Planning
Sprint
Execution
Sprint Retro
and Review
Sprint Demo
Daily
Scrum
Customer Empathy Rapid Experiments Go Broad to Go Narrow
Putting it Together

13. Let’s put this into practice

14. Problem Statement
I am:
A front-end developer at Intuit, working on a plugin for one of our product functionalities.
I am trying to:
Modernize the UI to have consistent design elements across the whole product,
But:
I can't use the standardized UI components that would simplify the implementation
Because:
Our tech stack is too old and thus not compatible with the new UI components we're supposed to use.
Which makes me feel:
Slow, frustrated and exhausted.

15. Ideal State
In a perfect world:
All of our plugins can easily use the latest UI components without worrying about compatibility issues
The biggest benefit to me is:
I can focus on improving the product, instead of trying to just making it work with the old tech
Which makes me feel:
Happy, efficient and on top of my work

16. Use these insights to narrow on most critical one in order to go broad on
brainstorming solutions before narrowing what to tackle in the sprint.
Scope
Scoping and planning
Review product backlog to make priority decisions for upcoming sprint.
Determine scope of work.
Connect with customers by listening to customer calls, doing interviews, reading
customer reviews or reading agent transcripts for insights.

17. Rewrit everythin !
Make UI components
compatible with every
tech stack
Ref r ug de n
fe e d op t
Tak dedicate mont
t refactor plugi
Team Brainstorming + Voting Exercise

18. Analysis
Analyze the work and further break down the “story”
in order to plan for the upcoming sprint.
Product
Backlog
As PD team triages issues with Customer
Success, they use D4D principles and
methods to narrow and focus on what the
team will tackle in upcoming sprint.
This process is ongoing and is in prep for
sprint planning.
Use a narrowing method called 2x2 to
prioritize the work based on two criteria.

19. Prioritize solutions
Eisenhower method:
URGENT
IMPORTANT
Improv
performanc
Sketch new
architecture
Rem
re d co
Rewrit cor
logi
Ad another
featur
Mak ur
c e k

20. Design
Design
In addition to defining architectural design, the experience you create must
also be customer-backed.
Conduct rapid prototyping with “cheap” experiments to quickly determine
the customer experience that will be build.
Use Tom Chi’s “poison cookie” principle to get directional data/feedback.
Collect feedback on prototypes, and narrow to key themes and
observations, which will help you and the team determine a solution.

21. ● Build new architecture diagram
● Review with team
● Improve structure
● Iterate
An Iterative Process

22. Implementation
Sprint work, completing stories
Daily
Scrum
Check in with customers to share and get
feedback on the solution you’re building.
As you learn from your customer, use “Going Broad
to Narrow” to narrow on tweaks to your solution... or
you may find that you have to pivot on your
solution
London: Each sprint, engineers close the loop
with customers. First, they connect to further
understand the problem, address it and circle
back with the customer once the issue is fixed
and released to production.

23. Testing and Integration
How would you also ensure that the solution/fix meets the customer
benefit you declared?
Testing and code coverage is part of sprint work
During code review process, the code reviewer may create a
comprehensive list of issues to fix. However, it is best practice if the code
reviewer narrows to the set of most critical fixes
Daily
Scrum

24. Maintenance
Deploy to production and provide monitoring and
support
Once solution is in production, teams listen
to/interact with customers to see how their solution
fixed a problem or how a new product feature is
being received.
Best practice: Connect with your Customer Success
team to circle back with the customer.
A DELIGHTER!
Usable
Software

25. Project Retrospective
Each team member contributes their input (broad) ...then, narrow to key themes to address them for
next sprint.
Declare what you and the team learned from customers during the sprint
If you and the team conducted experiments with “cheap” prototypes, declare what you learned through
the process, which will be fodder for experiments/prototypes you want to tackle for next sprint

26. Key Takeaways

27. Goody Bag
Here’s what you can bring back to
your team!
1. Design thinking
methodology summary:
Design for Delight (D4D),
principles
2. Breakdown of how to use
D4D in Agile/SCRUM: e2e
process cards
3. Fun Zoom background to
share with your team as you
practice these skills

28. Understanding your customers’
needs or pain will help you narrow
to the problem you are trying to
solve.
Ask “What is the customer
problem?”
Consider as many ideas and
potential solutions before you
narrow to the one.
Ask “How might we solve this?”
Establish an “experimentation
mindset,” which means you are
testing and measuring at all times.
Ask “How might we test our
hypothesis or solution before we
code it?”

29. Software Delivery Lifecycle (SDLC) SCRUM
Design for Delight
(Design Thinking)
Scoping and Planning - Review product backlog to make
priority decisions for upcoming
sprint.
- Determine scope of work.
- Connect with customers; listen to
calls, read online reviews or agent
transcripts for insights.
- Use insights to narrow on most
critical one(s). Go broad by
brainstorming solutions before
narrowing to sprint scope.
- Determine what experiments to run
with “cheap” prototypes.
Analysis Analyze the work and further break
down story to plan for upcoming
sprint.
Use a narrowing method, 2x2, to
prioritize.
Design Product Backlog - “Cheap” and rapid prototyping
- Narrow on customer benefit of your
solution
- Narrow to key insights
Implementation Sprint work, completing stories Check in with customers

30. SDLC, Software Delivery Lifecycle SCRUM
Design for Delight
(Design Thinking)
Testing and Integration Testing and code coverage as part of
sprint work
- During code review process, the
reviewer may create a comprehensive
list of issues to fix.
- Best practice is to narrow to set of
most critical fixes
Deployment and Maintenance Deploy to production and provide
monitoring and support
- Once solution is deployed in
production, teams listen to and
interact with customers to see how
their solution fixed a problem or how
a new feature is received.
- As you learn, determine if there are
other problems you and your team
still need to solve for future sprints.

31. Download the Zoom background!

32. Aliza Carpio
Principal Tech Evangelist,
Innovation Catalyst
San Diego, USA
https://www.linkedin.com/in/alizacarpio/
Sonia May-Patlán
Software Engineer,
Innovation Catalyst
Edmonton, CA
https://www.linkedin.com/in/sonia-may-patlan/
Thanks for
Joining Us!
Questions?
Download our slides here:
bit.ly/Devweekdesignthink