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 is highly developer-centric, focusing on basic functionality with user testing often deprioritized and technical feasibility driving decisions.
Recognizing the scalability risks of building on outdated functions, my Rule #1 was to introduce a reusable component so that it can be scaled (shown in the image right below). This design handled the outdated function efficiently, enabling scalability and easing future feature expansions without adding technical debt.
CHALLENGES ————
To name a few:
No time to reinvent the wheel
Tight dev bandwidth
Very limited Data, just one metric
No user testing runway
Design needed to earn engineering
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 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 highlights the reality of designing in imperfect, fast-moving environments. While early assumptions are necessary, skipping quick validation cost us clarity. We prioritized speed over learning, and missed a key lean UX principle: quickly validate and learn fast.
I later responded with iterative fixes based on feedback, but even brief internal testing could have reduced confusion upfront. Overall, I am glad I was able to positively influence the team to trust design more and consider scalability not just in code, but in decisions, paving the way for more sustainable outcomes.
