Yves Kwameh

The problem

The Car Guys had just bought the domain. There was no site, no pages, and nothing anyone could fill in.

The business does three different things, and they are not variations of each other. Someone can buy or lease a new car, sell the car they already have, or hand back a lease early, and all of it happens without a dealership visit. Each one needs different information from a different kind of person, and each one ends in an application that a human being has to read. So the site could not be a brochure with a contact form at the bottom. It had to carry three separate services and be ready to take real applications the day it went up.

The waitlist, first

A domain with nothing on it is a month of people arriving and leaving. Rather than wait for the real site, I built them a coming soon page and put it up straight away.

It asks five things: first name, last name, email, phone, and a message. The message box matters more than it looks. Someone who is mid-lease and wants out will say so there, and that is a warmer lead than a name on a list. Three chips above it name what the business actually does, lease buyouts, auto brokering, no dealer markup, so a visitor knows whether they are in the right place before they type anything.

Drawn at 1920, 1440 and 425, so it was responsive before the site it was standing in for.

Drawn before it was built

Every page was wireframed in Figma first, in grey, with no photography and no brand colour. That is deliberate. A dark hero with a car in it will sell almost any layout to almost anyone, and the point of this stage was to argue about the order of the sections and the length of the forms while those were still cheap to change.

Eleven layouts came out of it, seven for desktop and four for phones. The application was drawn at this stage too, which is how the length of it became a design question rather than something discovered at the end.

The site

Built in Webflow off those wireframes. Four page types: the home page, and one for each service.

Every service page is the same shape. A headline that says what you can do, one button, then How It Works as three steps, then the form. Someone who lands on Sell Your Car from a search reads the same structure as someone who came through the home page, so the site only has to be learned once.

The FAQ answers were written from the service copy rather than invented, so the page answers its own questions instead of contradicting itself further down.

It holds at every width

Responsive the whole way down, not just below one breakpoint.

The navigation collapses to a menu at tablet width. On a phone the three step rows stack, and the two column form fields become one column rather than shrinking to something nobody can tap.

The application

This is where most of the work went.

The form we were working from, an existing application from another company in the same business, ran to 43 fields across three tabs. Eleven about the business, fifteen about the personal guarantor, and seventeen more about that guarantor’s employment, ending in a signature. Everyone answered all of it. A sole trader with no guarantor still filled in three tabs of guarantor questions, and a first tab that asks for a Tax ID is a strange thing to show someone who just wants to lease a car.

So it became two applications, not one. A person gets asked what a person can answer. A business gets asked about the business. Both sit on a single page instead of three tabs, because three tabs hide how much is left and a page does not.

The co-signer moved behind a toggle. Off by default, twenty one fields that only exist for the people who have one. That single decision is most of the difference between 43 and 22.

Result

A business now fills 22 fields instead of 43, and a person fills 29 without ever seeing a question about a guarantor they do not have. The site is live and covers all three, and the waitlist was up taking messages the whole time it was being built.

The problem

Accounting firms all say the same four things, and a musician trying to work out whether one of them understands touring income cannot tell them apart. BOH works with creators, entertainers and the agencies around them, which is a real difference, and the old way of saying it was a services list that could have belonged to anybody.

There is a second problem underneath that one. Three audiences, an artist, a manager, and an ordinary small business, want different things and are reassured by different proof. A single page written for all three ends up written for none.

Say who, then what

The home page leads with who it is for. Three audiences as three doors, entertainers and talent, agencies and managers, and small businesses, because someone arriving already knows which one they are and wants their door marked rather than a paragraph to sort through.

A page each

Multi-page rather than one long scroll, so each door opens onto a page that speaks only to that audience. The talent page can talk about royalties and touring without a small business owner reading past it, and the reverse.

Eight services, folded

The service list is long: bookkeeping, contract and royalty administration, tax compliance, payroll, cash flow, insurance, entity structuring, advisory. Eight items, each needing a paragraph, is a page nobody finishes.

