Proptech
B2B
B2C
SaaS
Responsive Web App
Company
Howbuild
Project Duration
12 Months
Role & Responsibility
Product Design Lead / Head of Design
Area of Impact
Design Leadership, Product Strategy, UX Design
Collaborators
5 designers, 3 product owners, 2 researchers
Background
Howbuild is the one and only startup in property technology (proptech) sector that offers end-to-end, omni-channel construction management SaaS product. The software manages people, payments, and productivity of a construction project.
As the company was funded by Softbank in 2020, I joined the core product team as Head of Design / Product Design Lead to spearhead and rebuild its software product, which was running on existing archaic system.
The Problem
There is a huge lack of transparency and visibility of information when it comes to managing construction projects. No one in a construction project uses same software even though they are building it together. Howbuild thought that this was a big problem (and opportunity) and wanted to provide a better way to monitor, manage, and pay construction projects.
So Howbuild built the first version of integrated construction management software a few years ago, but the way it was built was archaic, information structure was fragmented and the UX felt outdated. It was in need of a complete transformation.
This case study will show the first part of the transformation that took 12 months of 5 designers, 3 product owners, 2 researchers, and 100+ engineers. It will focus on my role in user journey mapping, product strategy, and design leadership as Product Design Lead.
Everything starts with
Mapping User Journey
Why Map User Journey?
Our user base is made up with more than 4 different key stakeholder groups, such as home owner, construction contractors, project manager and architecture firm, who use our platform to find new contractors, submit proposals, and process payments. They interact with each other both online and offline to work together on projects.
When the scope of product is this big, understanding end-to-end user journey becomes very important for everyone, not just designers. As Product Lead, I saw the importance of mapping user journey for each and every stakeholder, end to end, for both online and offline experience.
This shows the big 5 phases of construction journey of a home owner.
With 5 designers on board, the first thing to do was to draw userflow from high level perspective. I divided designers into clusters and assigned one stakeholder per cluster and a specific phase in user journey to research and map out.
After 2 weeks, all designers would come together, share their assigned stakeholder's user journey, and weave the whole journey together.
Exchange of Data within Userflow
After mapping the whole user journey, I led the team to further dissect each phase into smaller granular phases and identified information 'junctions.' In these 'junctions,' users exchange information, such as messages, legal documents, payment, and progress status, either online or offline. Each designer interviewed internal stakeholders to understand when and who makes information input and where it was flowing.
Through these exercises, design team created two high level userflow map and UX snapshot, called Omni-Channel Service Flow and Service FlowShot, of the entire service.
Omni-channel Service Flow shows more than 200 'junctions' of information exchange between multiple stakeholders, from start to finish of a construction project, within our software product. Service FlowShot captures end-to-end user experience of the primary user (home owners.)
After multiple revisions, the final products were shared to every member and team at the organization.
Leveling everyone's understanding with
Userflow
After being published online via Figjam, Service Flowshot was being used by everyone at the organization almost instantaneously. It helped not only the product team, but also customer service team and operation team in their communication with clients.
If Service FlowShot had focus on understanding what's happening at each phase throughout the whole journey of a user, Omni-channel Service Flow was designed to show the flow of information and its direction between stakeholders. Naturally, it was used as the central reference and guide to engineers, product owners, and project managers, as it showed when and where a piece information was being shared, where it was coming from, and to whom it flowing.
This was a great validation and clear indication of success for design team. Everyone at our organization was in need of better understanding and visibility of what users experience in our system and design team provided it successfully.
Identifying each stakeholder's
Pain Points
Understanding Everyone in the System
Key stakeholders' pain points are at the core of product hypothesis and business model. And as a platform, our SaaS product is serving everyone in the construction ecosystem as key stakeholders; Typically in a construction project, money flows from top to bottom. Bank finances the project, home owner pays head contractor, and head contractor pays subcontractors, so on.
Painkiller over Vitamins
Working for startups almost a decade, I know that creating painkiller product is always better than vitamin product that offers lots of supplementary value without fixing the root cause. I guided the team to embody the concept and distinguish 'must-have' from 'good-to-have'.
In order for the product team to fully understand what 'must-have' features were going be, we had to first understand where pain points for each stakeholder occur and what we can do to change that.
The brief map I created above shows major pain points for each stakeholders and the causes; Each stakeholder was suffering from some version of lack of information visibility or transparency issues, such as not being able to get updates on time from the site or track payment status.
These were critical pain points; Such lack of information can cause mistrust for everyone involved, and mistrust can lead to payments latency, which is the main cause of legal disputes.
This was a very clear shot of opportunity for the product team because, if our team can gather data, we can provide visibility and transparency within our product.
Building features on key
Value Propositions
The Best Way to Deliver Instant Value
Building 'must-have' features around key value propositions is the best way to deliver instant and irreplaceable user value.
Again, as a team, we knew that transparency and high visibility for financial overview and project status were very valuable to users but not conveniently delivered or easily available, because they have to come from subcontractors and multiple vendors (in other words, it comes from bottom-up.) To show such information within our product meant restructuring of data, changes to information architecture and APIs, and major UX changes.
As Product Lead, I hosted a lot of meetings to advocate for the imperative user values and building features that align with them. It was very clear to me that delivering core value propositions would be the key factor that sets our product apart from everyone else in the market.
Long discussions and a lot of effort to align key members such as CTO, CEO, Head of Product, and Head of Operation, continued.
Must-have Value & Features
Out of many, a batch of 'must-have' user value proposition was developed and finalized; With product owners and researchers, the team designed features that directly co-relate to the key value propositions.
The chart below shows the final features (type of information) and list of stakeholders who can access each information.
Each square has a type of information, which is shown only to certain stakeholders.
Fostering everyone's
Design Leadership
Although the project took 12 months to launch, it was developed in sprints with silo/squad setting. I was leading the entire product design direction, so I participated in all product strategy meetings in addition to designing products in my own silo.
In full honesty, It was not easy to oversee and align the whole system's design direction while designing a part myself. Working 40 hours a week started to not cut it, so 60-hour work week became the new normal.
In the process, I learned an important insight; When every designer is in complete sync with the direction of product design, design output is more coherent and the process more efficient and harmonious. And to achieve this level of collaboration and synchronicity in such big project, every designer has to become a leader, too. Whether it is for herself or within his silo, a designer who is practicing leadership goes extra mile to learn more for herself and perform on an another level.
Michelle is always customer-focused and produces results based on user-centric approach. She empowers the whole team with her positive and proactive mindset.
Ben, Head of Product
Leading to create full-scale product transformation of this magnitude within 12 months was not an easy task. Every designer on the team poured so much energy and effort, and a lot of overtime happened before we launched the new product.
I hosted an retrospective session after successful launch of the product, and in the session, designers shared their own experience and take-aways from the intense 12-month project.
Most of designers were satisfied with their design process and outcomes. And every one of them was proud to be a part of the journey and achievements we made as one team. It was a great validation and measure of success for the design team.
Part 2 of the case study will focus on developing the complex SaaS product's UI design outcome.