November 7, 2020 · 10 min read

My Process

I’ve often heard it said that “you should fall in love with the problem, not the solution” - and while I absolutely agree with that statement, I’ve fallen in love with finding problems that need solutions.

I’ve worked on countless projects over the years where I am approached to help design a solution to a problem - and often times the solution that’s proposed is based on a loosely formed problem statement.

Product managers and owners often “fall in love” with their solution ideas, but I find it valuable to help those that approach me look closer at the problems that they are addressing - sometimes there are brilliant solutions out there to problems that they aren’t aware exist. When I have my way, I’ll spend just as much time on discovery and forming a solid problem statement as I do on the ideation and design process.

Typically this is done using the Double-Diamond approach to design where you:

  1. Look at the problem space and get the broadest knowledge that I can. (Discovery)
  2. Hone in on a problem that is both impactful and feasible. (More focused discovery)
  3. Define the problem.
  4. Develop lots of ideas for solutions to those problems. (Ideation)
  5. Validate that one of those ideas is the most valuable. (Prototyping and Testing)
  6. Detail the solution.

Double diamond chart showing the design process from problem definition to solution

Tactically, even when there is a deadline looming, a project plan can be put together that still focuses on the breadth of problems that can be solved with a quick solution. Any number of discovery methods and design deliverables can be combined that can satisfy both the user and business needs and bring something to market that is not only a good product, but “The right” product to create.

chart showing the steps in the design process from discovery to iteration and testing

Discovery & Research

Every project is different, and I can’t always get to (or even recommend) every deliverable under the sun, but on large projects or over the course of several years working on a product, I will touch almost every UX deliverable, from persona development to hi-fidelity prototypes.

Involving stakeholders throughout the process and relying on users to build out research (including them in card sort observations, looking closely at analytics together to define metrics and user testing together) to develop a living strategy document will create more focused discussions that connect both user and business goals.


Personas are an import part of getting everyone, including stakeholders, researchers and designers, on-board with the motivations and behaviors that drive people that will be engaging in the experiences that you are creating. Personas become a mechanism for validating how solutions can impact user’s behaviors throughout the design process - making sure that the experiences are looked at through the users eyes instead of leaning on our own biases.

Although they are no substitute for the actual behaviors that users will display with your experience, they will help to focus on what potential solution is most important to users, where those users might get the most benefit, and will help stakeholders and product team members to gather the most pertinent information when designing new experiences.

Experience & Journey Maps

Knowing what users are doing and what they are thinking across the different phases of an experience can help to expose where there is friction in that process that could be addressed with a potential solution. Each product or experience is unique and often unique to each persona. When looking at such specific aspects of each experience and each persona, you can find opportunities that are often overlooked that may have a significant impact that could or should be addressed.

Once you have a list of opportunities, you can map the impact to a user against the ability to create changes to the process. There is often low-hanging fruit that can be tackled immediately, while other issues will need to be addressed with new solutions.


Once we know where there are opportunities for our users and craft detailed “How might we” statements, it’s time to generate ideas. At this part of the design process, given that we are on the same page as to who our users are and where there can be improvement, coming up with ideas and not falling in love with them, can lead to solutions that wouldn’t have been imagined without taking such a focused view on users, their behaviors, their tasks.

Every idea during the ideation process is valuable. You may not want to explore some, but others will seem that they could have a real positive impact to users , potential users, and even new markets.

Taking what we know about our users, where there are areas that can be improved, and the strategy of the stakeholders, the most important part of the design is rapidly iterating over ideas, validating them against the user and business goals and making sure the overall experience is clear for the users.


What makes a project most successful is not the amount of deliverables created but the agreement on common problems faced by users and who exactly your users are. Working closely and collaboratively with stakeholders to agree on common goals that balance the user and business objectives is what leads to a great product.

Building on a living strategy document during discovery throughout the design can jump start ideas and new goals for future product development or even refocus the current goals.

Stakeholders in a project can often disagree about an approach or think that one idea is better than another, but those ideas can be validated and iterated on rather quickly so that time and money isn’t spent creating something that people will not engage with.

There is never surprise feedback when we work openly and collaboratively during each phase of the UX process.

Architecture & User Flows

Once you have a solid vision for a product, detailing out each step of the process that a user will take, organizing the information in a manner that they would expect, and matching those paths to each persona’s tasks will show where there may be friction in the process and if there are scenarios that may not have been considered.

Taking the architecture and flows into testing early on will illuminate the user’s mental models of the site and make sure that it is aligned with what’s being created before ever having to create detailed wireframes or comps.

These processes will remove uncertainty and clarify any assumptions that are being made in the design of an experience.

Wireframes & Prototyping

Bringing a solidified idea to life lets you test if that idea is worth pursing further. Prototypes can range from simple storyboards to refined interfaces, but the main goal is to be able to show your vision to users and to determine if their expectations are being met, if you’ve made improvements to process, and the users understand the system.

Most importantly, you want and be able to make changes quickly and incorporate feedback. Each prototype should improve on the last until you have confirmed that the new product or site is viable and desirable.

Concept & User Testing

Instead of rushing an idea into production and creating a product or experience that you believe will work for your users, creating a rough prototype of an idea and taking it directly to users can save hundreds of person hours.

Simple sketches of an interface can elicit valuable feedback from users without having put any money into an idea. You want to be able to rapidly iterate on your ideas to figure out if the product is even something your users want to engage in. The best way to know is directly from users. Spending just a few hours of time with your users engaging in a new idea can validate if it is desirable and if there is room for improvement.


Applying a company’s brand or developing a new one for a product can be both challenging and a welcomed constraint. Given that there was constant sign-off during design and iteration, the visual design of a website nearly creates itself.

Creating mood boards to help express the brand and applying that to style tiles can give a clear initial direction on how interface components will manifest and the interplay between them.

Design Systems

It’s important that every button, element, component, layout and state is explored and defined in order to eliminate any issues as the system is being built. Have a living design system helps to make sure edges cases don’t cause problems and that you don’t need to make design compromises later on. A solid design system lets me create screen and prototypes in record time.

Visual Design

With all that research, ideation, and testing behind us and our system in place - our new product starts to look like something that can almost be shipped - a nearly perfect state before moving into development.


At this point in the design process, we now have something that resembles a shippable product and can be signed off and handed over to development. That doesn’t mean that developers haven’t also been along for this ride with us - they are just as valuable and informed and contributing participant in this process as the product owners. With my experience in developing code and working with large scale CMS’s, I can bridge what is typically seen as a divide between design and development.

That’s the gist of it

It can sometimes be difficult to see the value in all this as not slowing down the creation of a product, but in the long term, spending more time in design leads to major cost savings as compared to when an issue arises in a half-baked product. It’s easier to change a picture than it is to change a website. I often tell people - “Trust the process” and you’ll see the rewards later. Those that have gone through this process never go back to creating products - they continually live inside the research of their users and use that knowledge to make informed decisions.

I’ve just skimmed the surface on what’s entailed in this - I left out detail on how you measure your ideas and know where to make improvements, but I’ll save that for another day.

Document Metadata

Raw File With Signature: .txt.asc

Hash of Raw File:

Ethereum Proof of Existance Transaction:

This text is Creative Commons:Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

Need More? If that wasn't enough, why not check out my blog, see how I work, or setup some time to talk to me.