UX Design Phases from Start to Finish
A story about a really long rope and stealing from other disciplines
Three-quarters through his captivating book The Great Bridge, David McCullough tells the story of the Brooklyn Bridge’s crux move. Two towers had already been completed, soaring taller than any building in either Manhattan or Brooklyn. What remained was suspension: hoisting a 3,000-foot rope two hundred feet into the air. For nearly an hour on the planned morning of May 14, 1883, the crews waited for river traffic to subside. Then they fired the cannon to begin.
“In a few seconds the rope began to move… faster and faster the space of clear water between the two parts narrowed, and in four minutes from the time of starting, it swung clear of the surface of the water, with a sparkling swish, amid the cheers of spectators.”
What a rush! But also: what a risk. What if the winches, in twin formation, hadn’t been set up correctly to account for the tide? What if a wayward ferry had crossed at the wrong moment? There are no do-overs, or certainly no cheap ones, with a 3,000-foot rope.
Software is nice that way; maybe too nice. The principles of continuous deployment and iterative design means designers and engineers can always tinker a bit more here, fine-tune a bit there. Sometimes, this adds up to projects trapped in the chasm of almost but Never. Quite. Done.
The fields of software and UX design borrow a lot of terminology from architecture (including, erm, “software architecture” and “information architecture”). But let’s go a step further. Let’s borrow their definition of the design process, too.
A key part of an architect’s design process is knowing exactly what phase of design they are in. Why are architects better at this? Well, design for the built environment is hired and completed in phases. A university might hire a firm for a conceptual design (the purple circles below) and use that concept to pursue funding. Two years later, after securing funds, they may hire a different firm for schematic design and design development. Clearly defined phases, including standard deliverables at each phase, are essential to making these long-term hand-offs work.
An introduction to UX design phases
Most software teams don’t hand off projects externally between stages, but rely on internal inflection points between UX, PM, and engineering. Often, that’s where workflows get murky. You might find yourself asking questions like:
- How much time should we allot for feature X on the roadmap when we’re not even designing it until next month?
- How do we strike the best balance between quality and consistency?
- This mockup is really beautiful. So we’re almost done with design, right?
Product and engineering teammates are “users” too — they’re users of design work. In order to complete their jobs, they need certain design deliverables to make decisions or write code. We should tailor those deliverables accordingly, from storyboards, sketches, and flows to mockups, specs, and code snippets. From start to finish, it looks something like this:
The Phases, Defined
Stage 1: Concept design. Whether your weapon of choice is a storyboard, outline, or project brief, your true goal is giving enough info to answer questions like Will this require major changes to our data model? or Is there a good library out there for this functionality? Your goal is to provide enough detail for engineering make t-shirt size estimates (S, M, L, XL), and product to make go/no go decisions.
Stage 2: Flows & Wireframes. Once the user’s workflows are defined, you’ll know what parts of the app are changing. From there, you can write stories and create estimates. This is a good time to add or subtract major parts of functionality.
Stage 3: Visual design. Here’s where a design comes to life: how the screen looks, how it behaves for scrolling and clicking, and more. Stages 3 and 4 are inextricably linked, but I’ve defined them separately because 3 often gets done, while 4 is ignored. Which takes us to…
Stage 4: Documentation. The super sexy part of specifying all the details needed to build as intended. Depending on complexity of design, front-end savvy of engineers, or your team’s working relationships, this can range from “use normal header styles and Bootstrap grid” to a working prototype to annotations of exactly how many pixels between each element and their hex colors.
Stage 5: Dev admin. This phase is often the difference between usable and delightful. In construction, contractors must complete a punchlist of minor repairs, cleanup, and anything else that doesn’t meet contract specifications before receiving final payment. Software deserves punchlists too; I’ve found the final scrub makes a huge difference in fit-and-finish. (Just once or twice, though — not 8 revisions, sheesh. Bonus points for providing the exact CSS changes needed, or organizing by files that need to be edited.)
Making design phases work for you
Case study: Planning a dashboard
Let’s say you are building a dashboard for a very large dataset that could have up to 90 million rows. Depending on what stats are shown, you may need to cache heavy calculations. As soon as Stage 2 (Flows & Wireframes) is complete, bring that to the tech lead. She’ll have the right information to consider various development approaches. You can jointly make tradeoffs — modifying the design, or adjusting project estimates—before sinking too much time making Stage 3 (Visual Design) pixel perfect.
What design phases don’t solve
- The designer-developer hybrid. There’ve been some great conversations recently about design & engineering being incredibly intertwined, but companies still not knowing what to do with hybrid skillsets.
- Firefighting mode. Using this framework sets you up for a smooth development process. You’ll still have to scramble if priorities suddenly change, but you can scramble methodically, choosing some stages to compromise on and others to fine-tune based on project needs.
- The great Agile debate. You may have noticed jargon like “sprint” and “groom” sneak into the Design Phases map above. I’m a fan of just enough process to get great work done. Sometimes that means full-on Agile methodology, other times just subsets of those practices. But that’s a post unto itself.
A few final thoughts
- Lather, rinse, repeat. For larger projects, it’s quite common, and even desired, to iterate within stages or between adjacent stages. But if all your projects jump wildly between stage 2 and 4, that’s a problem.
- Tightly constrained projects can skip stages. Designing a new onboarding experience might require all 5 stages. At the other extreme, a new account setting might need only Stage 4.
- These stages represent the strengths of a well-rounded design team. You can have them in one individual, or spread across specialists. Recently, I worked with a team in transition from a centralized design team (where different designers owned interaction vs. visual design) to an embedded one (where each designer is expected to own all 5 stages). Full stack design is a common role these days, but very few schools train this way. One designer was a strong visual designer, so his stage 3 (visual design) work was stellar. But, the team needed all 5 stages to bring those designs to life, so we worked on building his Stage 2 and 4 skills to make him a more well-rounded team member.