My design process

5 min readMay 6, 2019

To start training for a 5k, the first step is to run a 5k. — Unknown

This is my favorite analogy for how I think about UX. If you want to quickly confirm or refute any assumptions a product team has, build something that can be tested against. Then continue building.

Background

I have a broad background when it comes to UX. I started in advertising as an art director, focusing on large and small client campaigns for companies like FedEx, Sprint, Yahoo!, EA Games, Frito-Lay, US Bank, and PG&E. This work led me to focus on product development, to baking user value into the entire product. This change of mind in turn led me to the enterprise and startup worlds, where I focused on projects in consumer, finance, healthcare, and larger enterprise work — all with the goal of exploring ways to test hypotheses with different levels of prototypes.

For background into my process of larger team collaboration, I originally studied UGL (Understanding Group and Leaders) in an Interactive Art Direction program in Sweden at Hyper Island. This evolved my process to think about group dynamics first; in relation to massive, multi-team projects. As I furthered my career, I also wanted a deeper knowledge of web development best practices and UXE. To gain this insight, I took time off from pure UX and began studying at General Assembly’s three-month intensive Web Development Immersion course, which focused on front-end and back-end engineering.

Experience

In my career, I’ve jumped from large companies to small, B2C to B2B, and even from client work to focusing on my own projects. I’ve worked in finance, healthcare, careers, social sites, productivity, and many other industries. In these fields, what has always fascinated me the most is working on the weird, complicated problems; the “impossible” problems in product design.

I believe great UX is viable for all industries. UX should always come back to the basic principle that products should be simple to understand and easy to use, no matter how complex the problem.

Understanding there is no perfect process

When starting any project, the first general rule I remember is that there is no perfect process. Your process should be defined by the problem, the team, and, most importantly, the people who will use it. That being said, there are some controls and general flows you can and should take advantage of.

Process is about teamwork

Going back to my background in studying and implementing UGL, the first step to any project is to really understand who you’re working with and how to achieve a unified goal together. This goal is should be defined and agreed to internally. From this point, the project can really begin.

Fitting myself into the process

My work process must be flexible to the needs of the existing project and not be bogged down by any ego. Based on the project, I may manage the team, partner with experts to rely on their knowledge, or do the pixel pushing. As long as I’m sharing and implementing my skills for the benefit of the project overall, this really lets me enjoy myself.

My process (Wash, rinse, repeat) or (Reduce, reuse, recycle)

For more insight into my process, I start by defining the real problem and real users beyond personas. The goal is to work with real users when possible, versus focusing on general personas. That’s why I follow these steps:

Real user research
Internal team interviews
Stakeholder interviews
Initial solution/paper prototype /“real” prototype to solve that problem with users and initial stakeholders
Come back to initial researched users
Define what will be used for the MVP (stressing viability)
Organize the team to divide and conquer tasks
Launch the MVP
Keep iterating on user feedback from the MVP

There is no perfect process, but I do love design sprints :)

Prototyping and testing

This is also entirely based on the product and product lifecycle stage.

A workshop I gave on product ideation and rapid prototyping.

Tools I use include include InVision, Principle, Simple Paper Prototypes, and creating fake websites or products. But no matter what, remember, the tool doesn’t really matter.

What is important is tracking prototype testing properly to really understand the data. I always try to set goals and define my success metrics as soon as possible.

Chatbot event where I ran the panel on the topic of understanding and tracking user retention. Video link.

Panel for discussing AI in bots on the topic of baking in good user experience.

Success through failure

I tend to start design reviews by saying the following:

“Tell me what’s wrong.” — Me

The reason why I love UX is because I love being told I’m wrong. No assumptions, only hypotheses reiterating on the problem with my team and with myself.

Asteria is the perfect example of a project that taught me this through failure. Asteria (Futurism article) was a hardware and blockchain project named after the Greek god of the stars, and falling stars. As we reached for the stars with a project so complex with the use of blockchain, hardware components, ML models, and web collateral, there was only room to really crash, like a falling star.

Closing thoughts

When thinking of UX, the solution is not always as important as knowing what the real problem is. I’ve built my career around trying to understand this process. And any real understanding of a problem is having the ability to fully work with experts and stakeholders in a smart and collaborative way.