B2B SaaS
2022 - 2025
Web-App / Outlook / Mobile
I led end-to-end product design for a B2B SaaS startup, spending two years as the sole designer before the team expanded. I grew the product from a simple CRM into a major platform used by over 150 firms. Working fast on 5–6 week cycles, I created the design for our data-heavy tools and workflows. This work helped mature the product, scale the business, and secure our Series B funding.
Here is how I moved each project from an initial idea to the final product:
Deliverable
User flow
Hi-fi Screen
Prototype (when necessary)
Team
Product Manager
Product Designer
Front-end Developer
Back-end Developer
Objectives
Projects typically initiated when a Product Manager brought forward a specific user pain point or client feature request. For instance: 'Users can only view data on a third of the screen because the menus and headers take up the remaining space; how can we optimize this layout?' or 'We want to enhance our collaboration capabilities so users can tag teammates and leave comments directly on any specific item.
Research
During research, I will review the existing features, and list all use cases related to that features. I mapped down the current user flows and did competitor analysis to understand how other company tackle this issues. These are some examples:
Design and Prototype
Once I understand the existing features, use cases, and core issues, I begin the design phase. In cases where a feature requires a user to complete a series of steps to achieve a goal, I create a user flow diagram. This helps me visually map out the journey, identify and clarify any use cases before I start designing the UI.
When necessary, I create prototypes to demonstrate how users are expected to interact with the component. Below is example when I created drag feature for Tasks.
Review and Iterate
The review phase was an iterative process. The first review was typically with the PM and internal team, followed by the stakeholders. Once approved, the design moved to the tech lead for a feasibility assessment to identify any technical limitations or necessary design adjustments. From there, the design was ready for handoff, and the development kick-off could begin.
Due to tight time constraints and limited resources, we were unfortunately unable to conduct testing with real users. In most cases, stakeholder reviews were sufficient to validate the ideas and flows before moving to development. Any user feedback received post-launch was collected afterward, and we addressed it through maintenance patches or in the next phase of the project.
Development Phase
The development phase typically lasted 5–6 weeks per project. During this sprint, engineering took ownership with the core goal of shipping by the end of the cycle. Developers had the flexibility to scope down features to ensure on-time delivery—a practice we referred to as building a 'skateboard' version.
To support this fast pace, the PM and I provided a clear priority list of features for the developers to tackle. My primary role during this phase was to support the engineering team, clarify design specs, or make quick UI modifications.
Challenges and Reflection
Reflecting on this experience, my biggest challenge was constantly balancing a polished design with the need to deliver on time. Given our tight timeline and the critical nature of our clients' work, my priority had to be on-time delivery—ensuring the features worked flawlessly and helped clients complete their tasks. Visual polish was handled behind the scenes through maintenance tickets or in later project phases.
Also, while, this approach allowed us to scale quickly, it also meant we couldn't test with real users as much as I wanted. Moving forward, I want to bridge this gap by prioritizing real user data—whether through setting up product analytics or conducting direct user interviews—to fully measure the long-term impact of my design choices.