So it folds. Closed, it reads as a short list of what they do, which is the question most people are actually asking.

Open, one at a time, it gives the detail to the person who wants that one thing. Royalty administration matters enormously to a musician and not at all to a restaurant, and neither of them should have to scroll past the other’s answer.

Proof, then price

Testimonials sit below the services rather than at the top, because a quote means more after someone knows what is being sold. They are attributed to real roles, a content creator, a musician, so a visitor can find the one closest to themselves.

Then the prices, in the open, as three tiers rather than a form to fill in to find out. An accounting firm that publishes its numbers is making a claim about how it works, and hiding them would have undercut everything above.

Result

What was delivered names its audience before it names its services, gives each one a page of its own, and puts the prices where a visitor can read them. It read as specialist rather than general, which is the whole difference for a firm whose clients are not ordinary small businesses.

The problem

Scroll House Studio sells cinematic property films, drone footage and AI visuals. That is a product nobody can judge from a description. An agent deciding whether to spend money on a film for a listing wants to see a film, and every second spent reading about the films is a second the work is not playing.

They also do not need a big site. One studio, one service, one kind of buyer. A services page, an about page and a portfolio page would have been three places saying overlapping things, and three chances to land on the wrong one.

One page, in the order someone decides in

Everything lives on a single page, ordered the way the decision actually goes: see the work, understand what you get, ask for it. The hero is footage rather than a headline over a stock photograph, so the first thing anyone judges is the thing they would be buying.

The explanation comes second, once there is something to explain. It is short, and it names the parts of the offer, cinematography, drone footage, editing, AI artistry and mixed soundtracks, because those are what a buyer compares against another studio’s quote.

The work carries it

The portfolio is the largest section on the page, deliberately. Vertical tiles, because that is the shape these films are shot in and the shape they are watched in, and a grid rather than a carousel, so the range is visible at a glance instead of one at a time.

A tile opens in place. Nobody is sent to another site or another tab, because a visitor who leaves to watch something on a video host has left, and the enquiry was on this page.

What they actually do

Under the work, the capability section splits into capture and create: what happens on site and what happens after. Two groups rather than a list of twelve services, because the useful distinction to a buyer is whether someone has to come out to the property.

On a phone

Most of this is looked at on a phone, often by someone standing in a property. The vertical tiles are already the right shape for it, so the grid becomes one column and nothing has to be re-cropped.

Result

A one page site that shows the films first and turns a scroll into an enquiry, built in Webflow so the studio can swap the reel as the work changes without coming back to me.

The problem

A design portfolio that describes how someone thinks about interfaces, in paragraphs, is asking to be taken on trust. I would rather the site be the argument.

The risk in that idea is obvious. An interface built to be admired is usually slow, and a portfolio that takes four seconds to show anything has argued the opposite of what it meant to. So the whole thing is built to one rule: nothing loads that the visitor did not ask for, and the page arrives under 10KB of JavaScript.

The lock screen

It opens on a lock screen instead of a home page, and it asks one thing: whether you want sound. Nothing plays until you answer, and the answer is remembered for the rest of the visit. The voice clip is not even fetched unless you say yes.

The unlock button runs away from the cursor. That is a joke, and jokes have to have an exit, so Enter works for anyone who would rather not play.

The desktop

Icons you can drag and rename, a dock, right click menus. The icons remember where you put them and what you called them until you clean up, which resets both.

Nine photographs from Port Harcourt live inside the Images icon in the dock. They fly out when it is pressed, scatter, and can be picked up and dropped back into it.

The windows

Every window is real HTML at build time, hidden with a class rather than fetched. Opening one costs no request. What is fetched on first open is that app’s behaviour, and only that app’s, which is what keeps the desktop itself down to the desktop.

Work is laid out like System Settings, a rail of case studies beside one case study.

About is a bio beside a reel of photographs that loops without a seam.

