Why UX sessions don't work?

1) Lack of context

What is context and whose context?

Context is defined as "the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood."

The goal of UX is to ensure that the user's (guys who will use your software) goals, the buyer's (guys who will purchase your software) goals and the enterprise's (mostly your own team who will sell this software) goals are met. The goals for each of these three parties can't be met in isolation, they have to be met in the context of the goals of other two parties.

For B2B (Business to Business) scenarios, the product usually goes through a pilot phase with power users (selected few), where the functionality is far more important than aesthetics at this initial stage. This is even more critical when the new system intends to replace or complement an existing system and as such, UX is required to ensure a seamless transition for all users, redefining their old habits with this new product.

Examples of context

Usual examples of context which are taken into account when assessing UX are:

• Different user roles
• Different browser/device/OS/form-factor support
• B2B / B2C (Business to Consumer)
• Out in the field / Back-office
• Different skill-sets and motivation levels of the current user base (and the availability of such a user base)

Why is context important and how does it drive usability?

When so many different teams and stakeholders are involved, it becomes important to prioritize which problems to solve and in what order. One such formal artifact that incorporates these details is a Product Roadmap. When this artifact become a basis (or gospel of truth) for deliverables from multiple teams in a single organization, adding all the minor details from an end-user and buyer's perspective to the overall context, becomes very very critical.

Let's take an example

Feature - Clean a meeting room desk

Problem statement - Clean the desk in an efficient and cost-effective manner

Bare minimum context -> The desk is polished wooden furniture. Meeting rooms don't have a drainage system and they have fans. Meeting rooms are mostly used for business and team meetings. The kind of stains usually found on a desk is either tea, milk, water drops or marks from pens.

Possible Solution -> Cleaning staff to use the cloth wipes with simple disinfectant liquids

Adding more context (by an End User) -> The desks need to also support workstations for employees. Desks may have different kind of stains so they will need washing once a week and wiping every day. Not cost-efficient and time-efficient to turn on the fan of every meeting room and having to constantly check if the desk has dried.

Possible Solution -> Desk to have wheels so that they can be pulled to a common area of the floor where they can be washed and dried.

Adding more context (End User again) -> Washing not possible on every floor.

Possible Solution -> Desks are to be foldable and light so that they can be carried to a common place for washing and put back.

Adding more context (Business context) -> Limited cleaning staff. Employees may also work throughout the week on the same desk.

Possible Solution -> Desk to support a covering sheet which can be peeled off from the surface and be replaced with new one every week.

Adding more context (Enterprise context) -> An enterprise needs 20 desks for their 20 meeting rooms for a new building. The Enterprise wants to start operations within 3 months. The desks are to be only used for meeting purposes. Workstation support has not been asked for. Your enterprise already has existing desks without workstation support.

Possible Solution -> Give a list of the desks you have, take feedback, understand the context and decide next step.

As you get deeper and closer to the user's and buyer's context, a solution which looked optimal otherwise isn't so usable anymore. Unless you are making these desks on order from someone as a custom request rather than your own product offering, you must provide the specifics for the different contexts that you want to support (or claim that you cater to them) as a product team. So the function and usability for that particular function depends on the context as well as understanding these details for optimal prioritization.

2) Product Manager or UX specialists

The Gulf between the two...

For most UX specialists (that I have met) understanding context goes only as far as defining different user-roles. Different user roles for a lot of domains such as supply-chain management have already been explored and are well documented. Why is it then that we can't find a good critique (or just a report of possible improvements) of existing solutions in this domain on the Internet? Since the core features, functionalities and the user roles for such domains are already defined, there must be more to defining context than just this. On the other hand, to be fair to a UX specialist, domains like supply-chain management already have products in the market and yet new ones are being built, rejected, improved, maintained and re-built again and again.

