Initiative
RenoRun is an on-demand construction material delivery company (think Uber Eats for Home Depot). During the first 3-4 years of business, they had only a mobile app for iOS and Android users.
As the company progressed, it shifted more and more from a B2C to a B2B model.
Our ideal customers wanted a desktop app to facilitate their planning activities as most of their ancillary processes happen on a desktop.
By speaking with contractors, I was aware of their need to plan the day before their busy day. Most of them at their home desk or at the dinner table. Many even mentioned wanting to have a desktop version of our app so they wouldn't have to context switch as much.
Build a web platform that will allow customers to:
Order Materials
Manage their orders
Manage their account
It was also decided to launch a brand new marketing website at the same time.
The scale of this project was bananas. With so many moving parts, this one really tested my organization skills.
On top of this: RenoRun didn't have a design system. Not in Figma nor in code (especially since the e-com site was going to be built in a new language). And most of our engineers hadn't even heard of design systems, atomic design or anything alike. So we took this opportunity to begin our design system proper.
We knew our competition. From an experience point of view, they weren't doing anything amazing nor innovative. Not that we were aiming to build something completely new. But we wanted to have our own spin on the experience before simply copying what our competitors were doing. Doing this lead to many unseen ideas for a better buying experience of construction materials.
The customer journey can be broadly sectioned into 4 parts:
FIND — Finding your materials (search, PLP, PDP)
BUILD — Build your material list (shopping cart)
SUBMIT — Submit your order (checkout)
MANAGE — Manage your orders/account
Yellow post-its were used for calling out any questions, assumptions or concerns. We also dropped any ideas below the green line if they were deemed not critical for the moment. To be explored later.
Parallel Development
To avoid a complete waterfall process, we decided to build components and pages as we designed them. Once components reached a certain level of certainty (70 - 90%) engineers could start building them without the fear of any major structural changes later on. The remaining 10% certainty (100%) came when components were fully polished and "Done". Providing Figma links to each component file in our design system with interaction instructions and usage examples.
Component Tracker
Page Tracker
Divide & Conquer
You can see above the different owners per component or page. Each designed owned a part of the experience. At one point we had such a solid system, we could produce massive one-off prototypes in less than 30 minutes. We used these to demo with various stakeholders and the company at large.
Marketing Pages
Julia owned the marketing pages on since her background was primarily in branding and marketing. Not to mention she'd already been working on the marketing site as a freelancer before we hired her and kicked off the e-commerce project.
Shopping Experience
Edmund owned the shopping experience since he had some prior experience working at ALDO on their e-commerce site. He was most interested in that area, so all the better!
Checkout Experience
Having designed checkout flows for 2 previous startups, supported by countless hours reading checkout optimization literature, I felt good about this. Besides, with checkout being such a high risk area, I felt compelled to take this on as the only senior designer on the team.
Account Management
I had previously worked on RenoRun's order console; A custom tool to build and manage orders. The code however was deprecated. So rebuilding this tool was on everyone's wish list.
With one specialized component, we could repurpose 80-90% of our ecom screens to rebuild our internal console.
Ultimately the hybrid e-com-console plan fell through. The engineers deemed this hybridization too risky. That said, it didn't change any of our current work, so nothing was lost here.
💭 Final Thoughts
Although this build was successful, it took much longer than anticipated. Knowing what I know now, I would've pushed for potentially using an e-commerce framework. Where nearly all of the components, pages and analytics are built-in already. Only years later did RenoRun start using 3rd party tools. Up to this point, everything RenoRun used was custom build. From the app to its internal tools (except for finance and data softwares). This would've saved us a lot of time. Refocusing that time to creating assets that tend specifically to the needs of contractors and to the unique nature of construction materials.