I came on as a freelance product designer when the product was still being defined, working with another designer, Faye, and reporting to the co-founder. We were a team of three on the design side of V1.
There was no existing product to redesign. We were figuring it out from scratch.
We designed the experience for environments, wallet creation, transaction data, security settings and backups. Faye and I did not really split the work as we were on calls constantly, and most decisions got made in the conversation rather than handed back and forth. He designed a lot of the reusable components that kept the system consistent.
Finding our way into the product
We started with the requirements. The co-founders would walk us through how a part of the product was expected to work, we’d ask questions, and get clarity, research and implement.
The process was fairly fluid, some decisions were straightforward, others only became clear once we started designing them. The first thing we mapped was onboarding: the flow from the point someone entered the product through the steps they had to complete before they reached their wallet.
Click throughGetting into the product1/5
Click to advance
As we worked through onboarding, it led us into the product itself.
Starting with the wallet
The master wallet was central to how Blockradar worked, so we needed to figure out what creating one looked like. Here we made it easy to create in one go.
Click throughCreating a master wallet1/6
Click to advance
There was the question of Test and Live. A wallet created in Test shouldn’t be mistaken for one that can hold real funds. We carried the environment into the creation flow and made the consequence of the choice explicit.
That led to another question: what should happen when someone switches environments? We designed confirmation states and supporting copy around that decision, so users had a moment to verify what they were about to do.
What sits inside a wallet
A master wallet could have multiple child addresses.
A child address has a lot of information attached to it. We could have shown balances, activity, asset information, creation details, status and other blockchain-specific data all at once, but that would have made the table difficult to work with.
We chose to keep the first layer focused on what someone would need most often, while allowing the rest to be opened when necessary. That kept the main views readable without taking away the detail an operations team might need when investigating something. The same approach carried into transaction metadata.
Then came transactions
Once we had the wallet and address structure in place, we moved into what happens after money starts moving.
The requirements included a lot of transaction information. We didn’t want all of it competing for attention in the table, so the main view showed:
Type · Date · Sender · Recipient · Amount · Asset · Status
The rest was available when needed. We also designed the transaction detail view around the events that happen throughout its lifecycle. For example:
Deposit confirmed → Asset swept → Deposit webhook sent → Sweep webhook sent
That became particularly useful for failed transactions. If a sweep failed, the failure reason appeared in the activity log and the relevant action could be taken from there. We didn’t want someone to discover the problem in one place and then have to hunt through another part of the product to fix it.
Advanced transaction filters
The table worked well for browsing, but we had to think about what happens when a business has thousands of records. We designed filters around the information someone would realistically use when investigating a transaction:
Reference · Hash · Recipient · Type · Status · Asset · Date
Filters could be combined, and the applied filters stayed visible so it was always clear why the table had been narrowed.
Small decisions like this came up repeatedly: what is the user trying to find, and what is the quickest way to get them there?
Designing the failed states
Once the main flows were taking shape, we started working through the several edge cases we hadn’t previously considered.
01Losing access to 2FA
If someone lost their authenticator, they couldn’t simply turn 2FA off. We worked through a recovery path:
Password → Email OTP → New authenticator → Confirmation
The “forgot 2FA” route was also kept close to the verification step, so someone didn’t have to work out where to go after getting stuck.
02Backing up a wallet
Backup was another flow where the edge cases mattered. The experience needed to make it clear that the information being downloaded was sensitive, while still getting the user through the process without unnecessary friction. We broke it into five steps, with the warning before the action.
Click throughBacking up a wallet1/5
Click to advance
03Failed sweeps
A deposit could come in successfully and the sweep could still fail. Showing a failed status wasn’t enough on its own, so we surfaced the reason and put the retry action next to it.
Working through the details
A lot of the work happened in questions the requirements didn’t cover.
How should a wallet address be displayed without taking up half the screen?
When should we show the full transaction hash?
What information should appear before someone opens transaction details?
How should a user know which environment they’re currently in?
What happens when there are no wallets yet?
What should happen when a transaction is pending, fails, or needs another action?
Where should a user go when they’ve lost their authenticator?
These questions rarely had an obvious answer in the requirements. Faye and I worked through them together and brought the bigger decisions back to the co-founder. That back-and-forth shaped a lot of the final experience.
Some answers changed as we designed. We’d put something on screen, realise it didn’t quite work, and go back to the flow.
Bringing V1 together
By the end of the engagement we had worked through the core V1 experience across onboarding, wallets, child addresses, transactions, security, backups, usage and settings.
The dashboard brought the main pieces together: wallet balances, address and transaction counts, deposits over the year, recent activity, and usage against plan limits.
More importantly, we had a shared direction for how those pieces should work together. The work later became the starting point for a product that continued to expand well beyond the V1 we designed.
Blockradar has since grown considerably, including new products and significantly higher transaction volumes. In 2026 the company reported crossing $1B in transaction volume.
Design: Faye and me. Product direction: the Blockradar co-founder. Freelance engagement, 2024.
Aether Energy
02/05
Building Aether from 0→1
I joined Aether as its first employee and first design hire, working closely with the founding team to take the product from early ideas to a working platform.
I worked solo for around six months before I was joined by another designer, Godson, and I closely collaborated with him.
In one year, we designed and shipped five major parts of the product: Solar Proposals, CRM, Solar Design, Document Manager and the website.
We moved quickly because there was very little room not to. New features were being shaped, designed, tested and shipped continuously as we learned from customers and sales conversations.
That work helped Aether sign a $500K ARR deal with SalesRabbit, grow to nearly $1M ARR, and raise $2.5M in seed funding within the year.
My role covered product design across the platform, from figuring out early workflows and information architecture to designing the interfaces and building the marketing site in Framer.
The product has since evolved and Aether has rebranded as Feldy.ai to pivot solely into roofing. The work below is from the period when we were part of the team building the original platform.
Here’s what we worked on
Solar CRM
The deal before the proposal
The CRM was where the sales side of Aether came together.
Solar companies were running leads, deals, site information and follow-ups across separate tools and spreadsheets. We designed the CRM: the pipeline, the deal record, the views reps build for themselves, and the handoff into design and proposals.
Starting with the sales workflow
We started by mapping the sales process from a new lead through to a signed deal.
There were a lot of possible states and pieces of information, so the first challenge was deciding what needed to be visible at each stage and what could stay inside the deal.
The home screen carries what a sales lead checks first (projects, total sales value, installs by state and the win ratio), with the pipeline from lead to done underneath it.
That shaped the CRM around the sales pipeline rather than a collection of separate records.
Making the pipeline useful
The pipeline needed to answer a simple question quickly: what is happening with my deals?
We worked through the structure of the deal stages, what information belonged on each card and how much detail could be shown without making the pipeline difficult to scan.
Deal Hub reads three ways: a board of stages with each column totalling its own value, a table, and a pricing view.
ScreensDeal Hub, three ways1/3
Click to advance
Filters run on deal owner, status, sales rep, location and date, and a filter can be saved and reopened later. A table view is built column by column, renamed, and pinned to the top.
Click throughMoving a deal across the board1/4
Click to advance
Click throughFiltering the board, and keeping it1/9
Click to advance
Click through1/5
Click to advance
Click through1/6
Click to advance
Opening a deal then provided the deeper context without losing the connection to its position in the pipeline.
Bringing the deal together
A solar deal can involve much more than a contact and a dollar amount.
Customer information, site details, proposals, documents and activity all become relevant as the deal progresses. We worked on bringing those pieces together so sales reps could understand the state of a deal without jumping between disconnected parts of the product.
ScreensThe deal record1/7
Click to advance
The record is tabbed: the overview, notes, files, the activity log, comments, and the building the system is going on.
Notes and tasks are the two things a rep does most from inside a deal, so both happen without leaving it.
The note editor takes blocks from a slash menu and formats inline, and it will draft a note on request: the rep asks, reads what comes back, and keeps it or doesn’t.
Click throughWriting a note, with help1/8
Click to advance
A task carries the deal it came from, so it shows up on the deal and in the rep’s task table.
Click throughCreating a task1/6
Click to advance
Designing for the handoff
The CRM also had to connect with the rest of Aether.
A deal doesn’t end when a salesperson closes it. The information collected during sales becomes useful to the teams working on proposals, design and installation.
We designed the CRM with those downstream handoffs in mind, so information captured early could continue to be useful later in the lifecycle.
The result was a CRM that became part of the same system as the rest of the solar workflow.
Solar design tool
Starting from a real building
This was one of the more complex parts of Aether. A solar system starts with a real building, so the designer needs to understand the site before deciding what goes on the roof.
We worked on the experience for building that site model, including roof faces, pitch, azimuth, base height, obstructions, trees and fire pathways.
Building the site
Screens1/4
Click to advance
Screens1/2
Click to advance
The designer could define the different parts of the building and work with the information attached to each one. A roof face, for example, wasn’t just a shape on the screen. It had information that affected the eventual solar design.
Designing around the site
Screens1/2
Click to advance
We also had to account for the things that get in the way of a solar installation. Trees, obstructions, pathways and local requirements all had to be considered while designing the system.
The interface had to keep all of that available without getting in the way of the actual design work.
The whole path is one move: a rep opens the Design Hub from the deal itself, models the roof, and the finished design goes back onto the deal it came from.
The configurator end to end, from a deal in the CRM into the Design Hub, the roof outlined on satellite imagery, pitch, azimuth and height set on each face, then the design attached back to the deal.
The design hub also got a quick AI design, in beta: an address goes in, and a sited model with a first array comes back to adjust.
Quick AI design: the address on satellite imagery, the roof traced and modelled, then panels placed and simulated, with irradiance graded across the array and the system summary alongside.
Solar proposals
Where the work became something a customer could see
The proposal was where the work we were doing inside Aether became something a customer could see and understand.
Solar proposals have a lot going on behind them. System design, energy production, pricing, financing and other project details all have to come together before a sales rep can put something in front of a customer.
We worked on two versions of the proposal experience.
Pro
The Pro proposal was built around the sales rep. They needed more control over what went into the proposal and how it was presented to the customer. We gave them room to customise the experience without losing the information that mattered.
Lite
Lite was more straightforward. It was designed to get the important information in front of the customer without making them work through everything happening behind the scenes.
The two versions shared the same underlying product, but they had different jobs to do.
ScreensThe proposal builder1/3
Click to advance
Click throughPutting an image on a page1/4
Click to advance
Click throughPutting a table on a page1/4
Click to advance
Click throughAdding a section to a template1/4
Click to advance
Click throughThe proposal a homeowner receives1/9
Click to advance
Document manager
Like DocuSign, but for solar
Solar projects create a lot of paperwork.
Once a customer agreed to a proposal, the contracts, agreements and disclosures still had to happen. We worked on the document manager that handled all of it: built, sent, signed and tracked without leaving Aether.
Everything in one table
The agreements list carries what someone would search by: the deal, the proposal it came from, the template used, the date it went out, and where it stands (pending, signed, voided or not yet sent).
Templates sit on their own tab. Each one records who created it, who gets copied in, and which parts of the product it’s switched on for.
ScreensThree tables1/3
Click to advance
Building a template
A template starts with the documents themselves. Upload the files, name it, decide who gets copied, and choose where in the product it can be used.
ScreensThe template itself1/2
Click to advance
Placing the fields
Then the fields a signer has to complete get dropped straight onto the document.
Signature and initials sit in their own required group. Text, checkbox, dropdown, email, phone and date cover everything else. Each field gets a label, an optional tooltip, and a switch for whether it’s required.
ScreensFields on the page1/3
Click to advance
Below the standard fields sit Aether’s auto-fill variables: consumption, production, system size, solar offset and savings. They pull from the deal and the solar design, so the numbers in a contract are the ones already produced upstream.
After it goes out
A sent document keeps its own record: which deal and proposal it came from, who received it, when it was signed, and the message it went out with.
And across all of them, the team could see how the paperwork itself was performing.
ScreensSent, signed, counted1/2
Click to advance
Website
How the company explained itself
We designed and built both V1 and V2 of Aether’s website in Framer.
V2 became more than the marketing site. We used it to walk customers through the product during demos, and it became the reference point for the product experience as we built out the platform.
It eventually became the site we used around the time Aether raised its $2.5M seed round.
We unfortunately didn’t save visual samples of either version, so there are no website screens in this case study.
Internal Healthcare System
03/05
A suite for senior care
I worked with the Internal Healthcare team alongside two other designers from my agency, Homalabs, to design and bring a multi-sided senior care platform to life. I coordinated and led the design team on this one, setting the direction across all five products while we split the work between us.
This was a large product with several user types, each with different needs and responsibilities. We worked across the product experience, from the public-facing website to the family looking for care, the provider managing clients and referrals, the caregiver handling their work, and the internal team keeping everything moving.
We stayed close to the client throughout, from requirements and early flows through wireframes, visual direction, product design and multiple rounds of reviews. We designed the different parts of the platform alongside each other so that information could move cleanly between them.
It took several months of meetings, refining and building. For part of it the process was agile: we were designing alongside the engineers.
The entire engagement brought over a thousand screens.
The system is now fully functional, with 245+ care professionals onboarded and families actively using the platform.
Family posts → Admin approves → Provider is referred → Caregiver works the shift → Family reads the log
The product
We worked across several connected products:
Each section below covers the products we worked on.
Website
The public-facing experience where families and care professionals first encounter the platform.
I worked on the website as the lead designer.
We started with a long list of requirements and roughly 15 pages worth of content. Before getting into the visual design, we sat down as a team to work through the content and sketch wireframes for each page. This helped us figure out what each page needed to communicate and how the information could be organised.
From there, we created a moodboard and explored a few visual directions. We reviewed these with the client, talked through what felt right and what didn’t, and kept refining until we had a direction we could all agree on.
One thing the client was specific about: real images of people, and visuals from the platform itself, in place of illustrations. That decision carried through every page: each header leads on photography or a product shot.
Making each page its own
Once the direction was settled, we didn’t want to copy the same layout across all 15+ pages.
Each service had different content and a different story to tell, so we treated the pages individually. We kept the same visual language across the site, but played with layouts, imagery, sections and interactions so that each page had its own character.
ScreensWebsite headers1/6
Click to advance
Home Care
Click throughHome Care1/7
Click to advance
The Home Care page is for people looking for support that can be provided in their own homes, whether that’s help with everyday activities, personal care, or ongoing support.
There was quite a bit of information to communicate, so we focused on breaking it into clear sections without making the page feel overwhelming.
Assisted Living
The Assisted Living page is for people looking for a more supported living arrangement, where care and day-to-day assistance are available within a residential setting.
Click throughAssisted Living1/7
Click to advance
The content was different from Home Care, so we gave the page its own structure rather than repeating the same layout.
Provider Directory
The directory is where families can browse care providers and find options based on the kind of care they’re looking for.
Unlike the service pages, this wasn’t about explaining a service. It was about helping someone find and evaluate their options.
Click throughA provider’s page1/4
Click to advance
The rest of the site
There were other pages covering the remaining services, resources and information the client wanted to make available. Each one followed the same visual direction, but we adjusted the structure depending on what the page needed to communicate.
Reviews and handoff
The website went through several rounds of review with both the client and our team. We were making changes while engineering had already started building, so the design and development work happened alongside each other.
By the end, we had worked through 15+ pages, from the initial wireframes and visual direction through detailed UI and the handoff into development.
From there, we moved into the portal side of the platform.
Family portal
For families looking for care, registering loved ones and managing their care journey.
The family portal is where someone starts when they’re trying to arrange care for a loved one.
We needed information about the person receiving care, what kind of support they needed, where and when they needed it, and eventually enough information for the right provider or caregiver to take over.
We worked on the family experience around that journey, from creating a loved one’s profile and submitting a care request to reviewing care information, managing billing and keeping up with what was happening.
Starting with the person
One of the first things we had to think through was what information we needed from a family at the beginning.
There was a lot we could ask for, but asking for everything upfront would make the first interaction feel like paperwork.
So we worked through the flow around the information that mattered at each point, gradually building the loved one’s profile as the family moved through the process.
Turning “I need care” into a useful request
The next part was translating what a family knows about their loved one into something a provider can work with.
A family might know that their parent needs help at home, but that isn’t enough information to match them with the right care.
The request needed to capture things like the type of care, specific needs, location, schedule and other requirements, without expecting the family to understand healthcare terminology or think like a care provider.
The form does the translating. A family answers in plain language; the request comes out structured enough for a provider to price it, staff it and screen for it.
That shaped how we structured the questions and grouped the information throughout the flow.
Giving families something to come back to
Once the request was submitted, the experience changed.
The family was no longer filling something out. They were now waiting, reviewing options and eventually managing an ongoing care arrangement.
So the portal became less about forms and more about keeping track of what was happening.
Important information such as the status of a request, provider details and care information needed to be easy to find without making the dashboard feel crowded.
ScreensFollowing a request through to a hire1/3
Click to advance
The rest of the portal
The same thinking carried into the rest of the portal.
Billing, care information, communication and updates are all things a family might need at different moments, so we kept them accessible without letting them compete with the primary task on the screen.
ScreensCare information, kept in one place1/4
Click to advance
Provider portal
For agencies managing referrals, clients, caregivers and care plans.
The provider portal had a lot of moving parts. The hardest part was figuring out how all of them should fit together when an agency is managing several clients, caregivers and referrals at once.
Before any of it was designed, we mapped the portal as one flow: every branch an agency could go down, and what each branch had to reach. It came out as seven areas hanging off one account.
Getting an agency onto the platform
Before an agency can be referred anything it has to exist on the platform properly: the right business type, a complete profile, a verified email, and the services it offers.
Click throughSetting up an agency1/7
Click to advance
The dashboard is where all of that lands. It opens on the four numbers a provider checks first (referrals received, pending, active and expired), and keeps the new ones directly underneath them.
Screens1/2
Click to advance
Deciding whether to take a referral
We had to figure out what a provider needed to see before deciding whether to take on a family request.
The early thinking put too much information in front of them. We worked through the referral flow to separate what helps someone make the decision from what they might only need after accepting the request.
Dashboard
Referrals
One referral
That gave the referral a clearer progression from review → decision → client.
What happens after “accept”?
One of the things we had to solve was what happens to all the information once a provider accepts a referral.
We didn’t want an accepted referral to become a completely new record that the provider had to build again. The information already collected needed to carry into the client profile and become useful there.
That affected how we structured both the referral and client experience.
The client profile had too much information
The client record was another place where it was easy to put everything on one screen.
Instead, we worked through the information according to what the provider would need most often versus what they might only need when investigating a particular client.
The result was a more focused overview, with care details, documents, caregivers and other information accessible without competing for attention.
Staffing was a matching problem
Assigning a caregiver wasn’t as simple as showing a list of available people.
The provider needed to consider the client’s needs alongside the caregiver’s information and availability. We had to work out what information should be visible at the point of assignment so the provider could make that decision without jumping between different records.
That led us to connect the caregiver and client experiences more closely.
Keeping one system consistent
This was probably the biggest design challenge across the product.
The family, provider, caregiver and admin don’t use the system in the same way, but they’re working with many of the same records.
A change made by one person could affect what another person sees later. So as we designed the provider experience, we kept tracing those handoffs through the other parts of the platform.
That meant thinking beyond “what should this screen look like?” and asking “what happens to this information after the user leaves this screen?”
That way of working carried through the rest of the product.
Caregiver app
For caregivers managing their work, care visits and client information.
Vivian, one of the designers, owned the caregiver app experience, and I worked with her over a series of calls to shape the journey from job discovery through to completed visits.
We had to work out how caregivers would find relevant jobs, make informed decisions, manage accepted work and record care in a way that still worked for the provider and family on the other side.
Turning the job board into a useful starting point
The job catalogue was one of the first areas we worked through.
We had a lot of information available for each job, but putting everything into the listing made comparison harder. We reduced the initial view to the information that could help a caregiver decide which jobs were worth looking at, then used the job detail page for everything else.
The job board
Emergency requests
What a caregiver sees before accepting
We worked through the information hierarchy and the different states around accepting or declining a job, including what the caregiver sees before making the decision and what happens afterwards.
Job details
The whole request
Designing the caregiver’s work after acceptance
Once a caregiver accepts a job, the experience changes.
We separated active work from available opportunities and structured the experience around what the caregiver needed to do next. This became the foundation for moving from an accepted job into the scheduled visit and eventually completing it.
The week
One shift
Swapping it
Money moving
Reducing the client record to what matters during care
The client record contained significantly more information than a caregiver needed during a visit.
We worked through the hierarchy as a team to determine what should be immediately available while providing care and what could sit deeper in the record.
The goal was to make sure the caregiver didn’t have to navigate through information that wasn’t relevant to the task in front of them.
The care plan
Who it is for
Designing the care log for three people
The care log was one of the more important pieces of the workflow, because the person entering the information isn’t the only person who will use it.
We designed the experience around the caregiver’s need to record a visit efficiently, while considering how that same information would later be interpreted by the provider and the family.
That meant being deliberate about what we asked caregivers to record, how we structured it and how the resulting information would appear elsewhere in the system.
The caregiver’s care log screen — I need the Figma node for it. The family’s side of the same record is in the Family portal tab.
The design challenge
The interesting part of this product wasn’t the number of screens, but designing a simple experience on top of a workflow with a lot of details and structures happening underneath.
As a team, we had to continually decide what the caregiver needed now, what they could find later, and what information needed to remain consistent when it moved between the caregiver, provider and family experiences.
Admin
For the internal team managing providers, families, requests and the wider platform.
The admin portal sits behind everything else in the platform.
While families, providers and caregivers each have their own workflows, the admin team needs visibility across all of them. They review requests, manage users and providers, track referrals and step in when something needs attention.
The challenge was giving them enough visibility to manage the system without turning the dashboard into a wall of information.
Making the dashboard useful
Families, requests, providers and activity all land in one place, ordered by what needs attention.
The first thing we worked through was what an admin needs to know when they log in.
There are families to review, requests coming in, providers on the platform and activity happening across different stages of the care process. We prioritised the information that could help an admin understand what needed attention first, rather than displaying every available metric.
The side navigation was broken down to make it easy to navigate across pages.
Reviewing family requests
ScreensFamily requests, and who they came from1/3
Click to advance
A family request is the starting point for much of what happens in the system, so the admin workflow needed to support more than viewing submissions.
We worked through how requests should be reviewed, what information should be visible during that review and how an admin moves a request forward once it has been approved.
The goal was to make the review decision clear without making the admin work through information that wasn’t relevant to it.
Managing providers
Admins need to know who is on the platform, what services they provide and whether they are ready to receive referrals. We designed the provider views around that information and the actions an admin might need to take.
This also meant thinking about what should happen to provider information as it changes.
Keeping track of the handoffs
A request from a family, through the admin team, to a provider, and the status it carries at each step.
One of the more important things we worked through was visibility across the referral process.
A request can move from a family to the admin team and then to a provider, so it shouldn’t become unclear where something currently sits.
We designed the statuses and supporting views to make those transitions visible, giving the admin a way to understand what has happened and what still needs action.
Where admins step in
ScreensWhere exceptions surface1/3
Click to advance
The admin is also where exceptions eventually surface.
If information needs to be corrected, a request needs attention or a user needs help, the admin needs enough context to act without jumping across several parts of the platform. That’s why we specified which jobs are emergency.
That shaped how we approached detail views and actions. The admin should be able to understand the situation first, then act from the same place.
Overview and control
One overview, and the six areas an admin drops into from it.
The admin portal gave us a different design problem from the family and caregiver experiences.
That balance between overview and control became the main consideration throughout the admin experience.
Where it got to
Live at internalhealthcare.com, operating out of Tampa, Florida, with 245+ professionals listed.
The engagement ended in a hand-off, and one of the designers from the team stayed on with the client to continue the work.
Uiland
04/05
Building UIland
Most design inspiration platforms didn’t cover African products. We wanted to change that.
I joined two engineer friends to co-found UIland in 2023, taking on the design side as the only designer on the team. We started with a small collection of African web and mobile products. Since then, it has grown into a design platform with 1,000+ products, 100K+ visits and thousands of dollars in revenue.
Building with a two-person engineering team
I work directly with both engineers to take ideas from rough concepts to shipped features, from product direction down to the details of the interface, and into how the library, website and wider experience have evolved.
From a library to a product
The first version was straightforward: make African products easier to discover and study.
As the library grew, we started asking what would make UIland useful beyond browsing screenshots.
That led us into websites, app store screenshots, OG images, interactions and other references designers could use in their work.
Designing around real usage
We use Cloudflare Web Analytics for aggregate visits, page views and page load times, and Google Analytics, Hotjar and other tools to understand how people use the platform, where they drop off and what keeps them coming back. I use that alongside user feedback and conversations with the team to decide what needs attention.
How a change gets decided: the numbers and the feedback point at something, we pick one thing, ship it, and watch the same measures again.
This has shaped the discovery experience, information architecture, SEO and the features we’ve added over time.
Some visual references
Explore Similar
The detail sheet
Where it is now
1,000+
web and mobile apps documented
100K+
visits
$20K+
in revenue
2023
founded
What began as a small collection has grown into 1,000+ products, 100K+ visits and thousands of dollars in revenue.
We have returning designers and paying subscribers, and the platform has been able to fund its own growth without sponsors.
UIland has given me the opportunity to work across the full product: co-founding it, owning design, working directly with engineers, using real usage data to understand user pain points, and continuously iterating to improve the overall experience.
Reown Africa
05/05
Building Reown
Reown is building a digital platform around the automotive repair experience, connecting customers, partners and repair hubs through one system.
I worked with the Reown team as a product design consultant for about a year, contributing to several parts of the product. Some of the work involved improving existing experiences, while other parts were designed from the ground up.
I worked closely with the founder, Ayodeji, the product manager and engineering team throughout the engagement, moving between product decisions, design and implementation as features were being shipped. We had regular reviews to work through requirements, explore different approaches and adjust designs as the product evolved.
My work covered the customer experience, affiliate and partner platform, and repair hub reporting tools, including both new experiences and improvements to existing products.
Technician logs the repair → It becomes the car’s history → The owner reads it → A reminder brings them back
Below is a breakdown of the different parts of Reown I worked on.
Website
Selling a record, not a repair tool.
Reown’s value only appears a year after a repair, which makes it hard to sell in a single visit. The site leads on the phrase the business rests on: a vehicle history database. The cost argument sits high up: push notifications for reports and due dates, in place of phone calls, SMS and the staff time behind them.
It also has to speak to every kind of shop without fragmenting. Hybrid and EV centres, tire shops, truck and collision repair, quick lube, wrap and detail all arrive at the same promise.
Setup is shown as three steps (create an account, add repair hubs, generate invite codes for customers), so an owner can see the size of the commitment before booking a demo.
ScreensThe marketing site1/6
Click to advance
Admin dashboard
Every workshop on one screen.
For owners running several branches. Hubs run along the top as tabs, and one table switches between reports, customers, vehicles, estimates and invoices, so comparing two branches never means opening two screens.
ScreensThe account overview1/2
Click to advance
Everything a multi-branch owner checks daily is on one screen, and the four lists underneath are the ones that generate work rather than just describe it.
ScreensInside one repair hub1/2
Click to advance
Selecting a hub keeps the same shape: the counts and the table just narrow to that branch.
This is the record the whole product exists to build. Build and specification sit above usage and maintenance. The reports filed against that car run underneath: a year-old repair is one scroll from the VIN.
Search accepts a VIN, a name, an email, or a phrase from the job itself: brakepad fix, wheel alignment.
Appointments carry the reason in plain language (“To fix my tyres and wheel and align it since I need”) alongside the technical summary.
Customer onboarding lives here too, and it was the riskiest part. Multi-branch shops had to get non-technical customers onto an app, which is where products like this usually die. The flow became: the hub generates a code, the customer enters it, and their vehicle and its history are already there. Nothing to set up, and something of value on the first screen.
Motor Rescue, running three branches, described going from “overwhelmed and stressed” managing across sites to work that was measurably cheaper to run.
Reporting app
Built for hands that are full.
The technician is the only person who can create the record, and they are the least able to sit and type. So the reporting flow got the most attention: short steps that survive being put down mid-way, defaults drawn from the vehicle’s last visit, and an estimate that becomes an invoice without re-entry.
The whole platform depends on this one flow being faster than writing it down. It carries the commercial side of the job as well (accepting an appointment, sending an estimate, issuing an invoice), so the record and the money come from the same place instead of being reconciled later.
This is the reporting app repair hubs run on today. I kept testing after launch and designed the feature updates that came out of it, for this app and the customer one.
Customer app
The same record, read by a driver.
The same record has to read two ways. In the shop it is parts, labour and diagnostics; on the owner’s phone it has to answer “is my car alright, and what’s coming.” I designed the customer view as a timeline with plain-language summaries over the technical detail, so trust does not depend on understanding the jargon.
Reminders are the retention mechanic. Phone calls and SMS were a real line of cost, and the follow-up that drives repeat work was the first thing dropped on a busy day. Moving reminders into the app made them free and automatic, but only if the timing felt like care rather than marketing, which meant tying each reminder to something specific in the car’s own record.
A branch locator sits alongside it, so an owner can compare distance and book from the same place they read their history.
Where it landed
Reown ships today as a three-app platform for repair hubs of every kind: EV and hybrid service centres, tire shops, truck and collision repair, quick lube, wrap and detail.
The work took the company from nothing to a product it could raise on. It closed a funding round, signed global partnerships, and onboarded its first repair businesses.
Motor Rescue, running three branches, described going from “overwhelmed and stressed” managing across sites to work that was measurably cheaper to run.
Still putting this one together
Reown is live. I’m just a little behind on writing it up, but I’d be glad to walk you through it in the meantime.
