Process makes perfect

I'm a design generalist with a focus on research and conceptualization. My ideal process takes me from a project's inception to completion, from the earliest research phases to final pixel polish. Here's what that might look like...

If I'm brand new to a topic, I immerse myself in secondary research. One exercise I find helpful in this phase is to create a list of factors that drive the people and problems I'm working on. Cagan & Vogel suggest categorizing factors as social, economic, or technical in nature. These “SET factors” provide a wealth of data for later ideation exercises.
After orienting myself, I identify areas to explore via primary research with end users and other stakeholders. The specific research methods change based on the task at hand but the common thread is the same: draw out insights from stakeholders without asking leading questions. I recommend the Research Toolbox by ThoughtForm & Daedalus as well as Universal Methods of Design by Bruce Hannington and Bella Martin for thoughtful collections of design research methods.

Armed with a collection of insights, the generative ideation processes kick into gear. This is ideally done with a small group of team members from design, engineering, and product management. I'm a fan of the ideation principles pioneered by IDEO and some new activities by Google Ventures.
Sometimes ideation winds up being a lone–wolf task. That's not ideal, but in those cases I start with writing. Writing about your design intent cuts noise and forces focus. You avoid thinking about form, color, or typography. You're just considering a problem and possible solutions.
When multiple concepts are being pursued, I find it helpful to use a weighted matrix to rank ideas based on the team's values and constraints. When completed in a group, they are a fantastic tool to ignite discussion.

For a service or digital product, I find that charting and diagramming helps organize all the activity that's happening at once. This step could take place on a whiteboard, a napkin, or using a tool like Omnigraffle. Service blueprints are particularly helpful, especialy for the “line of sight” that denotes which processes are visible or invisible to end users. That scope preserves the magic of an idea while fleshing out its reality. These diagrams force a top down design approach with a low level of detail. Since iterating on a concept at the service blueprint level likely involves moving or cutting entire flows, you avoid investing too much time in a bad idea.

Once we have a solid concept to work with we can start to think about UI. I love sketching at this step since it maintains a high speed of iteration. I'll sit down with a pen and stack of paper, maybe a grey marker and spot color if we're getting fancy. When the interface takes shape on paper, I jump into production tools like Sketch. For other projects this step might be in HTML/SASS, After Effects, Solidworks, clay, wood, et cetera. — whatever medium is most appropriate for expressing the idea. Most often, I'm producing mockups of web and mobile products in Sketch. The core workflow is smooth and, thanks to an active and excited community, the availability of plugins and other resources is tremendous.
After attaching version after version of UI updates on project management tools like Asana with mild frustration, I've become a fan of sharing mocks in Google Drawing. For a team that's already running Google apps, the commenting flows are dead simple and notifications integrate well with your email.

With the first take of the UI laid out, I've been creating more interactive prototypes. I've explored a few tools along the way but keep coming back to those based on html/css/js. I'm a big fan of Framer.js and its integration with Sketch. Animations, transitions, and simple flows are easy to build and tune at a high level of fidelity. Since you're left with source files, this method makes it easy to host and share. I wind up putting up a project site with a directory of prototypes to pass around the product team. I'm getting comfortable with the command line and Git, but my use cases are isolated to my own projects at the moment so I'm missing out on collaborative workflows. For mobile prototypes, Clear browser and similar apps emulate a native experience well enough to test with real users.

Evaluative research is a worthy endeavor for getting feedback on your work and influencing the refinements you choose to make. In practice, it's easy to introduce serious flaws that lead you in the wrong direction. Raucous focus groups, interviews littered with leading questions, and mindless metric collecting will do little more than waste valuable time. A diligent researcher using the scientific method will make usability sessions and similar usage tracking achieve results that improve your product.

When the team starts revving up on a new idea, it's important to make it an interdisciplinary affair. I'm not a fan of handoffs. It's a mistake to delay engineering progress until we know every last pixel is in place. Somewhere after ideation sessions, around the time that a service blueprint is coming together, each team member has their own work to focus on. That's why it's so important to be aligned towards a clear vision after those early sessions. As design goes off to bring form to an idea, engineering should be assembling the fundamental parts that will make that idea a reality. As the product takes shape, it's critical that all disciplines work together closely to keep pace with inevitable changes, avoiding unnecessary work. This process can understandably become hectic. A calm, organized, communicative product manager who can lift roadblocks with ease is crucial to keeping everyone on pace to finish.
As I go through this process more and more, especially for mobile products, I've been flirting with production code. We've repeatedly seen a bottleneck at the end of a launch cycle when balancing feature development, bug fixing, and test coverage against UI nits. Our design team has begun to define a workflow where bugs like “make this headline condensed bold, instead of just bold” become a designer's job instead of pulling developers from their focus. I'm excited to see how this workflow is implemented and where it takes us.

Launch day isn't the end. As a product designer, I'm invested in collecting and understanding the usage metrics and KPIs we're concerned with — both as a measure of our efforts and as inspiration for future enhancements. To me, this step feels like another method of evaluative research and a reminder that the design process is not linear. ❦