Let’s Talk Design Debt: What is it and what could it cost me?

Imagine with me for a second. You’re a non-technical founder with an awesome B2B SaaS concept. You know you need to hire a developer to build your software product and you’ve heard no one wants to invest in your startup until you have something built, so you go straight to the developer or dev shop your friend recommended.

The developer takes your money and your requirements and gets to work. You communicate back and forth on requirements and technical constraints that you kind of understand and you’ve made decisions to the best of your ability based on those conversations. As far as design goes, you’ve sketched together a few flows and back-of-the-napkin wireframes. Your developer has taken those and interpreted them, making several design decisions when building out the product. $30,000 dollars in and 6 months later, you have a product. 

You launch and get some initial interest, but not enough to really get the traction you’re looking for. Your customers make some feature requests, so you drop another $50,000 over the next 6 months building out these features. The good news: You’ve gotten some great features out during that time and as you become more competitive in your feature offering, you’re seeing more revenue coming in. You now have a decent-sized customer base.

With all these customers, there’s a whole new set of issues. You’re seeing loads of support tickets coming in about frustrating workflows, features not working as expected, and errors popping up that customers don’t know how to interpret or resolve. Time spent dedicated to supporting customers is skyrocketing, and with it you’re having to pay for additional help on customer support and dev. Ouch! You’ve hit the initial shock of design debt.


Wait, what? (via Giphy)

But that’s just the beginning. You start working with your dev team to fix design problems where you can identify them, diverting valuable time from new features and strategic projects.

Finally, you hear about how bringing on a UX designer can help. You spend the time and money to recruit and bring the new designer up to speed. The designer audits the current platform and recommends a redesign, which could take longer than the original build. You’re able to get a few new features slipped into the redesign, but the time and effort costs you a year of valuable time just reconfiguring the current foundations instead of making further progress. Meanwhile, you’re reeling from excessive churn and damage to your brand’s reputation in the market. Bam! You’re now encountering the full cost of design debt.


That cost more than expected! (via Giphy)


The vast majority of developers I’ve worked with (or whose work I’ve inherited) are not great designers. That might sound like I’m throwing my friends in engineering under the bus (sorry, y’all), but truthfully, the very reason they’re amazing developers is why they shouldn’t be doing design. 

Developers are highly attuned to the technology they work with – constraints, functionality, possibilities. They’re superstars at translating defined requirements into working software in the most efficient way possible. Developers thrive on technical language and technical workflows, and oftentimes are too deeply familiar with the tech and the way they’ve built the platform to really empathize with the experience of a non-technical user.

Designers, on the other hand, are focused on representing the users’ perspective. Non-technical users, by and large, don’t understand the difference between a 404 error and 500 error. Users often don’t see the “clearly labeled” button that developers can quickly point out because of the hundreds of hours they’ve spent building the corresponding workflows.

This focus on the users’ experience, enhanced through conducting user research enables SaaS product designers to design data structures, workflows, navigation, layout, in-app messaging, and interactions that intuitively make sense to users. One of the common misconceptions is that UX designers are brought in to make the UI look pretty. While designers certainly take pride in aesthetic excellence and in delivering delight, it’s far from the only deliverable. In essence, UX designers define the details of the requirements that a developer will build, told from a user’s point of view. 

Cost to change a design over time (Hint: it costs a lot more once it's built!)

UX designers are the architects and developers are the builders. Imagine jumping straight to hiring a construction crew to build your new skyscraper with no architect involved in the process until the first 15 stories have been completed. The analogy breaks down to an extent in that software is an iterative process. But iterations can be extremely expensive if the right people aren’t involved at the right time.

So, what’s the alternate scenario? What’s the recommendation? Bring in design support early, before dev starts building. An hour of a senior designer’s time is much less expensive than an hour each multiplied by the multiple developers it will take to build out the design. 

There will always be some design debt that accrues in an iterative Agile SaaS environment, but working with an experienced design partner, like Trailmerge, at the outset and over the long-term can help you dramatically reduce the severity of support needs and rework at a time when you want to be focused on growth.


Mark Tegtmeier

Founder Mark Tegtmeier brings years of design experience to Trailmerge. He has worked with early stage startups, design and software agencies, government, and enterprise, driving them further in their product vision. A husband of one, father of four, and urban homesteader, Mark loves developing tech talent and coming alongside founders with ambitious visions for their products and companies.

No items found.