How we work
The ELLOR method
Five stages, always in this order. It's slower on paper than jumping straight to design, and that's the reason our projects rarely need a second round for what the first one missed.
Explore
Every project starts with listening, not pitching. We talk to your stakeholders, dig through what you already have, and map out what you're really up against, so the brief matches reality instead of a hunch. It's also where we're straight with you on scope. If a full redesign isn't the answer, we say so.
Layout
Before anything gets styled, we lock the structure: sitemaps, user flows, content models, and how everything sits on the wireframe. It's the dullest stage and the one most people rush. We don't, because every design choice that comes later inherits whatever gets decided here.
Layer
With the structure agreed, we add the visual layer: type, color, components, and prototypes you can click through. We test those on real users before calling anything done. Catching a bad flow in a prototype costs a lot less than catching it in production.
Optimize
Here the design turns into real, production-ready build: clean code, sensible performance budgets, and an accessibility pass that's about how the site actually reads and behaves, not just ticking a box. We do this before launch, not in a panic after a slow page has already cost you visitors.
Release
Launch is a milestone, not the finish line. We come back at agreed check-in points after go-live and review progress against what we set out to do before kickoff, not a flattering story assembled afterward.
Why we don't skip steps, even on a tight timeline
Every skipped step comes back as a revision. A layout drawn before the structure is settled gets redrawn once the structure finally happens. A sitemap agreed on gets torn apart the moment someone actually tries to use the product and it doesn't hold up. Running the method in order costs a little more time up front and saves a lot more on the back end. That trade has held on every project we've run it on.
Curious how this maps to your project?
Tell us where things stand today and we'll point out which stage you actually need to start from.
Frequently Asked Questions
The stages scale, they don't disappear. A one-page site still gets an Explore conversation and a Layout pass, just a shorter version. What changes with project size is depth, not order.
Then Explore and Layer look different. We start by understanding what already exists and where it's working, rather than assuming everything needs to be rebuilt from scratch.
We can move fast, but we won't skip Layout. Every project we've rushed past that stage has come back as a more expensive fix later, so even under a tight timeline we keep the order and compress the time spent, not the steps themselves.
No. Release includes agreed check-in points after launch to see how the site is actually performing in the real world, and we're available for ongoing work after that if you want it.
It depends entirely on project scope; a landing page and a full product rebuild don't run on the same clock. We'll walk you through a realistic timeline for your specific project on the strategy call.
That's normal, and it's exactly what the strategy call is for. Tell us where things actually stand and we'll tell you honestly which stage to start from, even if that means picking up mid-method rather than at Explore.