Design Debt

I spent most of my day today working on "Design Debt".

As you probably know, I work at a software company in San Francisco and have spent a significant amount of time trying to make visual design and creative concepting a part of the Agile process. Part of this adaptation was to understand how engineers approach a project, find overlaps in the problem-solving process, and mirror if at all possible.

One of the many habits I've adopted from the engineering modus operandi is the concept of "Technical Debt".

Technical Dept is defined as:

A concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.[1]

My design day today is no different. I often work in a fast-paced environment. I need to make changes on the fly for a presentation or make UI decisions on the last day of a sprint when QA catches an issue with inconsistent padding. It happens. I'll make a quick adjustment to a mock-up for a meeting that is happening in 15 minutes, but won't have time to update the design guide. I'll make a minor 10 minute adjustment to a mouse-over behavior, knowing it will take me 2 hours to update the design guides for the new behavior...but it's important.

And all of this. These loose ends. These "I have an image I need to resize in Muse" and "I need to spend half a day updating the design guidelines"...These fall into the category of Design debt.

Why is it important? Because the Engineering team, outside vendors, partners, freelancers, the press, your sales team need it yesterday.

I allocate approximately 10% of my week to Design Debt.


  1. https://en.wikipedia.org/wiki/Technical_debt ↩︎