I Used to Design Every Screen Myself

The designer, by default

At my first company there was no designer to hand a screen to, so the screens were mine. The signup form, the payment flow, the dashboard our resellers ran their businesses from, the mobile apps. Some of my interfaces had no screen at all. A phone menu is user experience with no pixels, and people get lost in one just as easily.

My usability lab was the support line, because I answered it. A customer couldn’t find the button I was sure was obvious. Another gave up halfway through a form and called instead. I wrote about building everything myself in the previous post, and design was the part of that job I was least prepared for. I learned it the way I learned networking: by getting it wrong in front of a paying customer and fixing it that night.

The user in my head was me

The biggest design mistakes I made were assumptions I didn’t know I was making. Many of our customers were immigrants, many were underbanked, and a lot of them dealt with money, identity and technology differently from the people who usually design software. A form that assumed a credit card, a stable address, a name that fits in two fields, fluent English and a fast connection on a recent device turned real customers away, and nobody noticed, because the customers who were turned away never showed up in the data.

The reseller channel made it harder. Businesses sold our service in their own communities and ran on our hosted platform, so they needed tools to run a business, and their customers needed the service to keep working for people who trusted the reseller, not us. I wrote more about building for people the system wasn’t designed for in the founder story. The lesson I took from it predates software for me. At my family’s florist and restaurant, the shop had to fit how customers actually bought things, and a screen is no different.

Readers, residents and drivers

Later roles changed who the person on the other side was. As CTO of a media publishing platform, I finally had designers on the team, and the people using the product were readers arriving from search and social on their phones. Speed was part of the experience. We shipped progressive web apps and AMP pages because a slow article is an unread article, and the design conversation was as much about load time as layout.

Government work turned the dial again. On a public-service modernization, residents didn’t choose the service and couldn’t go elsewhere, so accessibility stopped being a nice-to-have. WCAG checks and security review were release gates, in the pipeline, not a review at the end.

The small projects taught the same thing in miniature. On the Union City Smog Check site, a driver is on a phone, close to a deadline, picking whichever nearby station they trust fastest, so calling and directions are the first two actions on every screen. The Berkeley Omnium site was built for someone checking race details on the way to the start. In each case the design question was the same one the support line used to ask me: what is this person trying to do, and how fast can we let them do it?

How I design now

Today I design with an AI assistant in the loop. I describe who the page is for and the job it has to do, and it comes back with a direction and a working layout in the site’s own type, colors and spacing. I open it on a phone, say what’s wrong, and we go again. It checks contrast and keyboard order, reflows a wide figure for a narrow screen, and drafts the error state and the empty state that I would once have forgotten until a customer found them.

The at-a-glance figure on my About page was built this way. I said it had to explain who I am to a hiring manager in five seconds without reading, the assistant proposed a chart instead of a grid of cards, and we spent most of the time on where it should transpose for phones. That’s a conversation I used to have with myself at midnight, with a worse outcome.

Left alone, an assistant reaches for the defaults every model reaches for: a hero, three cards with icons, a gradient, rounded everything. It looks like every other site built last month. So the first thing I do is say no to that, and the second is to hand it the constraints a designer would want, which is the audience, the device, the one action that matters, and the design system it has to live inside. Given those, it’s fast, patient and better at consistency than I am. Without them, it’s a template generator.

What hasn’t changed

Pixels were never the hardest part. Knowing what the person is trying to do, on which device, with how much patience, was the hard part when I drew the screens myself, and it’s still the hard part when an assistant draws them. AI makes the drawing cheap and leaves the knowing to me.

It doesn’t know your user. It has read a great deal about users in general, and nothing about the reseller who runs a business from your dashboard, or the resident filling in a form they didn’t ask for. Everything it knows about them comes from what I tell it, so the work moves from drawing to explaining.

Experience still shows up as noticing. I see the form that breaks at a narrow width, the name field that won’t fit a real name, the contrast that fails for someone my age, and the empty state nobody designed, before they ship. The assistant will happily produce all of those if I let it. Reviewing its screens is the same job as reviewing its code: the mistakes look plausible, and the reason I catch them is that I’ve shipped the real version and taken the call.

A good-looking product is still not a business. The smog check site exists to produce a phone call, FedPath exists to produce a bid or no-bid decision, and a publishing platform exists to be found and read. If a screen is beautiful and the action doesn’t happen, the screen failed.

And learning is still the job. I learned accessibility properly because government work required it, and I learned design tokens because consistency across a dozen pages is hard to keep in your head. The assistant is another thing to learn to work with, and so far the most useful lesson is to give it the brief I wish someone had given me.

Why I still design screens

I lead engineering teams now and I could leave the screens to other people. I still like being the person who notices the button nobody can find. Designing with an assistant means I spend less time pushing boxes around and more time on the question that mattered from the start: who is this for, and what happens when they try to use it?

That question doesn’t get easier with better tools. It gets easier with every customer you have watched get stuck, and I’ve watched a lot of them.

Short answers