Home Work About Archives Contact

Selected work

Blockradar

01/06
The Blockradar dashboard

Blockradar serves businesses that want on-chain wallets without building the infrastructure. I designed the first version in 2024 with Faye (product designer), and handed over a production-ready Figma file: scalable patterns, a responsive version, handoff notes. Blockradar has since processed $1.3B across 1.1M transactions, with 189.3K wallets created.

Designing Blockradar’s V1: wallet infrastructure for operations and finance teams

The problem
Operations and finance teams needed on-chain wallets they could run without a blockchain engineer, and the product could not hide the complexity, because the people paying for it needed to see exactly what was happening.
My role
One of two designers on V1, with Faye, reporting to the co-founder. Onboarding, wallet creation, transactions and filters, the failed states, backups and the dashboard.
Outcome
Blockradar was implemented and went live using this V1. In 2026, Blockradar reported that it has processed $1.3B across 1.1M transactions, with 189.3K wallets created.

The people using it are operations and finance teams, not blockchain engineers. Every flow carried real cryptographic weight: environments, generated addresses, key material, exports you cannot undo. All of it had to read like an ordinary dashboard to somebody who has never held a wallet, and the product could not hide the complexity, because the people paying for it needed to see exactly what was happening.

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 figured it out from scratch.

We designed the experience for environments, wallet creation, transaction data, security settings and backups.

$1.3B
total transaction volume
189.3K
wallets created
1.1M
total transactions

Starting with onboarding

We took the product one piece at a time. The co-founders would walk us through how a piece should behave and share a few visual references, and after some reading on the market we’d come back with our questions. Onboarding was the obvious place to start. It’s the first flow an operator touches, and nothing else in the product is reachable until they’re through it.

The main call was where to put the security step.

  1. 01Create an account
  2. 02Verify the email
  3. 03Business details and a password
  4. 04Set up 2FA
  5. 05You’re in
Recovery mattered as much as the happy path. If an operator loses their authenticator, the forgot-2FA link is right on the verification screen, so they can get back in on their own.
Create a new account: email address and nothing else.
2FA setup: QR code, the secret key in copyable form, then the six-digit check.

As we worked through onboarding, it led us into the product itself.

Starting with the wallet

We designed the master wallet setup as a multi-step form first, because that’s what setup flows usually are. Testing it against a single screen showed the habit was wrong here: the network decides the assets, and the steps hid that dependency from the operator.

We brainstormed a single screen. The wallet name stayed a text field, since nothing depends on it. Network and assets became dropdowns side by side: when an operator picked a network, the asset list narrowed right there, and they saw the effect of the choice without stepping back. Review became a summary page before Create, where the whole wallet got checked once, at the end.

The lesson I kept: check whether choices depend on each other before deciding how many screens they get.

First pass: five screens
  1. 01Name the wallet
  2. 02Pick a network
  3. 03Pick the assets
  4. 04Review
  5. 05Created
What shipped: one screen
  1. 01Wallet name · Network ▾ · Assets ▾Each old step is a field on one screen; the asset list follows the network. Then a summary page, then Create.
One screen for a new master wallet: network and assets as dropdowns side by side.

Blockradar has a Test mode and a Live mode. The switch started out in the header, like most dashboards. In review we saw an operator could create a wallet without noticing which mode they were in, which matters because Live wallets hold real money. So we moved the choice into the wallet form, where it couldn’t be missed, and added a confirmation step when switching modes.

What sits inside a wallet

Each wallet has many addresses, and each address has a lot of data. Our first table showed all of it, and it was unreadable. So we kept the three things an operator checks most in the row, balance, type and status, and put everything else one click away.

Child addresses under one master wallet. Balance, type and status up front, everything else on request.
  1. In the rowBalance · Type · StatusWhat an operator checks most, readable at a glance.
  2. On requestActivity · Asset details · Creation details · Chain dataOpens from the row, so nothing is lost.
Filtering that table down: activity, type, asset, when it was created.

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, and our first table showed most of it. In review it read like a spreadsheet: an operator checking whether a payment went through had to scan past hashes and webhook details to find the status. So the main view kept the seven things an operator looks for first:

  • Type
  • Date
  • Sender
  • Recipient
  • Amount
  • Asset
  • Status
The transactions view: volume and counts at the top, then every record with type, timestamp, sender, receiver and status.

We designed the transaction detail view around the events in its lifecycle, because that is how an operator checks one: what happened, in what order, and where it stopped. For example:

  1. 01Deposit confirmed
  2. 02Asset swept
  3. 03Deposit webhook sent
  4. 04Sweep webhook sent
