Share:
Over the past few years, and in my role as Product Practice Leader at Callibrity, I have observed the practice of UX start to feel like more of a performance. Running extensive workshops, endlessly creating and focusing on unnecessary assets, and spending more time on toil over clarification.
In the past five years, I have noticed more fluff in UX practices. There has been a lot of time “taking people along on the journey,” focusing on “telling a great story,” and attempting to incept stakeholders to think that our ideas are theirs. I call this practice “UX Theater.” While I admit there has always been a little dog and pony-ing in the practice, recently, it feels like we are laying it on thick.
Have We Lost Our Way?
The goal of UX is to understand and define what a product will be and continue to clarify and increase confidence in the product’s purpose through its launch. This happens through documentation and the creation and iteration of assets. The assets that a UX Practitioner produces should be purposeful. The UX process is a guideline and a set of tools to choose from, not a prescriptive set of instructions. We should only be creating assets necessary to define the product, not just a checklist of activities to perform over and over to fill time and a binder of deliverables.
The assets we create serve two purposes:
- Clarify the product or feature to be built.
- Visually communicate project goals, requirements, and gain stakeholder buy-in.
UX should be lean, focusing on essential research and assets to ensure high-confidence recommendations for building the right product.
The Main Offenders
The biggest offenders in the list of unnecessary assets are day-long workshops, personas, and journey mapping.
Day-Long Workshops
Workshops are helpful ways to engage with stakeholders, capture information about what they want from the project, and build alignment and relationships with them.
What I have been seeing lately are people scheduling a lot of full and multi-day workshops. These are a burden on everyone’s calendar and problematic if crucial stakeholders can’t participate the entire time. I’ve also seen the guest list for workshops grow to involve everyone related to the project, inviting everyone to give their opinion.
Workshops are most efficient and easier on everyone’s calendars when they are kept to 50- or 80-minute engagements. A lot can be captured in a short amount of time, and if more time is needed, schedule another hour-long session. I have found that more projects benefit from two or three hours of workshops. Keep the list of people invited to only stakeholders and critical players in the project within the first few weeks, usually around 4 to 6 people. Your role is the facilitator, and at this point in the project, it’s not to get buy-in on your ideas but to capture and document everyone else’s. Start by creating an agenda, sharing a whiteboard with the team, and leading the meeting—keep it succinct and on track.
Personas
Understanding who you are creating for is essential to what we do. Personas can be helpful, typically on large-scale products with multiple user types. They are created based on user research, like user observations and user interviews. They should never be a recreation of an actual individual but as a summary of a specific user type.
Personas allow UX team members and the rest of the team to humanize the users, who are surprisingly less thought about and considered as the product progresses into the build phase. As a team, we can discuss what “Malcolm” would do differently than “Charles” as a shorthand for user types.
What I have seen personas become is a failure of process. Personas should not be created like characters in a book, wholly from the imagination of the person creating them. If they aren’t based on research and actual users, they will serve no purpose in the project. The exercise of creating personas can be helpful to a UX practitioner to get to understand better who the user types are through summary.
Don’t waste time on personas for projects where everyone involved understands the user or there are only one or two user types. Simple archetypal write-ups, essentially the short-hand of personas, are just as beneficial without the extra effort and gloss put into persona creation. Most of the time, all that is needed is a bulleted list of use cases defined from a user meeting. And if you do create personas, don’t spend more than an afternoon creating them.
Journey Mapping
Journey maps are a method of telling a story of how multiple users will interact and feel throughout the engagement of a product. They are most helpful when defining the experience for a physical space, like a coffee shop. Let’s say you have several user types defined in the process: two types of customers (pickups and lingerers), two types of baristas (counter and creator), and a manager role. The journey map allows you to chart out what each user is doing based on observation through each step of the progression of a goal like “buying a cup of coffee.” Process times and the emotions of each user type are charted across a timeline.
Journey maps are helpful to inform an audience who may not understand all of the user types, to call out areas of improvement, and are really only valuable when there are vastly different user types engaging with your product. Once journey maps are created, they will live in the product’s documentation until a product has been refined and used to compare: “This is what it was before, this is what it is now. Are the users more satisfied?”
I have seen journey maps being created conceptually instead of based on actual real-world observation of user types in action, charting a summary of what the users are doing from step to step. If you are just making it up from your desk without engaging with your users, the resource will have little to no value.
What I have also seen is journey mapping becoming a replacement for creating user flows. These are two separate assets with two different functions. Journey maps are to aid in communicating pain points and tell a visual story to stakeholders, typically focused on a single use case. User flows are created to document or conceptualize a complete product and all the possible interactions and user cases involved in the product. Flows allow you to visualize the product, communicate to stakeholders the vision, and collaborate with developers to refine the user flow to act as a roadmap to build the product.
Journey maps created for smaller products, features, or products with only one or two user types end up flatter and communicate very little. For projects like these, creating journey maps is a waste of time both in creation and iteration, and they can take away valuable time from stakeholders and team members, to do presentations and walkthroughs to get buy-in.
Stop the Theatrics
As the UX practice starts to be looked at more as a performance, the easier it is for business and product teams to dismiss what we do (we are already combatting being looked at as just making things look pretty). Help to combat this by only creating the assets that need to be created. To understand what those are, know what tools you have available to you and take a step back to look at what deliverables will help you to make sense within the ambiguity of the product.
Be thoughtful of others’ time, reduce the number of workshops and meetings, and only include the people who are absolutely necessary in the room. Limit weekly share-outs to essential information and allow your documentation to speak for itself.
As a practice, we must consistently show value and progress to be taken seriously. This is best done by keeping deliverables lean, only focusing on what will increase our (and our team’s) confidence level in the product requirements. As we cut out the fluff, we can move faster, and save time and money for clients.
To learn more about how Callibrity can help your organization, email us at contactus@callibrity.com to schedule a time to connect.
.jpeg)
