Redefining beauty with SaaS


BloomMe's mission is to make running a beauty business simple by offering spas and salons a one-stop resource management system.

As part of the effort at improving the performance of the business and the team, my team and I wanted to resolve some of the major communication problems that have been hindering the growth of the business for years.

I am the lead of the team and this project.

Alongside with 3 UX/UI designers and 4 full-stack developers, we were able to create something amazing within 4 months:

  • Requirements for 5 different interfaces (iOS x1, Android x1, Web x 3, and API x 1)
  • Established an effective product development process
  • Established an internal knowledge library
  • Vastly improved the quality of communication between teams
  • Vastly reduced on-boarding time
  • Eliminated bugs and errors rooted from flawed system design

Challenges we faced

The project was launched 2 months after I joined the company. In order for me to understand the scope and difficulty of the problem, I scheduled meetings with the key leaders within the company to ask for their point of views. Here is what we have identified:

  • Communication quality — teams spending more time finding information rather than focusing on delivery. Information and knowledge discrepancy between team members means they rely heavily on team lead for updates
  • Effective decisions — lack of useful insights and readily available information makes it extremely difficult to make effective decisions efficiently
  • Insight/knowledge preservation — non-consolidated information is not knowledge, it’s just noise. Also struggles with the constant loss of human capital in the form of knowledge after turnovers due to lack of documentation effort and refined system
  • Bootstrapped legacy system w/o documentation — an inherited legacy system with no documentation, rely heavily on memory recollections and comments on task tickets, prioritizing short term speed over long term scalability

Framing the problem

Speaking from experience, the reason why most startups failed to scale is not because of the lack of adventurous investors who are waiting to invest, but rather to find the right focus that is helpful to their customer which brings real impact.

Money = depth of impact x urgency x width of scale

Especially when we are in the era of no-code interactive prototyping tools, we no longer need to wait for a year to build something, it’s all about validating the idea as soon as possible.

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about the solutions.” — Albert Einstein
Design discovery framework from Practical design discovery

Among design/UX/discovery frameworks, we realize that the design discovery matrix by Dan Brown from his book Practical design discovery was most fitting for our project. It is highly recommended to those who want to refine their UX discovery process.

Not only the matrix is able to provide a sense of progression to the team when different items are being checked off the list, but also it is a solid reference to follow when organizing the information we collected from different resources and convert them into refined knowledge.


Try imagining yourself as a young kid, stranded between the endless complaints about being a terrible partner, either being insensitive or failing to solve any real problems.

This, is B2B2C.

The tricky thing about surviving under this business model, is when you are constantly striking the balance between both sides where each side has opposing interests. Not to mention, the needs, wants and pains between different user personas among the B2B market (users vs buyers vs executioners) further complicates the matter.

To avoid any drift of context when we were conducting our research, we broke the research down into a two-by-two matrix, clearly defining our team’s focus before we conduct our research. Not only does this set the perspective for our research, but it also helps our team to empathize better with our interviewees.

B2B2C market matrix

Here’s what we’ve learned about the unique characteristic of each market from our researches.


  1. Problem-solving oriented: Businesses are highly driven by applicable problems, and customers consider trade-offs between cost-benefit religiously.
  2. Longer change cycle: changes can easily cause a butterfly effect because most businesses don’t just operate as a stand-alone. Upstream and downstream are always in consideration.
  3. Risk-averse: Less exploration in general, changes are not welcome.


  1. Excitement driven: Consumers celebrate personalization while welcomes pleasant surprises, always on the lookout for new excitement that acts like an escape from daily boredom.
  2. Self-reflection related: Especially the beauty industry, there is a high chance that the desire of the customer roots from personal value.
  3. Short change cycle: products have a shorter life span, the majority of demands are driven by trends and exposures.
  4. Adventurous: Consumers are more forgetful and forgiving than businesses, trust are less harder to earn due to less is on the stake.

Domain research

Intensive user research template

Qualitative research such as one-on-one visits are awesome when understanding a certain topic/subject, and quantitative research is best at validating hypotheses.

After spending hours interviewing different merchants, our team organized consolidated them into the following artifacts:

  1. Knowledge library
  2. Glossary
  3. User journey & persona
  4. Data library for database scheme definitions
  5. Entity-relationship diagram
  6. Database scheme

This not only allows other teams to get a better understanding of the topic in order to make better decisions, but it also acts as a single source of truth when conflict or confusion arises. A simple, effective, yet easily ignored thing to do to reduce the cost of communication.

Marketing research

Data analytical tool stack

When time is of the essence, and you are confident with what you already know, sometimes it’s alright to just either quantitative or qualitative research.

Since our customer-facing application had been operating for a few years, and enough qualitative feedback was stacked up, we felt the confidence to only rely on our tracking data for the project.

We retrieved data directly from our tracking stacks and consolidated it into analytical insights. At this point, quantitative data are far more helpful than qualitative data at validating our design hypotheses.

Competitor research


When it comes to looking at our legacy system with 0 documentation, we all felt the urge to scrap it and start fresh, because it will be more difficult to decipher than rebuild. However, it wouldn't be wise to ignore it because the longevity of the system has proven that something was right about it.

Successful products usually have one thing in common, where they found the balance between the golden triangle of delivering a great product: value-add, user experience, and execution. As such, we took a look at what was being built.

  • Business audit — understand where the business is standing, and to find room for improvement
  • Design audit — understand how to be more effective at delivering our value to customer using design, and how to scale efficiently by using design systems
  • Technical audit — understand where is the limitation, and how to improve the system’s effectiveness and efficiency
Business value preposition canvas
Design interface audit
Technical audit


New design system

Even though the development was terminated because the business ceased operation under the impact of COVID-19, nevertheless the work itself was still worth a pat on the shoulder.

Our team had produced end-to-end documentation to align the teams across the company, eliminating especially act as the bridging between business, design and development.

  1. Brand foundation
  2. User persona
  3. Industry knowledge & Glossary
  4. Design system
  5. Mock up
  6. Company roadmap
  7. Product backlog
  8. Interactive prototype
  9. Business requirement documentation
  10. Functional requirement documentation
  11. Cloud infrastructure documentation
  12. Micro-services architecture
  13. API documentation
  14. Data library

Some key takeaways from this project are that:

  • Identify your deliverable first — work your way backward to avoid scope creep
  • Pick your battle — we can't win them all. Find what matters and compromise with the bigger picture in mind
  • Transparency is king — most conflicts come from poor communication, and keeping everyone on the same page makes things a lot easier
  • Collect, consolidate and stay organized — unorganized information is useless, and organized knowledge makes helpful insights
  • Listen, don’t shoot first — always start from listening to your customer, and make no assumptions

What's your story?

I'm always interested in hearing about new projects and opportunities.

Let's grab coffee or get on a Zoom call. You can tell me about the problems you are trying to solve. I'd love to listen and see if there is anything I can do to help. | +(852) 6126-3333