A single deposit opened up, with the activity log running the full lifecycle on the right.

If a sweep failed, the failure reason appeared in the activity log at that step, with the retry beside it, so nobody had to leave the record to fix it.

Advanced transaction filters

The table worked well for browsing, but a business with thousands of records isn’t browsing. An operator investigating a transaction arrives with a reference, a hash or a recipient in hand. Our first filter was a single search box, and it kept returning too much. So we designed the filters around the information someone realistically has when investigating:

  • Reference
  • Hash
  • Recipient
  • Type
  • Status
  • Asset
  • Date
Advanced filter. The chart narrows with the table, and applied filters stay visible as removable chips.

Filters could be combined, and the applied ones stayed visible as chips, so it was always clear why the table had been narrowed and what to remove to widen it again.

The filter controls themselves: amount bands, transaction type, preset and custom date ranges.

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 went back through them for the ways they break, the edge cases the requirements didn’t mention.

01Losing access to 2FA

If someone lost their authenticator, they couldn’t simply turn 2FA off; the wallet sits behind it. Our first answer was “contact support”. That would have left an operator locked out of real funds until someone replied, so we designed a recovery path that proves it’s them another way:

  1. 01Password
  2. 02Email OTP
  3. 03New authenticator
  4. 04Confirmation
The verification gate, with the recovery link for someone without their authenticator under the Verify button.

The “forgot 2FA” route sat on the verification step itself, because that is where people are when they get stuck.

02Backing up a wallet

Backup was another flow where the edge cases mattered. A backup downloads the wallet’s keys, so the flow had to make clear how sensitive that is while still getting the operator through it. Our first version put one warning at the top of a single form, and in review people scrolled straight past it. So we broke it into five steps, with the warning before the action, so the acknowledgement couldn’t be skipped.

Before the phrase is shown, three toggles the operator switches on to confirm what it protects.
03Failed sweeps

A deposit could come in successfully and the sweep could still fail. Showing a failed status wasn’t enough on its own; in review the first question was always “why?”. So we surfaced the reason and put the retry action next to it, so an operator could fix it from the same screen.

The reason is stated in the log, with the retry next to the status.

The questions the requirements didn’t cover

A lot of the work happened in questions the requirements didn’t cover, and where each one landed.

  • How should a wallet address be displayed without taking up half the screen?
  • Shortened to its first and last characters, with the full address one click away.
  • When should we show the full transaction hash?
  • Only in the detail view. The table carries the reference.
  • What information should appear before someone opens transaction details?
  • Type, date, sender, recipient, amount, asset and status. Everything else waits inside.
  • How should a user know which environment they’re currently in?
  • The mode is stated in the header and inside the wallet form, and switching asks for confirmation.
  • What happens when there are no wallets yet?
  • An empty state that explains what a master wallet is and starts the create flow.
  • What should happen when a transaction is pending, fails, or needs another action?
  • The status says why, and the next action sits beside it.
  • Where should a user go when they’ve lost their authenticator?
  • Nowhere new. The recovery link is on the verification screen they’re already on.
  • … and 20 more like these

None of these had an obvious answer in the requirements. Faye (designer 2) 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, and handed over a production-ready Figma file: scalable patterns, a responsive version, handoff notes.

The dashboard everything reported into: balances across wallets, address and transaction counts, deposits over the year, and the latest activity.

The dashboard came last, on purpose: it brought the main pieces together once we knew what they were. Wallet balances, address and transaction counts, deposits over the year, recent activity, and usage against plan limits, which is the one an operator checks before the month ends.

Usage against plan limits: addresses generated and monthly transaction volume.

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.

Looking back

The requirements described the happy path. Most of what shaped V1 came from the cases they left out: a lost authenticator, a sweep that fails after the deposit lands, a Test wallet mistaken for a Live one. We found those by designing the main flows first and going back.

If I did it again, I’d map the failure cases with the co-founders in the first week, before the happy path. They took the most rework, and they’re the flows an operator remembers.

What I’d measure now: how long a new business takes from sign-up to its first wallet, and how many failed sweeps get resolved from the activity log without a support ticket.

Design: Faye and me. Product direction: the Blockradar co-founder. Freelance engagement, 2024.

Send me an email at tassyomah@gmail.com and I’ll walk you through it properly.

Aether Energy

02/06

Designing the solar CRM and AI design tool behind Aether’s growth to $1M ARR

