My Design Process



When people ask me about my design process.  I often say that there are two versions,  one version is the “academic version” with many steps that could take up to six months to complete and the other “the real world version” where I’m given a ticket in Jira and I have two weeks to complete a feature.  


“Developing your own process is almost as important as developing your own design style”

I started my career like many designers thinking the design process is much like the design school. Get the assignment, show three options, iterate, and then wait for the applause from the rest of the class.  I’ve found out the real world is nothing like that.  Every single company I’ve worked for has it’s own process to develop a product.  As the designer, it’s imperative that you need to spearhead and refine the design process that works for you and for the company.  


  • Figure out what problem you are trying to solve and who you are designing for.
  • Define not only the target audience but what is a typical use case for when they are interacting with your product.
  • Is there a core task you want a user to complete like: complete signup, refer a friend, enable notifications, complete onboarding, set up your profile, etc.
  • Are you long term goals as well like we’d like to elevate the brand or we want to build a positive feedback loop to keep users coming back for more.
  • Ask What does success look like? (Qualitatively and quantitatively).

Getting dev’s involved with design process early on not only gives you an idea of the scope of work involved but also gives them a feeling of ownership of the project.  I’m my experience there no one better suited to poke holes in your flow than a developer.

  • Have a kickoff meeting with not only your stakeholders at all levels of the company. The kickoff meeting is a perfect time to get input from the developers, other designers, marketing, leadership, and customer service.  Having a large kickoff meeting will help the design team be transparent and avoid the classic “you are designing on an island” thinking.  As you move through the design process slim down the number of people in your meetings and eventually only meet with the stakeholders when you come to the final design.
  • There’s no design necessary for the kickoff meeting. Write users stories with sticky notes and put them on the wall such as “as a user I’d like to save my favorite recipe and see the later”.  Organize the user stories into feature buckets and eliminate duplicates or scope creep.
  • Once you get consensus on what you are building define the timelines, what platforms they will be published on, and who are the stakeholders.


  •  Chances are you aren’t the first person trying to solve this design problem.  See how other industry leaders are solving this problem, see who is the new up-and-coming competitor and how they are solving this problem.  Sometimes inspiration doesn’t even need to come from products in the same field.
  • Interview your current customers or if you don’t have any customers yet find people that would fit into your target audience and have a conversation about what services they use for this design problem.  What do they like about it?  How would they improve it?  Ask them what would they pay to solve this problem (the answer is often nothing)!
  • Gather products with similar features and flows you’re trying to solve for. The most crucial part is to screenshot each step and print everything out so the entire team can evaluate every page with pros and cons and what you can you improve or avoid.


  • Unless you’ve got some really strong and specific data against it, thinking Mobile First makes the most sense. It’s easier to add complexity to a design as more screen space becomes available, rather than to reduce its complexity for smaller screens.
  • Make sure to include plenty of comments right into the wireframes. Comments make wireframes look more interesting, and they’ll guide the client through your thinking process.
  • Start with low fidelity black and white wireframes and nail down the content modules and the flow.  When running a design meeting it’s much easier to get the room to approve wires rather than get hung up on a specific photo or which shade of purple to use.  If the meeting gets off track have people focus on placement of the content, the flow, and user experience.  Try not to engage on what kind of picture should be in the hero section.
  • Design with real copy if possible at this stage. Working closely with your content/marketing team helps prevent surprises late in the game.
  • After filtering to a few solid options, put something together that’s functional (using the notes from your analysis with flows, and entry & exit points). Share with the team, get feedback and critique.



  • There are a ton of prototyping options out there I prefer using InVision because it allows users to test on  mobile or web and they can leave comments on specific areas on the screens.  I often find with competing schedules with stakeholders Invision allows me to send out a quick prototype and people can review on their own time.  Some designers complain that Invision doesn’t give you enough control of unique interactions but it’s speed and ease of use wins me over.  It also accepts gifs that can be used to replicate animation if you need to show that.
  • Go thru the prototype feedback and address the feedback and make the necessary changes.
  • Get users and talk to them. If strapped for time and resources, get people you know or people from Craigslist who somewhat match your user profile and bring them in for guerilla usability testing.
  • Now is your time to shine! Test your prototype with people that have never seen it.  I like to use or TryMyUI.  If possible try to get the users that are in your target audience.
  • Go through the data of your user tests and compile a findings report.  Are people getting lost?  Are people completing the mobile core task? Is nobody tapping on your hamburger menu?
  • Adjust your design accordingly , and nail down the user experience to meet your goals.



 Often time when you create something yourself you have biased of how easy it is to understand. Validate internally and test externally is the sure fire way to get around that.



  • This is the time to obsess over typefaces, colors, photos, and the look and feel of the product.  Assembling a mood board that shows colors, font choices, illustrations, and pictures can save you some time if the style of the company hasn’t been defined.
  • Decide on some typography combinations, sizes, and colors that fit your brand and the product.  If necessary do variations on your visual treatments but I would not recommend more than 2 versions otherwise you can get the dreaded “Frankenstein design” where stakeholders pick parts from one comp and other parts of the other comp to create another style that may not work together.
  • It also helps to emphasize the business goals of the app, the target audience, and other marketing aspects in this phase.
  • If stakeholders want to change their mind of the flow remind them this would invalidate  the user testing that has been done and we would need to test the new flow.
  • What I discovered is that there comes a point in time where working at a higher fidelity actually requires less time than working at a lower fidelity. For instance, once our visual style had been developed in the mockups, it was no longer beneficial to build wireframes; going straight from sketch to mockup worked just fine.



  • The devs should be a part of this entire process.  I tend to involve devs early on in the process and excuse them from high fidelity design phase unless their time is free.
  • Prior to the production of assets meet with the dev who is going to be the lead on the project and define how they want the assets delivered.
  • I also like to sit with or near my devs during the building phase because there is usually going to be many trade-offs and possible use cases that haven’t been addressed.



  • QA your product backward and forwards. Use your product under real live conditions (and preferably in multiple places and scenarios.) Gather feedback and make adjustments. Make sure you address everyone who must know about design changes.


  • Are users dropping off?  Determine why.
  • Are users completing their core tasks? If not determine why and adjust your design.
  • Whatever the result may be, ask WHY it might’ve happened, form a new hypothesis, tweak the design, and re-launch.



This is the long-form version of my design process and my experience in the real world is often a shorter.  Timelines get shortened, goals get changed, or sometimes the entire company might pivot from one value prop to another.  Being an exceptional designer means you have to roll with the punches and handle feedback gracefully.   All feedback is not equal and you have to separate valid feedback from people’s personal preferences.  If you get in a bind where the team doesn’t see eye to eye on a design decision test it and have the user testing validate the decision.

Keep your focus on the user. Do whatever it takes to:
  • Provide an amazing experience, that
  • Helps your users accomplish their goals, and
  • Enables your product and company to flourish

EveryMove Case Study




EveryMove is an app that converts physical activity into real world rewards.  The intent of the app is to be your hub for working out, celebrating fitness goals, tracking all of your fitness data and activities, and encouraging your friends.  There are two methods to get your fitness data into EveryMove. One is connecting an app or fitness tracker and syncing your data, the other is manually entering your activity via the mobile app or website.  My task was to create a seamless easy to understand user experience for active people to enter their physical activity.

Read more