BlogWhat is Dev-ready UX? (part 1)

We throw around this term Dev-ready UX at Planorama, but it has real meaning because most of us have seen what happens when it’s missing.

When someone mentions Product design or User Experience (UX) design, we understand the focus is on the users of the application – how they will interact with it. Intrinsically we know that the users are those other people…the people we’re building it for. The application’s UX should be intuitive, and guide them efficiently towards their objective.

However, another set of people actually have to build the application: the dev team – solution architects, front-end developers, back-end developers, QA, devOps, etc. For this first article installment, let’s talk about delivering the UX and documentation (user stories) that also aims for intuitiveness and guiding developers towards efficient building of the application.

Delivering user stories with developers in mind

Many companies adopt a user stories structure to capture product requirements documentation from user-centric perspective (and/or technical stories from a more system-centric viewpoint). User stories and UX are, or should be, joined at the hip since they both communicate how the features should function when completed. In fact, they are so intertwined that at Planorama we embed the UX designs into the stories.

At a minimum, user stories should have a narrative (“As a …I want to….so that I can”), and acceptance criteria (“user must be able to….”). The narrative paints the picture for the developer and establishes some empathy: a view of what the user wants to accomplish, and why. Acceptance criteria communicates to the developer and QA what success looks like for this user story; what the user should be able to accomplish after this functionality is implemented. Glossing over either one isn’t recommended, though glossing over acceptance criteria means you’re loosely defining success for devs and QA, and can result in changes later which may have been avoided with better definition earlier.

Getting specific with user story scenarios

Beyond the user story minimum of a narrative and acceptance criteria, we have found that including scenarios by far ensures the developers have the details they need to build what we design. Our scenarios are written in a “Given…when…then…” format to describe the user’s paths in that user story. I say “paths” because there’s at least one path – the happy path – which covers the most straightforward, most efficient usage of the feature. However, there are probably also exception paths which should be detailed as well. For instance:

• What happens if the user enters garbage into a text field?
• What happens if a required field was left empty?
• What happens if the server is too slow to respond to an API request?

By thinking through all of the scenarios early in the user story development, when delivered, the developers will not be left to guess. Developers want to develop, and not stop for incomplete requirements.

Documenting motion design

As animations and motion design is becoming more prevalent in software products, we also find it helpful for UX to create animations for developers to show intended motion behavior…which otherwise is difficult to write into a user story. We include the animations in the user stories themselves, and ensure the frontend developers sign-off on it before UX is complete. After all, animations are fast to design, but if too difficult to implement, we can discuss alternatives before the dev team receives the final user story.

Read the second installment of this article.