Our Design Process

Agile Development and UX Design working better together

Let’s have a conversation about…

• What’s been working

• What’s our goal?

• Where are the wrinkles?

• Ways to improve the process

What’s been working…

• Engineers exhibit more ownership of the design

• Engineers and Designers are communicating regularly

• Design and UX improvements are implemented quickly

• Engineers are more inclined to ask for design guidance

• Readiness testing on live product prior to wider launch

Goal: Validate our ideas

Validate our ideas the fastest, cheapest way possible

Building and launching a product idea is the slowest, most expensive way to validate the idea

There are wrinkly places…

• Transition from design to implementation is still a mini-waterfall

• User testing has to be a formal part of the process, with time built into schedule for fixes

• Design refinement is being worked out during the sprint

• UX has to balance constant need for micro-improvements and optimization within a sprint with big-picture thinking and discovery

• UI Debt (fit and finish) doesn’t have a home

Implement

Discover

Design

Current Design Process

Research High level user

flow

Paper TestWireframe

Stories

Visual and Copy

PlanAssess

Implement Live Test

Amazon and Ingram Design Board

Tracking design stories separately is a challenge

Early testing has to happen before implementation…

• Interviews

• Surveys

• Card sorts

• Paper prototypes

• Sketching

• Test competitor sites

• Clickable wireframes

When does engineering start? Find the switching point

Switching Point

Design Process

Refinement happens in the code between design and engineering

Problem-solving

Refinement

When can big-picture design work happen?

• Designers and other team members focus on design questions

• Can happen at the start of a scrum or anytime during scrum process

• When design spike is called, any work that can be affected by spike temporarily ceases

• Dev team members can move forward with work that is not affected by design in question

UI debt needs a home

UI fit and finish is not necessary for functionality, but has an impact on brand and trust

• Plan that whatever work we do will merit 10-15% fine-tuning

• Commit UI debt to getting done as a part of ongoing regular improvement cycle

• Consider admin panels as part of UI debt

• Track UI debt by tagging component as page URL or module so it stays easily visible and does not get lost in the bowels of JIRA

Formalizing a process: Dual Track Scrum

Cycle 0: Usability investigation activities that are foundational to project.

Includes research, analysis, contextual inquiry, persona work, high-level exploratory designs and testing

Iterate the design and implementation separately, but simultaneously

Proposal: Design Process

DiscoverPhase

TestTestDesign

ImplementRefine

User-centered stories Wireframes

Sketches

High level plan Clickable prototype

Interactive prototype

Formulate design patterns

InVision/ConceptShare

Invite-only site

Live site

Interactive design patterns

Component taxonomy (JIRA)

How

Create DSN story and sub stories

Add copy, visual, metrics, verification subtasks

Create WT story UI BacklogJIRA

Identify assumptionsResearch Add engineer as observer

Design and testFE engineer builds module

High-level KPIs

Steps Build, test and refine Tag UI debt

Post-test fixesVerify design

Appendix

Design phase and handoff

• DSN story is created so we can track until it is ready for implementation

• Story starts out broad

• "Observer" mode allows everyone to have visibility into the progress of the story even prior to implementation

• Testing, copy, visual, wireframes, metrics, etc can all be subtasks

During Implementation and beyond

When a story goes into implementation mode, how do we handle changes?

• Design Iterations: Any additional design iterations that happen post-implementation start are filed as a new bug or appended to an existing story

• Design Verification: A story is not finished until Design has signed off on the implementation

• Tracking UI debt: UI debt comes is identified as a bug or story, attached to the correct component, and added to the backlog for a future sprint.

• Tag components by page (URL) or a module within page so we can effectively find UI debt as we work on different parts of our system

When do we switch to implementation?

• We have investigated key assumptions

• Copy and visual are mostly defined

• We benefit from seeing the interactions

• The unknowns involve fit and finish

The design is the pattern and the code is the fabric…