Design Debt
Part One — Deconstruction of an interface
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.
Containerization
We could take a small detour to demonstrate that in say, deconstruction of a tablet interface from the gif below.
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
