Application teams work to differentiate themselves from their competitors by introducing UI embellishments into their products. The wow factor from a stunning UI can lead to positive brand impressions, which in turn build trust and drive conversion.
Despite being a highly creative and rewarding exercise, UI design is only part of a UX’ers responsibility. Resources must also be devoted to developing personas, user journeys, and evangelizing for usable workflows. More still, a UX designer needs to work closely with development teams to make product language consistent and ensure all front-end development work aligns with established design system patterns.
This last responsibility (aligning established design system patterns) can go by many names:
- UI Audit
- UX Review
- Design Review
- Implementation Review
I prefer UX review, but whatever you call it, UX reviews have a huge impact on product consistency. Fortunately, it’s easy to optimize these workflows to free up time for other UX work.
Study Dev Team Workflows
A sprint Kanban may look something like this:
- To do
- In progress
- Code review
- QA review
- In Test
- Ready for merge
- Done
Evaluate your sprint workflow to determine where a UX review would have the best impact on final outcomes. Ideally, UX reviews should take place before QA reviews. This gives developers the most freedom to update code without needing to repeat steps in the sprint. Perhaps more importantly, it’s another opportunity for you to learn about your product while considering a persona’s goals.
Give developers the most freedom to update code without needing to repeat steps in the sprint.
Tweet
The location you choose in your team’s workflow is not final. Make changes as needed, but avoid making impulsive selections – weigh pros and cons before updates are put in place. Wherever your UX review currently is, use the recommendations in the sections below to free up time in your day-to-day for the other creative solutions your product needs.
Create Templates for Communication
Structured and consistent communication is the key factor determining the success of a UX review program. UX reviews generate a lot of documentation. Because developers already spend a great deal of time in documentation, when they encounter feedback from you, they need to identify the action items, implement changes, and move on.
Some developers will be responsive and share progress updates readily, with others, you’ll spend much of your time in the dark.
Templates are an easy way to introduce consistency and professionalism. You should have two goals in mind when creating a template for yourself:
- Frame the review
- Orient the reader to issues
Developers work through a lot of stories. Don’t assume they will open a page and immediately know what it is you’re about to tell them. To properly frame a review:
- Create a title closely tied to the developer’s work
- State the date and time
- Note the acceptance criteria
Once framed, the reader can understand the scope of the UX review and is ready to focus. Quickly orient the reader to problems that can fall in one of these two categories – issues with acceptance criteria or style irregularities. A simple IA is best here to outline each problem:
Acceptance Criteria No.
Status
Reason for rejection
[screenshot of the error]Solution
The solution can be provided in several ways
- Description
- Screenshots
- Links to design systems
- Linkings to story-level mockups.
When developers encounter feedback from you, they need to identify the action items, implement changes, and move on.
Notify the Development Team
Jumping ahead a little bit – to when your template is complete and you’re fully integrated into the development team – it’s time to take action. When you see a story update on the Kanban board from In Progress to Code Review, notify your colleagues with either an instant message or a status update during daily stand-up. Your team needs to know what you’re reviewing and be prepared to address the issues you identify.
Request Updates
Everyone has different communication styles. Some developers will be responsive and share progress updates readily, with others, you’ll spend much of your time in the dark. When you feel out of the loop, politely ask for an update and give encouragement on the good work thus far.
Perform Final Checks
After receiving confirmation that issues have been resolved, perform one final review to confirm that all issues have been fixed. Sometimes UX reviews identify issues that cannot be resolved within the scope of the current ticket. An issue could be too large to resolve because it would necessitate a global style change that needs further research, or because you’ve identified a separate, unrelated problem.
Be sure that any issue you found during UX review is marked as resolved or that a follow-up ticket has been added to the backlog.
Summary
UX reviews are an important part of sprint workflows. To implement a UX review process in your organization
- Study dev team workflows
- Create templates for communication
- Notify the Development Team
- Request Updates
- Perform Final Checks
Have you had success with similar or different practices? Please let me know what advice has worked for you.