Approach
Good work starts by understanding what actually needs to change. Seven things I hold to, whether I’m leading a team or building the thing myself.
Understand the real problem
Design shouldn’t begin with a blank canvas.
Before touching an interface I want the business, the people using it, and the system around it. Existing strategy, research, analytics, brand, technical constraints, previous attempts. If those exist they become inputs. If they don’t, we establish as much of that foundation as the project allows.
The amount of research changes from project to project. The need for understanding doesn’t.
Make strategy visible
Strategy becomes useful when people can see it.
A direction nobody can picture is a direction nobody can argue with, and a direction nobody argues with never gets sharp. I put the thinking on a wall (ecosystem maps, journeys, audience models, annotated inventories) and interrogate it with the people who know the system best, including the client’s own designers, developers and domain experts.
That is also how alignment actually happens. Stakeholders commit to what they helped build, not to what arrives finished.
Design the system, not the screen
Solve for the ecosystem around the thing.
Most of the hard problems I get handed are structural. A company’s internal architecture has quietly become its customer’s navigation; a platform has grown faster than any structure holding it; a task has spread itself across fourteen open windows.
Fixing the screen in front of you leaves that intact. I’d rather change the model underneath and let the screens follow, then build the system that keeps it coherent after I leave.
Prototype early
Make it real enough to learn from.
A prototype doesn’t have to be linked design screens. Depending on what we’re trying to learn it can be a working front-end experience: something stakeholders use rather than imagine, customers interact with, and developers can read for intended behaviour.
That changes the conversation. Decisions get made around something real, while changing direction is still inexpensive.
Lead through the work
Creative leadership isn’t just reviewing what other people make.
I stay close enough to the craft to create clarity, raise the bar and unblock people, sketching alongside the team, taking the difficult screen myself when that is what the deadline needs.
The rest of leading is less visible and just as decisive: who is on the project, whether the scope and the staffing agree, where the quality bar sits, how work moves from design into development without losing its intent, and who is being brought along. Get that machinery right and the creative work has room to be good.
Use technology intentionally
New is not a reason.
AI, RFID, connected environments and emerging technology matter when they improve the experience or change what is possible. The technology should disappear into the experience. A child shouldn’t need to understand identity systems to feel that a park knows who they are.
I build with these tools as well as design for them, which keeps my judgement about what they can actually do honest.
Ship, learn, improve
Launch is part of the design process, not the finish line.
Once something is real we learn things we couldn’t have learned while designing it. People use it, technology pushes back, priorities move, new opportunities appear. So we go around again.
The goal isn’t to execute a process perfectly. It’s to understand what the product needs next and have the range to meet it there.
In practice
Understand where we are. Solve what’s in front of us. Build on what we learn.
See what I can lead and make, the work itself, or get in touch.