Laolu James

At work, I don’t jump straight into layouts. I start by asking questions. What does success actually look like for users? What does the business need out of this? What’s already been built, and what actually needs to ship right now versus later?

From there, I map things out. User flows, journeys, sometimes quick state diagrams. Mostly just trying to understand where things can break before we even start building. If something feels unclear or risky, I’d rather prototype it early than argue about it in a meeting.

Once things are solid, I move into high-fidelity wireframes and flows. I make sure they account for real scenarios like loading states, empty states, and failures, not just the ideal path. Those designs aren’t just for show, they’re how design, product, and engineering stay aligned.

After that, I layer in visual design and motion. I’m intentional with it. Transitions should help people understand what’s changing, not just look nice.

If it helps us move faster, I’ll prototype directly in the browser. I also try to get things in front of real users whenever possible. The goal isn’t to make more screens, it’s to avoid surprises later.

I document decisions, design tokens, and motion details so things stay consistent as the product grows.

Outside of client work I tend to chase side projects that force new skills — small tools, experimental sites, and occasional hardware-adjacent ideas. I like long walks with a camera, over-preparing for trips, and sending too many links to friends who did not ask for a reading list.

I keep a messy notebook for quotes, UI references, and half-baked diagrams. I cook when I need to think without a screen. I am trying to get better at stopping when the solution is good enough, which is harder than it sounds when you care about the details.