The problem

Solar companies were running leads, deals, site information and follow-ups across separate tools and spreadsheets, and every handoff between sales, design and installation lost something along the way.

My role

First employee and first design hire. Solo for around six months, then with Godson. Product design across the platform, from early workflows and information architecture to the interfaces, plus the marketing site in Framer.

  • Scope set directly with the founders
  • Five parts of the product designed and shipped in one year
What we built
  • One deal record that sales, design and proposals all read from
  • A site model built from the real building before a single panel is placed
  • Contracts that fill their numbers from the deal and the design
  • AI designed into the product: a note editor that drafts on request, a quick AI design from an address
$500K
ARR deal with SalesRabbit
~$1M
ARR within the year
$2.5M
seed round

What Aether needed

Business goal

Aether needed to turn a new solar workflow into a product customers could actually use and buy from, moving quickly from early ideas to a working platform that could support sales, design, proposals and the operational work around them.

Constraint

Speed. We were designing while the product was actively being built and sold. Features had to move from requirements to design to engineering quickly, often while the requirements were still changing. That meant making good decisions without waiting for everything to be perfectly defined.

Features were shaped, designed, tested and shipped as we learned from customers and sales conversations.

Working it through with the team

One recurring tension was how much control to give users versus how much structure to impose. We had to make calls on what should be configurable, what should be standardised, and what information belonged at each stage of the workflow. Those decisions were worked through with the founders, product and engineering.

Here’s what we worked on

Solar CRM

The deal before the proposal

Figuring out the sales workflow

When I joined Aether, the CRM was still being figured out. We had requirements and a sense of what sales teams needed, but we still had to work out how all of that information should fit together.

I started by mapping the sales process from a new lead through to a signed deal. That map became the basis for the CRM’s information architecture: what a rep would need at each stage, what information had to follow the deal, and where the CRM would connect to the rest of the product.

  1. 01Lead
  2. 02Qualified
  3. 03Agreements
  4. 04Financed
  5. …Done
The deal stages on the Deal Hub board, from lead to done.
The CRM home: 2,505 projects and $32.6M in sales, created projects by month, installs plotted by state, top creators, the pipeline from lead to done, and an 88.34% win ratio.

What should the pipeline show?

What does a sales rep need to know about a deal without opening it?

A deal could carry a lot of information, but the pipeline couldn’t show all of it. We sorted every piece of it by when a rep would need it.

On the card
  • Customer
  • Address
  • Deal value
  • Status
  • Last updated
  • Comments
Inside the deal
  • Overview
  • Notes
  • Files
  • Activity
  • Comments
  • Building
In a report
  • Projects
  • Total sales value
  • Installs by state
  • Win ratio

Decision Every piece of information sorted by when a rep needed it: on the card, inside the deal, or in a report. The first pass had all of it on the pipeline and read like a spreadsheet.

One set of deals, different ways of working

Once the basic pipeline was in place, we had another question: should everyone have to work with it in the same way?

Board

For moving deals through stages.

Table

For teams that needed to compare more information across deals.

Pricing

For working through the financial details of a deal.

Options considered

Option 1One board, with everything a rep might need on each card.Rejected: the cards got tall and the board stopped being scannable.
DecisionThree views over the same deals: the board for stage, the table for detail, pricing for value.

Trade-off: three views to keep consistent whenever a deal field changes.

ScreensDeal Hub, three ways1/3
The same deals as a board, each column totalling its own value. Deals as a table, with columns the team defines and views they can save. Pricing: system cost, storage, adders, discounts and rebates, every line switchable and carrying its own margin.

The table also became configurable. Reps could choose the columns they needed, rename them and save views they wanted to return to.

Decision Filters on owner, status, rep, location and date could be saved and reopened, because a sales lead was rebuilding the same view every morning.

Trade-off Saved views were one more thing to manage, in exchange for no daily setup.

Then we had to figure out the deal itself

Opening a deal brought in everything that couldn’t reasonably sit on the pipeline:

  • Customer
  • Property
  • Pricing
  • Proposals
  • Documents
  • Notes
  • Tasks
  • Activity

We worked through what belonged in the initial overview and what deserved its own section. Notes and tasks stayed inside the deal because they were things a rep needed to work on without losing the context of the project.

