Reducing UX debt (or die trying)
Product people should be less concerned with delivering new features (maximising) than with reducing UX debt (optimising). Poor, unresolved user experience is what drives away customers and destroys team motivation and commitment.
UX debt refers to known user experience issues that have not yet been fixed. These unresolved UX issues lead to inconsistent and ineffective user interactions that lead, in turn, to business loss.
UX debt is also all the design work, optimisations and cleaning, that the team didn’t have time to do —or do well.
Ironically, agile teams are not spared and are even particularly prone to generating UX debt due to the increased pressure to deliver new features on a regular basis or degrade a feature to meet a sprint deadline.
I won’t talk about the UX Research actions you might want to take to ensure your product meets — or even exceeds — users’ expectations. I’ll talk about the debt due to poor internal processes and lack of communication within the team.
Here are a few ideas I am currently exploring in 2 different contexts
- Try (paper) prototyping with developers
- Do not compromise on the quality of your atoms
- Structure your UX libraries to enforce modularity, heritage and sunsetting
- Enforce UX governance and rituals
- Document & track the gaps
- Make debt reduction the responsibility of the largest team
1. Try (paper) prototyping with developers
The biggest source of UX debt is the separation between design (the intention) and the programming of it (the execution). It’s not the specifications that are put into production, it’s what the developer understands of them. This gap is very well explained here. One way to reduce it is to have regular design sessions with the developers.
Most designers don’t like to host live design sessions. Although exploration is part of the design process, we don’t like to show how we fumble before figuring things out or how messy some of our process can be. Also, live design sessions tend to end up by putting draft designs (and not masterpieces) into production. Especially if the sponsor attends them.
But it’s entirely possible to live-design with the developers, so that we share the same understanding of features, space layout and interactions.
One way to effectively design together and make it shameless is to do paper prototyping: it’s easy, fast, cheap, straight to the point and inclusive. Everyone can paper prototype. Also, paper prototyping is widely use nowadays not only for application interface but also for game design and even prototyping physical objects.
Developers can paper-prototype too: they bring their experience and technical knowledge of the stack to the table. They also realize that the design job is not so trivial: paper prototyping builds mutual empathy and alignment blazingly fast. In a very short time (30 mns is usually enough) you will draft together the overall intent and principles of your design without drowning into unecessary details.
2. Do not compromise on the quality of your atoms
Chances are, your are applying the principles of Atomic Design created by Brad Frost. If you listen to Brad himself, he conceptualized these principles precisely to bridge the gap between design and code, to find the sweet spot between the two.
As a designer your main mission is not to produce more screens but to check the robustness of your components in the Design System, ensuring that both other designers and developers can work safely from the DS.
Take this label component for instance: it does not adjust to the size of its contents.
- all its variants are defective, and therefore all the components containing them as well 😢
- I will have to redo this component (in the core lib or in my child lib) 😤
- If I can’t push the new version in the core lib (say I’m not allowed to), I will have to document why there are now 2 comps (the broken one and mine, in a child library)
- once the author of the lib has fixed its component I’ll have to switch back to it, changing all the references of my instances to point to their updated lib 😫
Produce less, check more
- Check the robustness of your atoms: corrupted atoms will be assembled into corrupted molecules that in turn will make corrupted organisms.
- Components you have to particularly check frequently include : buttons, labels / tags, tabs, inputs, accordions.
- Only a few qualified people should be able to push modifications to atoms.
3. Structure your UX libraries to enforce modularity, heritage and sunsetting
Debt is like clutter, if you want to reduce it you have to get rid of things and clean up regularly. Like Mari Kondo in your UX libraries: throw away, sort and structure.
In Figma (paid versions) you can cascade libraries. That allows to build for modularity, heritage and gracefully sunsetting components.
Modularity (building for both genericity and specialization), heritance (building on top of what’s solid) and easy sunsetting (decommissionning) is what allows you to manage entropy and clutter. Here is an example that could work for most projects, whatever their size.
- Core lib: should contain the subatomic definitions aka tokens (styles, color variables and themes, elevation and radius variables) and the triple-checked atoms (buttons, badges, menus, switches, tabs, etc.). It can also contain small molecules that are vastly used such as search bar, menu, header.
- Extended library: inherits from Core and extends it. Contains molecules, organisms and templates (modals, filters, cards, accordions, etc.)
- Icons library: I usually put the icons in a separate library so that any product of the company can easily import it (to ensure branding consistency) without having to suffer the whole weight of the entire design system
The Figma part of your Design System can then comprehend the Core Lib, the Extended Lib and the Icons Lib. All three shall be meticulously curated, annotated and guarded by the UX core team —or by a person I call the UX Dictactor. The UX Dictator is the person who takes responbility for any change in the Design System. Which leads us to UX governance.
Take a look at the very interesting takes of Inayaili de León and Brad Frost (who built on top of Inayaili’s ideas) on UX Governance.
4. Enforce UX governance and rituals
Designing is not just composing in Figma, it’s communicating clearly on the structure, problems, context, intent, leads, constraints and solutions to everyone in the Product team. It’s also deciding which components should be created, improved or removed.
To achieve great back and forth communication, I strongly encourage you to set up UX reviews. One hour per week is enough to bring 90% of the value of this ritual. It’s the best thing you can do to lever the one weird trick for success.
The purpose of a UX review is to
- talk about user interactions and answer questions or raise concerns
- review and share UX Research and UX production, critique the designs and find better ideas
- while reviewing the designs, discuss changes needed in code to meet the design — or changes in designs needed to meet the code
- mark elements for cleanup and improvement
- track the gaps between the design kit and the code
It’s even better if after the review you send an email / slack / whatever-works-for-you with: wonders (unanswered yet questions), answers (to previous questions), decisions and follow up actions.
5. Document and track the gaps
If you don’t document changes and decisions around the design system, you won’t be able to scale UX in the organization.
In the absence of something like Storybook (often difficult to maintain) you can use little things to document the DS for POs and developers.
- Annotate with plugins like this or this to annotate the components
- Use descriptions in dev Mode particularly for more complex components (cards, filters, etc.)
- Care for mandatory and explicit commits in Figma when you publish a library so that other designers know what you change and can confidently update their prototypes.
- Use versioning to declutter. Regurlarly throw away deprecated or unused variants and version it (you can use plugins like this one to find if a variant is in use anywhere). Use meaningful commits (e.g. “version 2.3 comprising new standardised cards, new button variant X and bug fixes for variant Y”). With precise versioning teammates know there is only one up to date version : the current one.
Decluttering your design allows your teammates (UX or dev) to update their designs / code regularly without trembling with terror at the thought that the update will blow everything up. Also, Figma now supports branching, so you can explore different design leads without compromising the main file.
Bridging the gaps
The gaps between the designs and the actual code (the CDK) is inevitable and part of the UX debt that every team has to live with. Very often it is never resorbed but that doesn’t mean you can’t try and control it.
I started with a simple excel file listing the gaps between what’s in the Figma libraries, what has been implemented in the CDK, what’s missing here and there, what needs to be updated, created or deprecated.
We also have dedicated tickets in the UX board, with simple labels (vital / irritating / cosmetic) so that the UX team can regularly address those gaps and push the improvements in the DS.
6. Make debt reduction the responsibility of the largest team
Here are 3 observations I find fairly widespread in the organisations I work for
- there are far more developers than there are designers. The average (optimistic) ratio is 1 designer for 5 developers in a team. But most of the time it’s a 3-person UX team spread across 5 development teams.
- developers tend to generate a good amount of UX debt (because they lack time to communicate enough and because they are pressured by the pace of sprints)
- yet it’s still up to the UX team to keep things up to date, neat and tidy and prevent the debt from growing…
What could possibly go wrong 🧌 ? How can one designer tame the entropy generated by a whole team?
Try to find a workaround that always places the responsibility for debt reduction on the largest team. If you have more developers than UX people then developers should always implement the latest versions from the Design System : it shouldn’t be up to the UX team to maintain 5 versions of a given component because 4 dev teams failed to update it. Seek an agreement with Product Owners about that so that they allocate time debt reduction.
To sum it up, UX debt is mainly created by the desynchronisation between design and code. The only cure is more communication, more documentation, more hand in hand work. I hope you will be inspired by these workarounds, and that you will find winning strategies to less debt and more time for consistent design.