Product managers (especially senior ones) are typically closer to the client and have a better understanding of the context. They are good at finding pain-points, possible draft-level solutions for those pain-points and opportunities to drive more efficiency, but they typically lack being able to define a marketable, professional looking solution.

This is where the gulf between a product manager and a UX specialist exists. The issue has only widen with UX professionals demanding a seat at the table even when product managers are just conceptualizing the story to sell. Product managers may lack the UI (User Interface) skills, but UX professionals are lacking the skill to analyze the existing solutions and comprehend the amount of impact it had on the user's habit.

For example, imagine a user whose job involves keying in prescriptions that arrive on email, into another system. The existing solution allows the user to split the screen in half with one half showing emails (with navigation) and the other half having the form to key in data. A UX professional may argue that these "nitty gritties" may get caught and ironed out during the user-testing (A/B testing) stage, however, these could have been identified by analyzing the existing solution rather than delivering the same feature (of being able to fill a form in a split window) in a new development cycle.

Who should drive who?

More importantly - how to segregate their areas of responsibility? At what stage are UX experts brought in and what input should be given to them? Should those inputs be specific or more abstract in nature? Do they need a mediator between them?

I doubt if anyone would argue against a product manager driving the whole show or have the final say in the module they are responsible for, but are they skilled, competent or experienced enough to give inputs to the UX team? Given they already write specifications for developers, are they willing to write one more document for the UX team? It's quite likely that UX experts would just read the specification document (intended for engineering team) and deliver based on the content therein. However, that document requires the inputs from the UX teams before they are delivered to engineering team. User stories were supposed to bridge this gap but since user stories need to be groomed, this simply created another opportunity for more never-ending exchange of ideas.

These days UX teams are an important stakeholder (their approval is sought) for assessing release-readiness. This has aggravated the problem even further. With UX teams given leverage to stop or delay a release till their inputs are incorporated, it has become harder for product managers to prioritize more important features over UX inputs. Mostly this results in bypassing UX approval, thereby missing the entire point of having UX approval as a part of a release-readiness report. When this becomes the norm, UX teams feel unmotivated and leads to a drop in team moral.

3) Enterprise's lack of experience in using UX specialists

How to interpret client/customer feedback as UX feedback?

A lot of times, intentionally or unintentionally, customer feedback doesn't reach the UX or engineering teams. Product managers do their best to ensure that this feedback is converted into action items with corresponding specifications that are refined before passing on in their organization. The feedback process usually involves direct and indirect communication and possible arguments with clients or end-users. It makes sense for the product manager to mediate this discussion to ensure that the client's interest is aligned with the end product. Assuming that product managers are involved in pre-selling, demos, enhancement discussions, etc. with the clients and that they have a business background, they are better equipped to front these efforts.

However, a UX expert may argue that a user's feedback is also a response against the current design and experience, so an untouched version of the feedback, along with rest of the business context, would be far more valuable to them than any such refined and narrower-scoped action items. They may also argue that while a product manager is better equipped to understand the user's context, a UX expert will be better equipped to see the end-user's feedback as a response to their UX design and hence see this UX feedback as a way to derive different kinds of insights for which a product manager typically cannot.

How to set the accountability?

A lot of organizations don't have much of a clue on how to set accountability on a UX team. This is also a manifestation of an organization's lack of understanding of UX metrics in the first place, which is why detailed UX metrics are not even defined when the project is initiated. Sleek looking aesthetics, response time, keyboard-driven form-filling, Right-to-left support, adherence to brand aesthetics, etc. are some high-level UX metrics. However, these metrics don't make a UX designer accountable for user-complaints like these (not exact verbatim, just the essence) - "I was able to fill 200 forms in a day with older app earlier, now I can only fill 50!" or "Data doesn't refresh on dashboard automatically and changes are not highlighted".  

One good reason why users are reluctant to let older UIs go even though the newer UI is far better looking and is more feature rich is precisely this - UX experts are not held accountable for ignoring the existing user habits.