Services is a set of grouped disclosures, so six offers read as a short list until one is opened.

Feedback scrolls client quotes past, and the game is a game of tic tac toe you are not meant to win.

On a phone

The same desktop rebuilt for touch rather than shrunk. The icons become a grid.

A window stops being a window and becomes a bottom sheet: it rises from the bottom edge over a scrim, covers the dock instead of sitting above it, and swipes down to dismiss. Dragging and resizing are off below 640, because there is nowhere on a phone to drag a window to.

Result

It is the argument rather than a description of one. Someone can drag the icons, open the windows, lose at the game, and judge the work by using it instead of reading about it.

The rule held. The page arrives with 10,135 bytes of JavaScript, which is measured on every build rather than estimated, and each app’s code is fetched the first time its window opens and not before.

The problem

Altabrio was weeks from launching a training product, which is the worst moment to discover that the navigation does not hold. Everything was built. What it needed was not more features, it was to be legible to somebody opening it for the first time.

A training product also has a particular problem: it generates a great deal of data and almost none of it is interesting on its own. A number is only useful next to the thing it is supposed to be, and a screen that shows forty numbers with equal weight is a screen nobody reads twice.

The way in

The first thing anyone meets is the sign in, so it does the introducing. What the product is sits beside the form rather than on a page before it, so nobody has to read a pitch to reach their account, and somebody arriving from an ad still learns what they signed up for.

Setting up is part of the product

An adaptive training plan is worthless without the athlete’s own numbers in it, so the setup asks for them. It is a sequence of short steps with a progress bar rather than one long form, because someone who has just signed up has not yet decided this is worth twenty minutes.

The dashboard answers one question

The layout puts the few numbers that answer “how am I doing” in front, grouped rather than spread, and keeps everything else one move away instead of on the same screen competing. The greeting and the date are there because a training app is opened daily and the useful frame is today, not all time.

The same system, four ways

The rest of the product is calendar, races and plans, and all three are the same components rearranged rather than three designs. A calendar of sessions, a table of races, a table of plans: one sidebar, one header, one set of table styles, one way a row behaves.

That is what made the deadline survivable. Once the system was settled, a new screen was an arrangement rather than a design, and the remaining weeks went on the screens that still needed thinking about.

Result

Navigation streamlined, the visual identity rebuilt, and a product that could go out on time and be understood by the people who signed up first.

The problem

A logistics app has two people in it who want opposite things. A sender wants a price, a pickup and to know where their parcel is. A rider wants work, a route, and to get paid for it. Both of them were going into one product.

Built naively that becomes an app full of screens that half the users should never see, and a navigation that has to apologise for itself on every tab.

Pick a side first

The screen straight after the splash asks which one you are, because almost nothing past that point is shared. Deciding it once, at the front, is what keeps the rest of the app from asking again on every screen, and it means neither side ever has to be told a feature is not for them.

Booking, in three short steps

Sending something is the thing a sender came to do, so it is the shortest path in the app. It is split into three screens rather than one long form: what you are sending, the details of it, then the vehicle.

Three short screens beat one long one here for a specific reason. Somebody booking a delivery is usually standing over the parcel with one hand free. A screen that asks four things can be answered standing up. A form that asks twenty cannot.

Each step ends in one button, always in the same place, so the flow can be finished without reading the screen after the first time.

Money is its own place

Payments live in a wallet rather than being attached to each delivery. A sender tops up once and stops thinking about it, and a rider sees what has come in and when. The transaction list is the same component for both, reading credits for one and earnings for the other.

Two dashboards, one system

From the account choice onward it is effectively two products, but they are built from the same parts: the same cards, the same list rows, the same buttons in the same positions. That is the foundation the brief asked for, and it is what makes a third screen cheap rather than a redesign.

Result

An end-to-end experience mapped for both sides, a booking flow short enough to finish standing up, and a visual system underneath it built to be added to rather than redrawn every time a screen is needed.