my design process

A note about my process. Over the years my design process has evolved from a fairly linear, waterfall-style approach to one focused on using data to design and develop discrete solutions in a collaborative, quick way. The sooner designs get out to customers for feedback the better. Companies will always have giant design projects (some showcased in my portfolio!), but customer-centricity tends to favor focusing on specific customer issues and testing, testing, testing. With this said, here's the process I promote . . . a process that may be a week-long, or it may be a couple of months long depending on the complexity of the design challenge.

Identify opportunity.

When starting a project, my first questions are elemental: What are the business goals of project? Who are the users of the final product? What data do we have about customer usage?  What problem are we trying to solve? 

At this phase I work with product managers to document the project's business goals: measurable success criteria for the project. These success criteria will help me--and the team--measure the effectiveness of design work throughout the course of the project, and ensure my work is grounded in what the users need.

This phase is also where user research is essential: interviews, surveys, usability testing, contextual inquiry...understanding user needs and goals is a critical part of identifying an opportunity.

Design a solution. 

With an understanding of the project goals and an understanding of user needs, I go about designing a new experience for them working closely with product management. Almost always this starts with ideation. I like to approach the design phase as a brainstorm--either with a team or by myself, depending on the scope. I explore adjacent products to get inspiration and then generate as many solutions to the design challenge as I can. I then select the strongest ideas from the brainstorm and proceed to add fidelity to them. The designs start basic: pencil sketches or even a UX flowchart, followed by low-fidelity wireframes. I work with engineers to make sure we're taking into account technical limitations and abilities, and business stakeholders to ensure I'm solving the core business problem.

Feedback, iterative testing, and design evolution.

Small scale design challenges--adding a new field to a form--do not require significant ideation (and may not require a designer!). For more substantial projects, like launching an entirely new checkout process, iterative testing with users/customers is important. In such testing my goal is to present users with real-world tasks and scenarios, and see the extent to which my design supports them. I take what I learn from those studies and evolve the designs further, eventually narrowing down the design alternatives to one as that design itself matures into a hi fidelity design.

Develop.

Ideally, while designs are coming together the engineering team begins its work. When the design is ready for development my work transitions to supporting development teams. In the past this has meant documentation, redlines, and so forth--now, I prefer giving them a few high level concepts and partnering with them to work through design/development together. Specs don't work, collaboration does. 

Deploy and learn.

Upon deployment is where we get to discover whether we've truly solved the customer need. Has conversion rate gone up? Has customer satisfaction increased? Have call center calls decreased?  The sooner you can get design solutions in front of customers to learn from them the better. And so repeats the cycle . . .