Design Debt
Part two — Fail Fast, fail often.
What is Debt?
The pandemic is the debt we are paying to the failure of recognizing our damaging hyperconsumption, failure of preparing and foreseeing the largely abysmal healthcare. The next stronger mutations will be the debt to be paid by the world for the withholding of the IP rights. So now that each human being on the planet knows about debt in an experiential way, maybe there is a chance to be more empathetic towards talking about the what and hows of Design Debt.
What is Design Debt?
In the previous article for Part One, I attempted to talk about visualizing design debt from an interface. In this one, I would try to talk about how it is created. First broadening, and then narrowing from there.
One problem regarding design debt that I realize lies in the definition of ‘Design’ itself. Most designers would look at Design, as a core all-encompassing functional aspect of any product-process development.
Example:
The logistical challenge of vaccinating the majority of human beings on the planet, is a supply-chain design problem.
The mRNA synthesis itself was a biotech vaccine design challenge.
The publicity of the efficacy of the vaccine is an advertising design challenge, and so on.
Thus, as soon as you solve something for someone, you are designing. This is where the understanding of this someone — the user, comes to play such a vital role. An interface is just a tool/means to achieve the user’s expectations. Through this, I attempt to relate to the ‘Fail Fast, fail often’ paradigm.
In my opinion,
It is in fact Design Debt, that results into Tech debt.
How is design debt created?
The ‘Fail Fast’ often does not talk about the definition of this Fast. And not defining this seems to usually be one of the root cause of the design debt. While failing fast, the systemic changes that the product and to the functioning and processes of an organization go through, is often ignored. Perhaps one should try their best to fail in repeated user testing cycles and not as much in a released product. Perhaps rather than putting all efforts in failing faster, effort should be put in judicious, meticulous, farsighted and thoughtful decisions.
One core reason for design debt is how one begins product development, and how much of the user’s perspective enters in the product.
Developer-Centric Design (DCD) is a unsaid paradigm.
DCD and Stories. Yes, User Stories. Throughout all these years, I’ve seen the Agile User Stories, being written from the perspective of the development.
Example:
“In order to avoid synchronization issues of multi-threads in backend, we need to route requests into the front-end box, otherwise exceptions would occur in the system interfacing.”
This could easily have been,
“As a clinician, I would like to see the same patients in the examination as in the list, so that I can verify if I’m performing the correct patient-examination.”
Sure, there will be actionable tasks inside a user story, and these tasks can be developmental requirements but the story needs to be a User’s Story.
This fallacy not only ostracizes the development team from the users, it also in a way isolates them from the cause, vision and mission of the company itself.
As the situation worsens when there are aspects of ‘How should the user do it’ embedded within these User Stories.
Example:
“As a clinician, at the time of setting up the scan, I would like to see the patient information on a tablet, so that I can verify the patient details before the scan.”
The other main presupposition of failing early that I think organizations miss, is learning from those failures. The tests themselves are done at a much later stage in the product development process. Thus, the tests iterations are too close to make a substantial difference in your product architecture. Thus, the possible learnings from a test would also be very shallow.
A UX test should test the product architecture, and not simply whether the button should be on the footer or on the left panel. A UX test should also bring out the fallacies in the product development processes, and not simply whether the user is able to click on something or understand an icon.
A UX test should prioritize testing different product architectures and hierarchies and not simply the color of a button.
Example:
For an AI-enabled training system, the test should be aimed at evaluating which metric/parameter of the AI needs a user input (according to the user) to increase the confidence level, and not how. How, as usual, comes much later.
Another crucial aspect is what to do with the test results. If you have performed the test too late in the development process, you would have not much leeway other than patchwork.
However, what you could do is feed the user test results for the usability of design patterns into your Design System, if you don’t, massive debt is underway.
So, what to do about it?
Apart from the core problems and solutions already mentioned above, there could be some more systemic changes that could be done.
Clearly, in a way an antithesis of this current paradigm — “Design Early, Design Often”, does that make sense? It tries to elucidate that design is not an execution role, rather a planning role.
Design, though now has a fancy little corner within the fairly undesigned agile chart below, however contradicts this core philosophy, amongst other things. Just like a software codebase/framework cannot align to fail early fail fast, certain aspects of design cannot too. The implications of bad primary navigation and basic hierarchical inconsistencies are simply too big to come out of.
What could be the common causes of design debt?
Adding to the earlier points, there are things that happen when the org tries to fail fast and fail early. Certain aspects of the product get cemented in the process. I try to abstract the problems and the possible solutions of some.
Legacy products
Problem
Dogmatic navigations and workflows are prime examples. Software that emulates CRUD to be the maximum capability of it and then expects to have an AI layer on top, is a recipe for disaster.
Solution
With changing times, codebase and design paradigms need to change.
Process
Problem
A product development process is thought of this dogmatic thing that will remain. This has to change. The product will be only as good as the worst process.
Solutions
Sensitizing and allowing for alterations in the process is utmost importance. — The earlier example of integrating usability feedback directly into to design system instead of the product is one central process anomaly which most likely does not happen.
— This is similar to language localization which quite often, wanders around as an afterthought, and thus is rarely designed for. It is a debt, it will come back and bite you.
— Include product management in your user testing and usability testing. If possible also the developers. If possible, book a theater and project it there :)
Bio magnification of bad design
Problem
The aspect of ‘We’ve always had it this way’, and the inability to revert from bad design decisions will only magnify it to unimaginable proportions. Solution
The only way — Question, question, question. Recursively.
Design patchwork
Problem
This magnification would only result into the patchy solution-centric design work which will reach its brim sooner than later.
Solution
Designing as early as possible, before development, and testing different architectures could help solve for this.
Instant gratification
Problem
Any of this patchwork, or any feature that is launched for instant gratification is almost always bound to fall in the bucket of debt.
Solution
If user need is not warranted, don’t force-fit, if user need is warranted, embed it in your product, not in its configuration page.
Developer centric design
Problem
As mentioned, this one is quite common. When the developer resources are considered more precious than the planning aspect, this rabbithole is not far away.
Solutions
They say, if you think good design is expensive, you should look at the cost of bad design. I’m not sure of any actionable solutions, but invest in people who advocates for the users and look at bettering the processes that lead to the organization’s perspective towards UCD.
— One (slim) possibility is to change the business model to reap benefits only if value to the customer/user is exhibited. And not based out of sales metrics. This will be a blow but I imagine, will straighten out the organization like nothing else can.
Multiple designers
Problem
A natural progression, leading to faster turnaround of designer roles. New designers coming from different experiences should bring better ideas and most likely possible resolution for the ongoing problems. However, if the system and process is not capable to accepting this, it will merely amplify the design debt.
Solutions
Ask new designers to present the processes that they liked from the previous organizations, and ask the old ones to document. And, the done definition. One should not be allowed to mark a user story as done if it is not documented.
Lack of documentation
Problem
Expedited role changes will magnify back lack of documentation like nothing else. The organization would end up designing the same thing dozens of times.
Solution
The done definition. Design rationales not being documented can be thought of as a ginormous debt which deserves its own article in the near future.
Randomized design critique
Problem
Similar to testing the designs at apparently random development stages, critiquing at random product planning stages will incur design debt.
Solution
Clearly, design early. At least the standard 30–60–90 critiquing should be followed.
Resolving ux changes through ui
Problem
Finally, the classic last resort, resolving UX changes through UI. Creating hyperlinks, softwares inside softwares using i-frames, promoting every unknown as a ‘configuration feature’ and so on, are classic examples of solving for UX from the UI.
Solution
Unfortunately, at this juncture, debt is already there. To avoid it from exploding, start doing the above points again.
Just like any debt, design debt is inevitable. Similar to how a company should set aside money for building a new tech stack every decade or two to revamp their architecture and code framework, the same needs to be allocated for design.
And while we are at it, keep one day a week as a meeting-free day in the organization. Let people work.
Thank you for reading and I wish you and your loved ones a good physical and mental well-being.
If you liked reading this, consider reading the Part One of this series. And if you have already done that, then check this one below where I (yet again) advocate for the user.
