Don’t call it a code handoff – user stories

This is a continuation on last week’s post Don’t call it a code handoff – design styleguide where I outlined the styleguide as the meeting point for designers and developers. What else is needed to communicate and clarify what to build?

A clear user story gives the why

A clear user story is written to describe what needs to be built. It must have a description of the feature, designs to show what it looks like, and an explanation for how it behaves.

As a [user role], I want [feature/action], so that [benefit]

The user story/ies gives the developer the “why”? That why is the reason for the feature, and as such it helps them see what the user needs, and they can help add design input. How might we help the user do what they want, from a technical perspective?

Design shows possible states

The finished design, aka the end result, is often the first thing that gets designed, but what happens before and after that state? What happens when it has no data? These are all things to consider in your design and to clarify so developers understand.

These are the terms through which developers see the world.

Design the error messaging and workflow so devs understand how the feature works, end-to-end. They want the user to have a great experience.

Design and Development is a cycle

As development kicks into gear, things can change! If not caught during design discussions, it will come up during functional and automated testing.

Whoops! We missed something.

Dead ends happen. Roadblocks happen. This is normal. In fact, leave time for it for any feature you design and build. Go back to the user stories and refine them if they are not clear or specific enough. This is what Design Thinking is all about. Constant iteration of the Discovery, Design and Implementation double diamond process.