ScreensThe deal record1/7
The deal in one view: the customer and stage, the system numbers (contract price, price per watt, payback period, 25-year savings), the property itself, the open tasks, and the proposals against it. One deal, opened. The homeowner and the property on the left, general information and the utility and consumption chart in the middle, and an AI deal scope on the right that summarises the install, flags the priority and lists the tasks with their due dates. Notes live on the deals themselves: tagged to the project they belong to, with who wrote them and when. Files on the deal, with the whole workspace along the top: overview, activity, pricing, utility, files, notes, tasks, permit history, agreement. Four selected, with the proposals for this project alongside. Every touch on the deal in one feed: a task assigned, a file uploaded, a simulation run, a proposal viewed and shared, an access request answered without leaving the page. The files tab with the comment rail open beside the deal. Site plans, aerial screenshots and building wireframes on the deal, with the actions rail alongside: the proposals drafted so far, and the way through to Design Studio.

Options considered

Option 1One long deal page, everything stacked.Rejected: a rep looking for the last call note was scrolling past site details and files to find it.
DecisionA tabbed record, with the pipeline position kept in view.

We also explored AI inside notes. A rep could describe what they wanted in plain language, get a draft, review it and decide whether to keep it.

Decision On request, never automatic. The note was the record of a real conversation and the rep had to stand behind it.

Click throughWriting a note, with help1/8
An empty note that tells you what it can do: type / for blocks, or ctrl-space for AI. A title, with nothing else filled in. The / menu: text, headings, bulleted list, table. Select any text and the toolbar appears over it, with AI as one of its options. Asked in plain words: project overview, site assessment, installation plan, equipment, timelines, next steps. The draft is written into the note itself. Key objectives, project milestones with real dates, and key contacts: the sales rep, the solar designer, the lead installer. Accepted, and the draft becomes the note.

A task created from a deal stayed connected to it and also appeared in the wider task list.

Designing the handoff

The same deal could move into solar design, proposals and documents, so information captured early needed to remain useful further down the line.

The problem. The design team was retyping the site address and roof details into the design tool, and the proposal team was pricing from a second copy.

Deal the customer the site, the stage Proposal priced from that record Solar design same site, same numbers Installation scheduled from what was sold

Decision Site details lived on the deal record. The proposal and the solar design read from it.

Trade-off Sales entered a little more up front, once.

We designed those connections as part of the CRM from the start. That gave Aether a shared deal record that the rest of the product could build on.

Result A number entered once was the number everywhere downstream.

Where it landed

In one year, the CRM, the solar design tool, the proposals and the website were designed, shipped and in use by solar companies; the document manager was the last piece in progress when I left. 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.

What I took from it: when the same site, the same numbers and the same customer run through five tools, the design job is mostly deciding where a piece of information is entered once and read everywhere else.

Send me an email at tassyomah@gmail.com and I’ll walk you through it properly.

Internal Healthcare System

03/06

Designing one senior-care system for families, providers, caregivers and admins

The product

Internal Healthcare matches families with vetted senior-care providers.

My role

I worked with the Internal Healthcare team alongside two other designers from my agency, Homalabs, to design a multi-sided senior care platform. I coordinated and led the design team on this one, setting the direction across all five products while we split the work between us.

What we built
  • Website, 15+ pages
  • Family portal
  • Provider portal
  • Caregiver app
  • Admin
245+
care professionals onboarded
1,000+
screens designed
5
connected products

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. It took several months of meetings, refining and building. For part of it the process was agile: we were designing alongside the engineers.

The system is now fully functional, with families actively using the platform.

  1. 01Family posts
  2. 02Admin approves
  3. 03Provider is referred
  4. 04Caregiver works the shift
  5. 05Family reads the log

The product

Website where families and care professionals first arrive Family portal families looking for care registering a loved one following the care Provider portal agencies managing referrals and clients caregivers, care plans Caregiver app caregivers managing their work and visits client information Admin the internal team managing providers, families and requests

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.

  1. 01Requirements
  2. 02Content and wireframes
  3. 03Moodboard and directions
  4. 04Client reviews
  5. 05Detailed UI and handoff

Decision 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.

Decision 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
About Home care Assisted living Senior day care For caregivers Directory

Home Care

Click throughHome Care1/7
In-home care, and who it is for. The kinds of support available at home, broken into sections. How a family starts, and what happens after they ask. The people and agencies behind the service. What the service commits to. Reading for a family still deciding. The care request at the end of the page.

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
Finding the right assisted living community, with the kinds of care laid out underneath. Tailored living options for seniors at every stage of life. Personalised and assisted support for daily living, and what a partner facility offers. Experience compassionate independence with the right help. What to weigh when choosing a community. The information centre and helpful guides. The care request at the end of the page.

