We love crafting beautiful products. When we do it right, it might seem effortless. But a rigorous approach underpins our work. Years of experience back up our instincts and decisions.
Our clients should feel like they’ve hired pragmatic partners. It’s important they understand how we get from start to finish.
This article outlines our complete approach to digital design. But we tailor our scope for every client and situation, picking from the menu that’s described below. Most jobs don't need the works.
We keep the Pareto principle always in the front of our mind. We like getting 80% of the way there in 20% of the time. It’s tempting – and occasionally warranted – to spend more time getting that last 20% perfect. But that is seldom the wise approach.
Our job is to create something from nothing.
A client comes to us with an idea. Just an idea. Sometimes they have a kind of project brief, but its thoroughness can vary greatly. So we embark on a process that puts form to this ephemeral idea, getting progressively more concrete until we have a real, living product.
This is the process we use to develop a site or an app, which for simplicity’s sake we’ll call the “product” from now on. We also often work on identity projects – developing a brand, logo, colors, tone, etc. The process there is related, but different, and will be expounded in a separate article soon.
We want to get every client to a normalized starting point, where we know enough to reliably do a great job.
We meet the client at whatever level of clarity they have. Through conversations (and emails, though we prefer Slack), we load their mind into our's.
We want to understand what’s really going on. What triggered the project? What’s motivating the people involved? What does success look like? What is everyone secretly worried about?
Often we find hidden, very human forces at play. Perhaps the CEO overheard a comment at a dinner party that inspired him and triggered a redesign. Or maybe an article posted by a developer started a bigger conversation. Maybe a revitalizing new product line is due out, and the company’s future is riding on its successful debut. Or perhaps a new leader is trying to make an impression on her team or her boss.
Understanding these factors helps us not only build the right product, it helps us support the client along the way. It ensures we’re all pushing in the same direction. It often gives us a map for the kind of success that a product description alone could never outline.
In short: we’re all people, and we want to understand the people in addition to the product.
The Creative Brief
If a project is complicated enough, our first deliverables aren’t visual, they’re text.
We’ll build a Creative Brief to summarize what we’ve learned and to give everyone involved in the project a shared baseline. Then we can all agree to this shared baseline and progress from it.
In the Creative Brief, it’s important to cover things like:
- Project summary
- Client summary
+ Market position
- Project goals (measurable, ideally)
- Target audience
It’s great to also include:
- Google Analytics insights
- Domain vocabulary
- User interviews
- Industry research
- Strategic recommendations
With this shared foundation, we can start putting shape to the product.
Our first visuals are diagrammatic. We lay out a proposed structure for the product (and, if this is a redesign, compare it to the current structure).
We may also outline flows, interactions with outside systems, and other high-level models.
At this point, we’re putting shape to what was previously just words and ideas. We’re answering questions like:
How many screens are there?
How many templates are there?
What sections are there?
What are the most important goals for the user?
This phase is commonly known as Information Architecture.
With the structure of the product defined, it's time to jump in and develop the structure of its individual screens.
We start with wireframes. They're only as detailed as necessary; sometimes pen sketches suffice. This lets us work fast. It also keeps us focused on building a shared view of the product's organization, structure, and concepts.
They help us answer questions like:
- What is on each page?
- What’s the most prominent part of the home page?
- What is in the navigation?
- Do we have a secondary navigation?
- How complex are our page layouts?
- What copy needs to be written?
- How are we connecting different sections of the product?
- How do pages look on mobile screens compared with desktop screens?
The wireframes fuel all subsequent work: graphic design, copywriting, development, QA. With wireframes in hand, these different groups can productively work on their areas.
This phase is commonly known as User Experience.
Now we know what pages we need and their rough structure. We also know what pieces we need to design: hero images, headers, callouts, etc.
We have what we need to develop the final, polished look-and-feel of the product.
We lean on the work done in the Dive phase to get a sense of the users (e.g. Are they young or old? Urban or suburban?) and the competitive landscape (e.g. Do competitors tend toward dense content or lots of whitespace? Organic or geometric imagery? Modern or outdated design standards?). From this, we begin to develop the aesthetic of the product.
Most generally, the design should:
- Enhance the brand
- Build trust in users
- Clarify the intended experience
- Be consistent, clear, precise, intentional
We carefully push the envelope, but we always keep in mind what is possible – and ideally straightforward – in HTML. Our design work is for naught if it can’t be faithfully realized.
To that end, we work as closely as possible with our developer partners. We want them to be a part of the design process.
It is also crucial that we deliver a detailed build guide made specifically for the developers. In it, we address specific design tactics (color values, pixel sizing values, etc.) and also their underlying strategies in color, typography, layout, button and form design, and more.
Developers can now understand what they’re building, from the big picture to the nitty-gritty details.
Big picture Diagram and Draft deliverables help devs architect the underlying structure of their code and inform decisions about which technologies to use. The finer details in Draft and Design guide the crafting that will ensure a consistent, standout experience for users.
We stick around to support the developers, explain our design rationale, and navigate the inevitable issues that arise as a concept becomes a reality. It’s vital that we remain available – at least in some limited capacity – as a connection to earlier work. If we’re not, we have found that the final product inevitably strays from the hard-won design intention.
The initial product development tends to involve a bunch of experts making a series of assumptions.
But once the product is live, we can gather fantastic, rich, detailed, useful data about what is and isn't working. We can test our assumptions and let our inexperienced and unassuming users guide our decisions.
Over time, we can optimize the product to minimize frustrations and maximize delight. We can use metrics like time on site and conversions (e.g. purchases) to gauge user success. We use this phase to eke out every last bit of potential from it.
This also lets us get a product – sometimes a "Minimum Viable Product" – launched as soon as possible. We then gather data, advertise the product, and push the company forward. With data in hand, we're then more asssured investing in building the right product.