BlogWhat is Dev-ready UX? (part 2)

In this part 2 of this article (see part 1), I will round out the conversation about Dev-ready UX.

Process: Marrying design & development

We know what software development process means, though each instance is different. Every company and every team defines and evolves their own variations, even if derived from well-accepted patterns. Though each may be unique, two attributes common to any mature software development process are promoting a regular flow of communication, and establishing repeatability so expectations are set within the project team. When team members know what to expect and when, there is confidence that each member can focus on their respective responsibilities.

For us, our product design sprints run alongside our client’s development sprints, and enforce communication by nailing down two touchpoints per sprint to formally solicit development and QA feedback. We absolutely need their involvement in the design process, but without taking too much time away from their own day-to-day efforts. Our mid-sprint review and end-of-sprint review meetings occur in each product design sprint. Hosted by the product design team lead, we demonstrate the UX designs and flows created for each feature planned in the sprint. In our end of sprint review, we demo the final designs and user stories with detailed scenarios that will be delivered into the development backlog. Development, QA, and stakeholders join each meeting, and provide feedback that we incorporate into the UX. While communication may certainly occur outside of these in-sprint touchpoints, these meetings guarantee it happens collectively at least twice per product design sprint.

We conduct our product design sprints in the same format, sprint over sprint, yielding the repeatability that other teams in the project rely upon. Each design sprint we peel off the highest priority feature areas from the project’s scope, creating the UX designs according to the features’ initial user stories and discovery with the client, and host the two review meetings to showcase our work. By the end of the sprint, every developer and QA engineer (a) has given feedback, and (b) has seen the features well ahead of time. This is crucial to set their expectations, so when the development sprint begins that includes a feature, they’ve already seen it. It’s never a surprise. The more notice we give to the dev team about features coming down the pike, the better able they are to develop it correctly when it’s their turn to execute.

UX Acceptance Testing

There’s nothing like seeing the designed experience implemented in software. Just as we include the development and QA team in our product design sprint touchpoints, we also join the development team’s end of sprint review meetings to see the final features implemented.

Especially when building new features upon previously implemented features, product design team reviews the complete experiences to (a) ensure the design was implemented as intended, and (b) review whether the new overall experience is as fluid as we expected. We call this effort UXAT (User Experience Acceptance Testing), and it happens after development releases features. Our designers review the features and if necessary file design tickets for any design tweaks, and/or file bug tickets for dev when the implementation do not match the design.

Note that UXAT does not replace an overall QA / testing strategy for the software implementation team, but rather it is a component of the strategy. UXAT will not comprehensively verify acceptance criteria, but validate the designed experience works, and primarily use that feedback for our own self-refinement and betterment of the product.

Design System

The concept of a Design System was born in recent years, formalizing many previous necessary UX deliverables to stakeholders (including the development team) as a unified deliverable.

One piece of a Design System that is very important to the product is the style guide because it defines the visual consistency throughout the application, such as typography, colors, logo, iconography, etc. The style guide deliverable is vital for front-end developers: if we want developers to spend their time developing and not questioning how something should look, the style guide answers those questions before they are asked.

Likewise, as user interfaces today tend to leverage component libraries, this should also be included this as part of the Design System deliverable to the development team. Selection of which component library to use is a choice based upon many factors, and consulting stakeholders (including the development team) is wise. The result though is an agreed-upon set of UI components which the product design team will use in their designs, which are then implemented by front-end developers. Both the design and development teams become more efficient during the project.

Wrap up

 Concluding this two-part article, when thinking about Dev-ready UX, consider:

• User stories with acceptance criteria so development and QA know what to measure the feature against
• User story scenarios that provide developers all the positive and exception paths for a feature, with accompanying UX designs for each
• Animations that show developers how to implement intended motion design
• A product design process that regularly includes developers and QA engineers for feedback and notification of what’s coming up
• Involving product designers in review of the implemented software from the dev team
• Delivery of a Design System that helps developers move quickly and be consistent with standard styles and components.