Decision The content was different from Home Care, so we gave the page its own structure.

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
What the place offers, its photographs, and the request form running alongside from the top. Ratings and written reviews, then the questions families ask before they commit. Similar agencies close by. The care request repeated at the end, with the newsletter and the rest of the site underneath.

The rest of the site

Senior Day Care, the top of the page: daytime care for active seniors.
Senior Day Care: the services offered and the three-step approach.
Senior Day Care: the guides, and the care request at the foot of the page.
About: who Internal Healthcare is, and the numbers behind the service.
About: the mission, what they offer, and the press coverage.
For caregivers: joining the network, and building a career on your own terms.
For caregivers: the opportunities, and what the app does day to day.
For caregivers: the earnings, the questions and the sign-up.

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.

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.

Send me an email at tassyomah@gmail.com and I’ll walk you through it properly.

Uiland

04/06

Building the UI reference library African designers didn’t have

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 Uiland homepage as designed: the hero and search, 400+ apps and 100,000+ screens, the Components, Flows and Web + Mobile entry points, the brands covered, and the filter rail above the grid.
The home grid: app screens, logos, colours and websites in one scroll.

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 other references designers could use in their work:

  • Websites
  • App store screenshots
  • OG images
  • Interactions

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.

Apps selected: every product in the index, two columns, each with what it is.
The same query narrowed with Apps selected in the rail.
Browsing every app in the index, by category and screen type.
Browsing by screen type: every guided-tour screen in the index, in one view.
Analytics GA · Hotjar Feedback users · the team Decide what needs attention Ship IA · search · SEO watch the same measures again
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

One screen opened up. The screen on the left with 1 of 456 and its similar screens underneath; on the right everything it is tagged with (category, screen types, the palette it uses, the flows it belongs to, and every UI element on it), then Edit in Figma.
The screen detail on a phone: Explore Similar over the screen, the engagement rail beside it, and the tagging written out as a sentence.
Explore Similar
And as a sheet: the product, the 1-of-456 counter, likes, saves, downloads and copies, Edit in Figma, then Explore Similar Screens underneath.
The detail sheet
The logo library, grouped by category.
A ready-made app store screenshot set, panel by panel.
One product’s whole profile: Pinterest with 233 screens, 24 flows, 244 followers, and every flow it ships listed by name (Add item, Checkout, Sign up, Upgrade plan, Invite a friend, Search, Reset password, Share, Import data), each one a strip you can step through, with Download all and Copy link on any of them.
One product opened up: every page of its website, captured and tagged.

Where it is now

1,000+
web and mobile apps documented
100K+
visits
$20K+
in revenue
2023
founded

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.

Send me an email at tassyomah@gmail.com and I’ll walk you through it properly.

Reown Africa

05/06

Designing repair-shop software that turns every job into a vehicle’s history

Reown was built for the Nigerian market, and it addressed two problems at once: operations and communication. Every job logged that way also became data, which is what the vehicle history is built from.

I worked with the Reown team as lead product designer for about a year. Some of the work involved improving existing experiences, while other parts were designed from the ground up. 37 garages ran it in beta, some of them paying to use it. The work took the company from nothing to a product it could raise on.

On the shop side, a mechanic could log vehicle data, send invoices, schedule appointments and send service reminders. On the owner’s side, it showed where a repair stood, opened a line to the mechanic, and let them rate the service afterwards.

I worked closely with the founder, Ayodeji, the product manager and engineering team throughout, moving between product decisions, design and implementation as features were being shipped.

Technician logs the repair → It becomes the car’s history → The owner reads it → A reminder brings them back

Reown currently reports having customers using the product, while transitioning into EVs to further expand the business.

Below is a breakdown of the different parts of Reown I worked on.

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.

DataraFlow

06/06

Designing the portals that run a six-month data science accelerator

DataraFlow is Africa’s accountability-driven data science accelerator: six months, weekly check-ins, weekly submissions, mentor-reviewed projects, and a public record employers can verify. Running that for hundreds of interns at a time means tracking every check-in, submission, review and certificate across cohorts, in one place.

Through Homalabs, I’m leading product design on its internal tools: portals for mentees, mentors and administrators, plus community management features, working with the DataraFlow team and the Homalabs team. The portals are in use by thousands of interns.

Still putting this one together

DataraFlow is live and the portals are in use. I’m still writing this one up, but I’d be glad to walk you through it.