My design process
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 quickly that can be tested against. Then continue building.
I have a rather 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, PG&E, among others. This work led me to focus on product development further, which in turn changed my focus from building user-value into just the marketing, to baking that value into the entire product. This change of mind in turn led me to the enterprise and startup worlds. This work included working on consumer, finance, healthcare, and larger enterprise work. All with the goal to be able to explore different 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 into web development best-practices and UXE. To gain this insight, I took time off from pure UX and began studying at General Assembly in their three-month intensive Web Development Immersion course, which focused on front-end and back-end engineering.
In my career, I’ve jumped from large companies to small, B2C to B2B, and even 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 (Understanding Group and Leaders), the first step to any project is to really understand who you’re working with, and how to be 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
The real need I feel for my work process is to 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)
Three projects you can review to see varying flows are Viewics, RadBots, and T-Mobile at nathantross.com. These show different process flows based on the project needs.
For more insight into my process, defining the “real problem” and real users beyond personas is what I strive to do. The goal is to work with real users when possible, versus focusing on general Personas. That’s why I focus in 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
Prototyping and testing
This is also entirely based on the product and product lifecycle stage.
Tools I use include… InVision, Principle, Simple Paper Prototypes, 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.
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 (shown in my portfolio) 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. :)
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 understand of a problem is having the ability to fully work with experts and stakeholders in a smart and complimenting way.
Other resources and sources of knowledge I cling to
Any books on analytical data comprehension.