May 22, 2019
Cover photo by Ian Espinosa on Unsplash
I was listening to The Shop Talk Show (a show all about front end design and development) the other day when Dave Rupert and Chris Coyier got on a topic kind of close to the chest for me.
In episode 360 "Riding a Bicycle" a listener wrote in asking about technical debt, when they should service it and how they should approach validating improvements to code when they don't have metrics in place.
Chris and Dave talked about technical debt as a whole and Dave made the statement that technical debt is code that's written fast and loose and often breaks things in the future. He challenged that wanting to change a bad design is not technical debt... it's just bad design and you have to live with it.
This piqued my interest because design debt has been a topic of conversation around the office lately. Our design team has been working on several projects, and I would say we have accrued a fair amount of "design debt". I believe design debt is comparable to technical debt, and might even be more dangerous because of how it directly impacts the user and the business.
So what is design debt?
Well if technical debt is code that's written fast and loose and often breaks things in the future... Design debt could be seen about the same way. It's design that is hastily put together without a system, without user research, and that breaks when you try to iterate on it.
For example, let's say you needed to put together a dashboard for an app. You don't have access to real users or any research, you have limited domain knowledge as it's a niche app, there isn't an incumbent to use for reference, and you have a deadline of 1 day because the development team needs something to work on ASAP.
This assumption-based, design in a vacuum approach is doomed to fail. No time to establish a design language that scales. No data to base a good user experience on. No flexibility to redesign the product, should users actually give feedback (or use it at all).
How does it compare to technical debt?
Like technical debt, you pay for design debt later. Unlike technical debt - it can doom a product from the start. Inefficient or slow code absolutely impacts the user experience, but a poorly thought out product that doesn't solve the right problems might keep users from even downloading or signing up in the first place.
Additionally, design debt often leads to technical debt. Iterations in a component, layout, or overall structure of an app can create time-consuming tickets in the backlog. "As a user I want to actually do something useful" might be an all too common story with poor design up front.
How do you service design debt?
It's easy to couch quarterback the scenario above and make sweeping statements like "don't work like that", or "just always do your research", or "tell the client that deadline doesn't work with your process." But the harsh reality is we've all been in a jam like that where we've had to compromise sound design process for a quick turnaround, relying on gut instinct and a whole mess of assumptions. So what can you do to fix it?
Step 1: Know your assumptions.
Write down all the assumptions you made during the design process.
- The users (goals, pain points, opportunities, etc.)
- The content (what you thought was important and why)
- The actions (how you thought users would want to achieve the goal)
For our dashboard example, you might note the following:
- Assumed user is middle-management of retail chain who cares about store performance, rank within the region, and tries to plan a successful day of operation.
- Assumed user pain points are outdated information, slow communication, and employee idleness.
- Assumed solution would show store performance and rank, real-time alerts for key information, and task delegation for employees.
That's high-level, but you can go deeper and deeper to talk about the specific content on each page.
- Assumed user would want to see current sales vs. sales goal
- Assumed user would want to see regional average sales vs. goals
- Assumed user would want to see forecasting of future sales to help inform operational decision making
- Assumed user would want to see employee schedule for the day
- Assumed user would want to see employee tasks for the day
- Assumed user would want to assign an employee a task
- Assumed user would want to be able to contact employee directly
- Assumed user would want to get push notifications about events impacting daily sales progress (returns, damaged inventory, etc.)
If you think this is a lot of work, it absolutely is Any time we "assume" as a designer, we incur some measure of design debt. If nothing else, this exercise will show you how many assumptions you make on a product. In the end, though, this list will become your ledger, giving a clear, quantifiable metric for measuring your debt and enabling you (and the team) to start servicing it.
This is usually the time where you present your findings and make the case that time needs to be spent getting answers to these important questions. If you group and sort all your assumptions it makes it easier for non-designers or stakeholders / management to understand the need and help prioritize your efforts.
Step 2: Validate with data.
If you have the "OK" to go (or even if you don't) it's a great time to start talking with users. You can go about this in a few ways; user testing, focus groups, interviews, or contextual inquiries as they use the app.
If you're working on enterprise level software brutal honesty is best - admitting that you assumed X, Y, and Z about their job and needs and giving the user a chance to prove you wrong. This helps you get conclusive information about what the app needs to be doing.
If your product is more consumer oriented it might be harder to tell paying customers that you built a crappy app. Instead try to get metrics on what features are being used, which ones are ignored, and map that to your assumption list. If you thought feature X was important, but engagement numbers are low, maybe it's not as useful as you assumed (or maybe it's too hard to use). This situation might prompt a survey related to the feature where users can respond with their opinion about it.
Once the data starts flowing in you'll be well on your way to making good design decisions and servicing that design debt. Just be sure not to add to it (too much) by making more blind assumptions in the future.
Just like technical debt, servicing design debt is contingent on bandwidth and priority from the folks in charge. In most cases, providing your concrete metric of assumptions (and articulating WHY this is dangerous) is enough to get the green light to start getting answers, and from there scoping out changes based on real data.
But if you work in a place that doesn't enable you to get answers to those questions / validate your work... you might be doomed to endless design debt. You absolutely cannot service it with more assumptions or "gut feelings" (you are not your user!). In this situation, try to get whatever data you can from leadership (KPIs, how they measure success of the product) and start trying to connect your assumptions to the data. The more you can correlate your questions to the bottom dollar the more management will be open to listening.