Full disclaimer: this post was written by a UX designer.
Situation: A visual designer receives a set of wireframes and begins to apply the appropriate branding styles. Just as his work is complete, the UX designer sends an updated wireframe with an entirely new interaction in place.
Situation: A developer sees a designed comp and begins to code. She notices the use of radio buttons and thinks a dropdown would be better suited. After getting confirmation from the project manager, she implements the dropdown. Little do they know, dropdowns failed unanimously in user testing months earlier.
How can these situations be avoided?
We’ve reached a point where user experience design is no longer a luxury. Across every industry, companies large and small rely on their users to help define their products’ function, form and content. With a user-centered approach, companies also save money in the long-run. The “ROI of UX” has been proven in a number of published reports. If, for whatever reason, you still have to justify UX to a client or stakeholder, you can reference this infographic.
But taking a step back, these reports show how UX is valuable, but not how much UX is required to get to this value. Is there such a thing as too little or too much UX? Since these questions cannot be quantified, utilization of UX is inconsistent across projects. In some cases, a UX designer stays for the duration; in others, they provide temporary, quick-fix assistance. We need to be more cautious of neglecting or extending UX for too long as it can lead to negative outcomes.
At Cloudberry, we believe a dedicated user experience designer or researcher presence throughout the entire production process is critical in ensuring the needs of the user are voiced and considered. Omitting this role at any point can cause delays in delivery or, even worse, the release of a substandard product.
A “dedicated” UX role does not mean a full-time UX role. The challenge lies in mastering what level of involvement is needed and at what times. Successfully ramping UX participation upwards and downwards at precise moments is the key to a fluid design process.
While there is no one-size-fits-all solution, here is a visualization of ideal UX involvement:
Click for more detail on the responsibilities of UX during these key moments.
Again, it is important to emphasize that this timeline is the ideal state. What are some common reasons for why UX is not involved enough?
Over-reliance on the handoff
An assumption that completing the UX deliverable fulfills the UX requirement is incorrect. The most perfectly annotated wireframes and interactive prototypes only focus on functionality. They do not list the rationale behind why these interactions were applied. Handing off and then completely falling off may result in the altering of certain decisions which had very specific user-driven intentions behind them.
Availability issues or others in the role (BAs, PMs) as substitutes
We’re all busy and have plenty of challenges to solve. So once the primary UX phase of a project is completed, there is no issue with passing ownership to a new party. But completely removing the original UX designer also removes the extensive, intangible knowledge that is extremely difficult and expensive to transfer over.
General concern that too many cooks in the kitchen constrain progress and creativity
Again, UX involvement does not need to be the authoritative voice after their deliverable is completed. By taking the role of a UX advisor, designers and developers can depend on consistent feedback to take informed next steps. Chiming in when needed to provide context around user research or testing will directly prevent wasted efforts.
What are some common signs that UX is too involved?
Neglect of business needs
When the balance is clearly tipped more in the favor of what the user wants over what the business needs, a product or service will also likely fail. The UX designer should be a participant in the business requirements gathering phase but more as a listener or advisor rather than a lead contributor.
After the “Experience Design” phase, wireframes should be in their final state. Sudden changes of any size will have repercussions on the progress of future stages and also will cause great frustration and lack of trust from the other collaborators. There needs to be a clear stopping point where the direction is clear and final.
How is it possible to balance UX involvement appropriately? Here are some tactics that have worked well for us and our clients:
- Use the right tools
Software such as Zeplin and InVision allows us to communicate across teams, assign and re-assign ownership on pending issues and give access to the most up-to-date designs in a persistent web-based location. Even when an issue does not directly affect the UX resource, they are alerted to status updates and can take action if and when it’s needed. Transparency is advantageous to all involved.
- Email aliases and team projects
Transparency also extends to emails and phone calls. By pre-defining a list of participants and sticking with that list no matter the subject, assumptions about who should and should not be involved are avoided. If a message is irrelevant or aligns with the strategy, there is no need to respond. Miscommunications and surprises later, as a result, are kept to a minimum.
- Scheduled check-ins
Keeping a recurring time slot on the calendar for status check-ins also ensures that collaborators are kept in the know. The primary presenter during these check-ins can alternate. When UX is presenting, they share learnings around user research or testing to all involved: stakeholders, developers, the more the merrier. Allowing for an open discussion after a presentation is particularly enlightening.
Coordinating involvement levels of multiple players on a large project is a very challenging thing to achieve. Business objectives will always be top of mind but the user needs can very quickly be overshadowed when someone isn’t there to campaign for them. The UX specialist is the only one to represent this large and powerful audience base. Removing the role can then have a major impact on the ROI we all crave.
We’d love to hear your thoughts on challenges you have had with keeping a consistent UX resource on a project.