Design Debt

Its been over 6 months that this write-up is in my drafts and I have been procrastinating on finishing it. And as a matter of fact, that is one of the prime examples of how debt is created. So I finally sit down this weekend, washed my hands for 20 seconds and opened my laptop.

If you are a designer who is trying hard to make structural changes, and the product management says, that is too expensive, or worse, “But, we’ve always had it this way!”, yes you are headed in straight in this trench of design debt.

‘But, we’ve always had it this way!’ — Almost Every Product Management

There is something about a tech debt that people are comfortable investing in even though not many people know about scalability and vision in tech decisions. But design debt on the other hand, is completely disregarded mainly because people continue to think of design as a mere coloring department and everyone has an opinion but rarely anyone has a vision and especially one that connects the user to the interface to the tech and org decisions. In fact, because of that perception, I recently even saw myself making different layers within the interface that would suggest how data should flow and which section should influence which.


We could take a small detour to demonstrate that in say, deconstruction of a tablet interface from the gif below.

Interface Hierarchy and containerisation

Considering a left to right approach, decisions made towards the right, viz. in taskflow or workflow, should not affect the product (offering) or the platform section. This ‘spilling out’ of functions from their respective area of influence creates irrevocable framework complications going forward. We all know how difficult it is to remove something after it has been developed within a product. Sadly something that has been added to a product without documentation cannot be removed without documentation.

Ergo, this area of influence needs to be neatly defined and upheld if one wants to push back on design debt as much as possible. Most of this debt comes from one area or one workflow trying to influence the other. It then quickly becomes a matter of ego for one product/workflow to ‘be seen’. When the screen real estate is premium every workflow will fight for it inevitable blurring the boundaries and thus responsibilities in the due process.

Seamless design should only be for the user, and that can happen only if there are definite, responsible and prominent seams within the interface — workflow — product — platform — and organisation.

Thus, decisions towards the right of this scale in the gif above, (which is the child), should not affect the ones on the left (parent). If and only if all children feel that they have the same feature demand then the parent can have a look at it and decide whether to ‘promote’ this feature. Otherwise, each kid only gets to play with their own toys in their own room. No messing up the hall.

It should be clear from the gif the flow of data, the access control, user privileges and area of influence. The data that is required by the complete platform should only be housed in the leftmost layer here. Children on the right can only be allowed to take instances from it. These things are usually common from a tech architect perspective, but quite often people seem to not relate it to the visuals displayed on the screen.

Organised organisation

In fact I would go even further to say that an entire organisation needs to be physically mapped according to your interface and this framework needs to manifest itself in the physical world. Imagine fancy interior design where the teams are sitting dependent on the area of influence they have on product and how the seams of these different areas need to be connected. This had become a complete different topic on its own so it got its own little post.

If you read that previous article, there I try to illustrate how even the teams need to be developed according to this within each other, and even physically positioned inside of the organisation to facilitate this framework. They simply cannot be set as independent pillars that we see in most organisations. Thus, a simple deconstruction of a screenshot above can help completely reorganize the whole organisation.

In this part we briefly touched upon from interface upwards. How interfaces can give rise to organisational structural changes. A lot of content has been left to the imagination of the reader because that is precisely the idea of the article. For the next part, I shall try to illustrate design debt in the realms of the infamous ‘Fail fast, fail often’. We shall touch upon Agile or SAFe in the realm of Design and then the dreaded — Design Documentation.

It isn’t uncommon for designers to literally see through the differences and ego fights that might be happening in a company just by looking at your configuration page. :)

If you liked reading my article considering reading more and following my work to get updates.
Quarantine read recommendation — The User Problem




Procrastinator by profession, facetious by talk. Traveller, wanderer. Musician, writer. Engineer, Designer. Not in that order.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How Can I Get In Touch With 3d Visualization Company?

Patterns and Flows: Goodreads

PSYCHIC PIZZA: A Case Study in Social Distanced Food Delivery

Custom Printed Vinyl Flooring — The Only Limit Is Imagination!

Sketch Versus Figma

Web Design: Blog 1

Are you missing out by waiting until your org is ‘ready for design’?

A Venn Diagram of design: desirability, feasibility, viability plus responsibility, systemic, and transparency

Designing Product for Your Users: An Approach Using UCD and Persona

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aditya Aserkar

Aditya Aserkar

Procrastinator by profession, facetious by talk. Traveller, wanderer. Musician, writer. Engineer, Designer. Not in that order.

More from Medium

Communication is the Key Element to Seeing Design as a Team Function

Three people with laptop computers engaging in a design discussion.

Design Sprints and should you use them?

Design Challenge: How to help a Human resource development to manage attendance for employees who…