Design Debt: Why You Should Avoid It (Especially in Fast-Paced Company)
As I write this article, I’ve been working in Kargo for more than a year. I joined Kargo when we were starting to develop our first product line up. I was tasked to handle the Driver app when I first arrived, and then I was also assigned to handle a web-based internal product called Panthera. I’m aware the development was already far and more complex compared to Driver app.
Earlier on handling this project, I found something that bothered me as a designer. When developing for Panthera, I found many elements that ignored usability over functionality. In a fast-paced young start-up like Kargo, sometimes we trade proper development processes in order to deliver a product faster. But it may come into debt in the future, especially if we don’t do a design process properly which I can identify as design debt.
What is design debt?
This concept built from something called Technical Debt, co-author of the Manifesto for Agile Software Development, Ward Cunningham said that:
“There were plenty of cases where people would rush software out the door and learn something, but never put that learning back into the program. That analogy was borrowing money, thinking that you never have to pay it back”
Even though the team might save some time and release the product early without proper testing, and later on the debt would come back after them. Once future development begins, all the debt becomes a blocker of its innovation, which later can cause headaches for all members. Sometimes the worst thing that can happen is to redo everything in a proper way which will take a huge cost. It is also applied to the design process, which can lead to design debt. In the long run, once the product itself becomes more complicated than ever with the additional requirements. It may ruin the user experience itself.
So where does design debt might come from? My findings on our web-based product during the development were:
- Lack of time or resource to work on every core feature with the same care
- Development without a proper design process, no user testing has been done
- Prefer functionality over usability
In many areas of web development, usability is often confused by functionality. The definition of usability is as follows:
“The extent to which a product can be used by specified users to achieve specific goals with effectiveness, efficiency, and satisfaction in a specified context of use.” — Source: International Standardization Organization (ISO)
On other hand, functionality can be defined as:
“The ability of an interface or device to perform according to a specifically defined set of parameters.” — Source: International Standardization Organization (ISO)
Now the problem in many cases of web and mobile interfaces are built to be functional, but not necessarily usable. It happened in Panthera.
Understanding user: Diving into their origin need
When a designer designs a product, it is meant to be used by people. Understanding how a user’s mind when dealing with their task on a daily basis is essential. In terms of Panthera development, I can’t directly ask the internal operation team what they need because it might lead to user’s bias. During user research, observation of internal operation team pain points can help me determine their real need. Because they can’t tell the difference between their needs or wants. I found this case when developing a tracking page which at that moment internal ops wanted to have specific features. During the user research session, I found their origin needs are more simple than they thought would be. Building a product that includes user’s bias can lead to design debt as well.
To reduce the possibility of creating new design debt in the future, I should proactively communicate my design decision. Well documented design decisions can be the source of truth not only for engineering teams but also respected stakeholders. If something happens in the future development, I can easily look back and evaluate the solution based on current requirements. Making my team understand my design is important because the engineering team can understand what they’re building and have empathy for their users.
Maintain scalability and future need
Based on the development of Panthera, I could say that enterprise product is complex. It is because enterprise product has many parts relying on each other. One thing that should always be maintained is complexity. When complexity happens, usability is often left behind. As a result, users can get biased, and sometimes they don’t understand how to complete simple tasks. Complex products are also hard to scale. It is difficult to build on top of the entangled base, which results in delays, unforeseen costs, frustrated employees, and bugs.
I found a hard time making Panthera simpler, but then I figured out that providing more options to make it more flexible and unbiased to internal ops makes the development easier. Internal ops should be able to adapt the tool to their needs, rather than feeling constrained into a path that doesn’t work for them. With the fast-paced company style, I think this model works best to handle future needs.
Building a scalable product is first priority in early stage-company
At the beginning of Kargo, we were focusing on building Panthera to help the operation of the business. Since we did everything manually through google sheets and a lot of manual data input. It was so frustrating for the business side because it wasn’t efficient enough to make us grow faster. Between product and engineer were challenged to develop the first MVP of Panthera. Panthera handles our operations in the logistic business starting from creating a job, assigning a driver to a truck, tracking the shipment, and so on. These were the core features that we built. In only one month of limited time, everything was built from scratch. However, there was a catch, which I mentioned earlier about delivering products fast without a proper design process. Due to the limitation of time and resources, at that time we deliver this product to be functional and put usability anywhere else.
Three months later, the business grew fast and we continued the development by converting manual processes to product. At that time, we expanded our market into two different types. Commercial jobs were handled by Panthera but marketplace jobs were handled by another product which is Internal dashboard. However, these two products were not connected with each other. We realized if we want to scale and unleash the full potential of our product suites and user networks, we need to unify these two products.
We call it The Big Bang, the reason why we call it that is because it was the biggest collaboration between product and engineer team to scale our business. I was in charge of handling payment disbursement modules, during design development I found that the base for Panthera was a tangled mess of infrastructure. To have a better look at the entire product, I started to do a design audit of my module and related modules. When I found enough findings of what happened in Panthera, I communicated with my design team and aligned in order to solve this design debt. We found that in the early stages of development for Panthera, many of its parts didn’t go through the design process. Rather, it was built based on lists of requirements without any proper testing processes. This caused usability and technical difficulties in which we are difficult to expand.
I revisited Panthera’s process flow and proposed improvements taking into account the usability point of view and future flexibility. I communicated with the engineering manager about this issue and I revamped the look of Panthera to accommodate the needs from internal ops and current requirements from business. The whole design team supported each other to make Panthera better than ever. Now every single development should always focus on understanding the origin needs of its user, stay unbiased, usability, and scalability.
Lesson Learn
“Deliver fast means fast feedback” — Speed is often identified with startup companies. However, when business development continues to rise rapidly and our product development is also at the same pace. We cannot forget the core element of product development which must always consider the appropriate process design. The cost of design debt can never be estimated in advance. So before this design debt interferes with the innovation process of product development, we must be able to prepare wisely.
About The Author
Mohammad Ilham Akbar Junior is a Product Designer at Kargo, managing the research and design development of Kargo’s external and internal products in the mission of developing Indonesia’s biggest and most trusted logistic platform.
