I believe that the best process for any product is one that empowers its participants with the maximum amount of ownership and autonomy to deliver value - anything else is unnecessary. 

The Human-Centered Design Process I designed for Mixpanel that increased speed-to-value while deeply integrating our customers.

The Human-Centered Design Process I designed for Mixpanel that increased speed-to-value while deeply integrating our customers.

Team Dynamics

Core Values
The heart of any process is the team of people who must believe in the fundamental principles adopted. Chances of achieving optimal performance are minimal without the philosophical buy-in from a team that is both protected and challenged by the right process. To guard against this outcome, I first seek alignment with my team on the "why" we do things the way we do and apply the "how" of practices once that foundation is grounded. 

Organizational Integration
Integrating the design team with Agile, Lean, XP, waterfall methods, or multiple processes is a business necessity. However, to reach optimal performance design teams need their own KPIs to measure success, and most importantly, when design is "done." 

Predictable Performance
High performing design teams aren't measured only by predictable velocity, but by the value that they deliver. While measurement of value should be governed by product performance, it must also be challenged by the organizational endorsement of design as an integral part of the company's brand. To achieve this balance, the collective ownership of the team must be promoted over the contribution of the individual when it comes to solving problems with design solutions. Solidarity, fostered through the persistent promotion of courage, vulnerability, and respect, delivers a sum of product solutions greater than the parts of the teams that deliver them.

Here are some samples showing performance reporting and team structure/integration:


Product design without research is not product design. Research defines boundaries informing designers of the problem scope and signaling the success or failure of a solution. Without it, the discipline of design flounders and falls victim to the subjective values of decision makers who are not the users. 

Product designers and engineers are best served by actively participating in the full spectrum of research from qualitative and generative, to user acceptance and behavioral data analysis, so that they can better empathize with their user. When budget doesn't allow for the research required, teams should be empowered to do it themselves. 

Below are some examples of research boards based on a structure borrowed from Pivotal Labs during a season we spent embedded with them in 2015.

Design Sprints 

There are so many benefits that sprints deliver so quickly; the laser focus of a diverse group, the cultivation of buy-in from stakeholders, the reduction of risk, the delivery of a valuable artifact at the end. 

I've been using the concept of sprints for 15 years and consider them a power tool when used in the right context. Depending on the situation, I utilize various exercises learned over the years including ones from workshops with companies like AdaptivePath,  modified brand strategy exercises, quantitative tools that reveal variance and patterns, and of course the incredible contributions from Google Ventures.


Borrowing from the benefits of paired programming, paired design yields faster solutions, reduces documentation, breaks down silos, and builds solidarity. I've used paired designing under the label of "participatory design" with stakeholders and users during research sprints to discover mental models and generate potential solutions quickly. I frequently use paired design to supplement the front-end development, where production designers sit with engineers to both develop product features to spec while fleshing out the last 10 yards of the interaction design. Pairing breaks down the walls between disciplines and just gets you there faster with a better result, period. 

Designing in the Browser

The value of making decisions about visual and interaction design in the browser is obvious, that's where interaction touches the user. A designer should be armed with the understanding of how functionality is expressed with code to empathize with both their user and their development team. This typically requires a modification to legacy processes that tend to require design specs to be "thrown over the wall" before development begins and may pose a threat to development team's pointing accuracy. However, when positioned against the value of the product delivered and the promise of reduced front-end regression effort, I've found this practice to be adopted by organizations with enthusiasm. 

Flows & Wires

My primary tool for bridging the gap between collaboration, requirements, research, feedback, and development specs are flows and wires. User flows provide visibility to quickly establish scope for developments teams and design requirements for pattern library components. Swim lane schemas provide clarity of roles and experience for new functionality to sales when selling custom enterprise installations. I've found the discipline of staying in the wiring phase long enough to validate solutions is great way to remain, "in love with the problem" and avoid becoming too attached to one solution over another. 

Pattern Libraries

Pattern libraries, when designed with the holistic understanding of the product's value, ideally can become a designer's primary tool. However, this can be an elusive goal when chasing an ever evolving product roadmap. In reality, pattern libraries can be a blessing and a curse – the former when they are comprehensive enough to serve the product and the latter when they are not. Nonetheless, the exercise of defining and integrating anything from a style guide to a pattern library unifies the mental models of your engineers with designers and builds a dialogue that pays off in efficient execution in the long tail of pattern implementation. 

Prototyping & Testing

Prototyping for the purpose of testing is an integral part to any good product design process, and my teams apply prototyping at various phases along the way. When velocity demands deem it necessary, having a dedicated prototyper with an intimate understanding of pattern libraries and code bases can be a valuable member of the team. Integrating the prototyping and testing cycles with established reporting objectives streamlines and automates the feedback loops and contributes to optimal team performance. Our prototyping spectrum starts with wire-flows used for quick validation with beta users or stakeholders and extends to fully functional prototypes for more complex interactions that depend on multiple variables to reach a user's goals.