Prepare, shelve, reveal (don’t push) — an in-house product design tip
Have you ever tried to raise a concern about a usability issue, only to be met with a silent nod? — a question for in-house product designers working on business-to-business software.
Does any of this sound familiar:
“The navigation has become too convoluted; we should redesign it,” or “Users are overwhelmed by the number of features; we should reduce them,” or “The user flow broke due to the latest changes; we need to refactor it.”
Then, many months later, you suddenly receive a task related to an issue that stems from one of your earlier warnings. If only, instead of spending that time trying to get buy-in, you had prepared a detailed solution proposal* back then. That way, you could simply present it now. 
Of course, what we really thought was,
“But first a deep sip from a very tall glass of ‘I told you so’.”from Rick & Morty by adultswim
(but we won’t tell anyone)
The Roadmap and the Backlog
No, your warnings are not ignored because they are seen as wrong or because no one believes them. Nope. They are simply ignored because there is neither any room in the roadmap nor in the backlog. And since these are mostly front-end related concerns that, on paper, don’t add immediate value to the sales department, they remain under-prioritized.
Sometimes, it might even feel like a design improvement proposal needs to involve backend work to be taken seriously**.
More backend — more epic.
So, until there is a task in the roadmap that overlaps with or is caused by your usability concerns, don’t waste your time trying to push or explain them to the rest of the organization.
If it’s not in the roadmap, it doesn’t exist.from the Tick!
The Tip
So, you can either keep banging your head against the wall called the roadmap and its backlog, or you can prepare an initial solution proposal and shelve it until the time comes. And believe me, if your concern is valid, that time will come.
Follow these simple steps:
Retreat to your desk.Gather all relevant user feedback and previous research that support your concerns.Prepare an initial document describing the issue and potential solutions.Create a few design drafts to support your proposal.As a bonus, start mentioning these usability concerns to fellow developers, but not yet to the roadmap decision-makers.
The key to getting your usability concern resolved is to have leadership believe the idea came from them. Once they take ownership, they’ll add it to the roadmap.
Instead of trying to push usability issues onto the roadmap, spend your time preparing the solution proposal. Set it aside, and reveal it when a relevant roadmap item is finally raised by leadership.
It doesn’t always have to arrive at your desk out of the blue as a task already decided for the next sprint. In healthier organizations, designers are often consulted on which epics or projects should be prioritized next. This gives you a chance to influence the roadmap. But one key component remains unchanged — it must first get into the roadmap and backlog. And getting it there is neither the product designer’s concern nor responsibility.
* Problems and Solutions
The product’s problem you’re suddenly asked to solve will rarely be defined in the same way as the usability issue you previously warned about.
Most likely, it will have a more simplistic definition, where A causes B, so A needs to be fixed. Moreover, no time within the Epic will be allocated for researching whether A is actually the root cause or if something else, like C, is responsible.
This is where your earlier preparations come into play. If you’ve already done the research and identified that C is the true cause, and that fixing it will resolve both A and B, you’ll be able to address the real issue instead of just implementing quick fixes driven by the pressures of typical agile continuous delivery.
** Frontend and Backend
In technology-driven organizations, which are common among B2B software development companies, the attitude towards frontend refactoring driven by usability issues is often seen as secondary. It’s frequently relegated to a side task, deemed unworthy of its own epic. E
ven distinguishing between the back-of-the-frontend and the front-of-the-frontend might not tip the scales.
The only hope is that business or technology-related pressures will eventually prompt leadership to recognize that addressing usability issues can yield significant benefits. Until then, it’s a matter of waiting…
Prepare, shelve, reveal (don’t push) — an in-house product design tip was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.
