Design Process
I’ve designed a lot of projects, but I always rely on a common set of tools/steps throughout. This section details the different phases I go through and what’s involved. Below, I talk a little bit about how I approach some of the steps in the design process in my own way. All the examples on this page are my own that have been used in previous projects.
At a high level, I lean on the ‘double diamond’ approach that many designers use. But I have my own interpretation of it. While some designers REALLY lean into it, and break it down and atomize it, I prefer to use it as a flexible guide that helps me chart a course to completion with a sense of order and agility. After all, every team and every timeline is different and contingency is always a thing. Plus, I wear a lot of hats when I’m on the job so flexibility is really key.
You’ll note a ‘stakeholder buy-in’ at the delivery phase. While this might sound discovery-oriented, this isn’t the same as buying into the philosophy and features around discovery. This is looking at the actual product and seeing how it’s ultimately manifested - everyone needs to turn their keys together.
1-Discover: Research and Discovery
This is the beginning - where teams/partners/clients come together after a concept has been proposed and perform some exploration to tease that concept out. Sticky note and white board exercises are common here in order to guide priority and primary features. I personally like to also double down on literature review before a discovery to ensure the user psychology is well accounted for and that the prospective efficacy of the product concept can be grounded in terra firma.
Limitations, target pain points, target market and market viability are all raised here to make sure things don’t proceed on the wrong foot. Client parameters are established if applicable.
Initial surveys and focus groups early on as part of the market analysis really help inform this process, especially when designing for kids. We make a lot of assumptions as adults about what kids like, but it only takes the feedback of a few kids to course correct early on - and the effort is worth it.
This whole phase should culminate in a treatment or a Project Charter being written then that can be shared with the group and ensure that everyone is turning their respective keys on the project so far. It doesn’t need to be a tome. The project philosophy and intended play/design patterns begin their journey here.
3-Define: User Journeys/User Mapping
Often I will simply create user stories during the development of the persona and then move into a user journey. I leverage user journeys to capture the segments of an intended experience so that we remain internally cognizant of the sequence of steps and the pain points and where they happen. While it doesn’t really let you address the minutia, it does involve a lot of consensus building, and it lets you forecast the big bumps in the road while keeping everyone on the same page. In making these I try to keep objective, focusing on the prospective interactive experience and weighing it against the expenditure of time, extra steps and any other expectations relative to the average encounter for similar products with similar target personae.
5-Define/Develop: Wireframes
The wireframe stage is where we rough out the states of the experience in Figma based on the key features and pain points outlined. They can vary from from greybox style to something higher fidelity that draw on brand or palette . The way interactions are created for children are VERY different from those for adults, so visual weight and scaffolding needs to be considered and accordingly based on age bracket, single vs. duel-user scenarios, indoor/outdoor use cases and so forth.
As I note in Krystina Castella’s book Designing for Children, for the Biba suite of games, I approached our design from the perspective of four users—three developmental brackets for kids, plus the adult that leads the experience. It can get pretty crazy! So extensive notation is a must with wireframes to articulate what features and functions do and under which user scenarios.
At either this stage or the next, I would look into generating a clickable prototype in Figma.
6-Define: Sign Off Presentation
Assembling the totality of the documents above, this project should now be presentable to stakeholders in the form of a design presentation that lets you walk through the prospective experience along with rationale. This document holds particular value in situations where we are dealing with external client stakeholder so that everyone is on the same page. I don’t like to finalize a brief or a doc UNTIL the presentation is complete so that any changes required are reflected in the shared document. This is effectively a return to the original Project Charter in some ways, demonstrating the ways in which it has been updated to embody the spirit of the original exercise and the ways (why and how) it has been altered along the way. This may feature simple wireframes or more sophisticated mock ups depending on where creative is at or how related the project is to a prior product..
2-Define: Personae Research
Next, we start trying to specifically nail down the target user. For me, this is sort of like starting at the bottom of the product-market fit pyramid and starting the climb upwards.
Personae done the wrong way can be limiting and potentially self-deluding, so this is where we need to test assumptions about who we’re making ‘the thing’ for. Extant research reviews, surveys and focus groups can again help you determine whether you’re actually on the right track here - and the sample size doesn’t need to be gargantuan by any extent - just enough to feel it out. If a persona is going to be employed it should be challenged and validated to ensure that it is viable.
At a high level though, a persona helps individuate the target user and their pain points, incorporating a variety of criteria including, age, gender, familial configuration, generational predilections, technological savviness, census data and so forth. This helps us narrow down a number of simple elements. For example, if we know we’re targeting an app at seniors, it’s a safe bet that we can make the text larger than average as a default. This is also where you ensure that design and marketing are on the same page.
4-Define/Develop: User Flow
Here is where I get into the nitty gritty - the actual flow of the product from initialization of experience to execution of experience to completion of experience - along with all of the considerations for lateral movement along the way. This is where I begin to involve developers heavily to give them a heads up on logical implementation, but also to get their feedback. After all, these flows will change over time and you want those changes to be easy for your developers to actualize. While there is no escaping them entirely, surprises are generally bad news. I actually like getting developers to re-iterate a flow back to me to ensure we’re on the same page.
Depending on the size of the project and the shorthand knowledge of the team I will heavily annotate these so that developers have as much information in one place as possible. Devs hate flipping through multiple docs and prefer efficiency where possible. This is also why I tend to provide a screenflow (see below) for developers that combine wireframes with a user flow so there is a visual logic for them to follow.
6-Define/Develop: Screenflows
Prior to production, I will re-create the user flow as a series of connected screens using wireframes and/or mockups created with shapes, sketches and sundry art. This gets provided to devs alongside the user flow, which helps them flip back and forth between gameplay logic and front-end as needed without losing the plot. I accomplish this primarily in Figma. If there is a particular information architecture that underlies the design I will accompany Figma screenflows with a Miro or Whimsical document.
Essentially screenflows become the storyboard for the app or game. During production, I will often fill in the gaps on this screen flow with completed states derived from production. When all of the states are filled in, the game should theoretically be at or near completion. Almost like a sticker book!
7-Define/Develop/Deliver: Design Hand-off
Once everyone is on board, a specification document can be formally compiled with all the information about the project that will be used both as a reference for stakeholders, but also as a guidebook for developers. Will things change? Absolutely. Most of the work done on a design brief probably comes after this phase of prototyping the MVP, but those things are all necessary to see what you’ve actually built. All the research to date, design validation and testing outcomes should go into this document as you move along. Building and iteration becomes a cyclical process that will constantly feed this living document as then move into researching the efficacy of the product through testing methodologies such as surveys, focus groups, interviews, contextual inquiries, diary studies and playtesting.