Category:
Quick redesign
Role:
Product Designer
Team:
Product designer, PO, CTO, 1xFE
Timeline:
4 weeks
Scalability is a common challenge in early-stage startups. Features are often built quickly to meet immediate needs, leaving behind legacy designs that eventually block future growth.
This case study highlights one such scenario: a project to deliver a Multi-Document Upload feature within just 4 weeks. While the concept was simple, it had to be integrated into an outdated and unscalable interface. Without careful intervention, the new functionality would have clashed with legacy systems the engineering team could not deprecate in time. I identified this risk early and proposed a strategic interim design solution, one that respected backend limitations, avoided added frontend complexity, and aligned with long-term scalability goals.
Through clear communication and stakeholder alignment, the solution was implemented without derailing the timeline.
IMPACT ————
COMPANY CONTEXT ————
My team’s developer-centric approach prioritised technical feasibility over user needs, often leaving user testing behind. This resulted in a platform built on outdated functions that were difficult to scale, ultimately slowing down development and making the expansion of features cumbersome.
To address this bottleneck, my Rule #1 was to introduce a reusable component that could replace the outdated functions. By doing so, I created a scalable foundation that streamlined development, reduced inefficiencies, and enabled future features to be added without compounding technical debt.
CHALLENGES ————
To name a few:
No time to reinvent the wheel: pressure to deliver quickly under existing constraints
Tight developer bandwidth: limited engineering resources slowed iteration
Very limited data: decisions driven by a single metric, reducing confidence
No user testing runway: little room to validate solutions with users
Design needed to earn engineering: every proposal had to prove technical value to be prioritised
Unscalable foundation: outdated functions made the platform brittle, slowing development and blocking future growth
First of all, what is unscalable? The 'Attachment' function:
What makes the 'Attachments' architecture fundamentally challenging to scale?
See the old interface for 'Attachments' below:
While it was clear that a better way to handle the list of attachments remained important, the first iteration for Multi-Document Upload confirmed that the 'Attachment' actions i.e. 'Link contract (into an attachment)' and 'Add Attachment', would be highly likely to cause a huge confusion.
L: A document list view for Multi-Document Upload
R: A document preview of one document
SOLUTION SPACE ————
By introducing a scalable document-item component, I addressed both legacy and new needs:
New uploads → Organized under the Documents tab by file type
Legacy attachments → Grouped as Related Contracts under the Related tab
ITERATIONS ————
This solution rolled out quickly without pre-launch testing, reflecting our team's operational reality. As the only designer in a culture that prioritizes intuition-based implementation, I identified the problem, proposed an interim fix, and saw development begin the next minute. Though I advocate for testing to prevent guesswork and rework, I supported our rapid development approach while closely monitoring post-launch user feedback.
My initial design aimed to preserve all attachment functions before a phase-out could be planned. First, I removed the secondary buttons from the header area and placed them with icon-only buttons for "add attachment" and "link contract" in the new Related tab, like in the Document tab.
Post-launch qualitative feedback revealed that it had led to users clicking the wrong "+" button, as shown in the left image.
I quickly iterated the design by removing one "+" icon-only button. Now, one + Add button triggers a menu with options to "add attachment" or "link contract," as illustrated in the right image.
FURTHER ITERATIONS ————
Despite limited research, my design increased the clarity of 'Attachments' (in a tab) as related contracts, especially to newly onboarded users. However, longtime users missed the visibility provided by the previous dropdown menu for 'Attachments', despite its scaling limitations.
REFLECTION ————-
This project underscored the risks of building on an unscalable foundation. The pressure to move fast led us to prioritize short-term delivery over long-term sustainability, and while speed mattered, it quickly became clear that outdated functions were slowing development more than helping.
The real turning point was shifting focus from patching issues to solving the root scalability problem. By introducing a reusable component, I helped the team reduce complexity, unblock faster development, and prevent technical debt from piling up. Most importantly, it showed that scalability isn’t just a coding concern but a design decision that can shape how quickly teams learn, deliver, and grow.
