There's a lot of content available about design sprints; what they are, how to run them, why they are useful. Key to them being successful is having a diverse team, including engineers. Very little of the content available covers the important role engineers play at this stage of product creation.

1. GV Design Sprints
for Engineers

2. You’ll leave here today with
→ An understanding of UCD
→ Deep insight into the GV Sprint Process
→ Knowledge of the role engineers play in sprints
→ Some resources to go and learn more

3. UCD, what is it?

4. We are not
our users.

5. User Centered Design
An approach to building products where each phase of the design process is
orientated around the needs, wants, limitations and desires of the end user.

6. An approach with many flavours!
Lean UX Storyboards
RITE
Charrette Deep dive
PersonasCrazy 8s Journey Mapping
Research
Heuristics
Sprints!

7. What is a sprint?

8. A 5-day Google Ventures inspired
process for answering critical business
questions through design, prototyping,
and testing ideas with end users.

9. Launch
Build
Idea Launch
Build
Learn
Idea
Learn

10. A failed idea is a
successful sprint.

11. When should you run one?
→ When speed and efficient decision making is required
→ To align a diverse team
→ To start a project with clear direction

12. When shouldn’t you run one?
→ The product is already well defined
→ Significant research is required beyond 1-2 days
→ The scope is too broad

13. How do you run a sprint?

14. → Facilitator
→ UX Designer
→ Product Owner
→ UI Designer
→ Front End Dev
Assemble your Cross Functional Team
→ Solution Architect
→ Business Analyst
→ Strategist
→ Marketer
→ Project Manager
→ Automation Tester
→ Interaction Designer
→ Middleware Engineer
→ Bus. Development
→ Acc. Management

16. Day 1: Map
Be thinking about the
service layer(s) required
to support the journey
map, especially when
things happen out of
view of the customer.
Developers

17. Day 1: Personas
Use the defined
behaviours, needs and
goals to think about
how we might treat data
within the product.
Caching? Offline mode?
Developers
Demographics Needs & Goals
Behaviours

18. Day 1: Problem = ...
Identify any last
remaining technical
implications from the
problem statement
discussion and create
your tech spike carpark.
Developers
Who is affected?
What are the boundaries of the problem?
When does it occur?
Where does it occur?
Why is it important we fix it?

19. Day 2: Sketch
Focus your solutions
on solving the technically
complex parts of the
journey map. Make sure
you are adding to your
tech spikes carpark.
Developers

20. Day 3: Critique
Be the voice of reason
about how ‘creative’ we
get with the UI. We want
a range of ideas, but
they need to be easy to
build & maintain.
Developers

21. Day 3: Storyboard
Developers
Be thinking about the
service layer(s) required
to support the
storyboard. Highlight
any major missed steps
or ‘leaps’ made.

22. Day 4: Prototype
Pick a new role! You can
help make the prototype,
stitching all the screens
together, be a
copy-writer, collect
assets for the prototype
or author test scripts.
Developers

23. Day 5: Test
Observe the testing
sessions run by the
facilitator. Note down any
major issues found,
especially where there are
technical implications.
Developers

24. What role do I play as an engineer?

25. As well as reducing the risk of poor
product fit with users, we are also trying
to reduce the risk of poor product
feasibility with engineers.

26. Launch
Build
Idea
Learn
Build

27. Go forth and sprint

28. Resources
→ Sprint Stories
→ Materials from the GV Team
→ The official Sprint book

29. Questions?
@reduxly