Design isn't an exact science. My process varies project to project, but below you'll get an overview of some of the tools I use during my problem solving process and when leading teams.
Generally, my process follows the order of the items as you go down this page. Sometimes parts are omitted because of time or budget concerns. Team size also affects which parts I include. I do, however, feel comfortable with and enjoy every part of the process. At the end of the day, some of my best work has come from my being involved in every step of the process.
Getting the right people in the room early is important. This can be product managers, sales, customer success managers, and sometimes even the CEO. Hopefully, design has a seat at the table and come in early to ask the right questions. I usually pair myself up, or a person on my team, with a product manager to understand requirements. If requirements are unknown, I will work with product to define them.
Users don’t always know what they want, but they often know what they don’t want. Finding out what current pain-points a user has can help you understand where to focus. This is often done via surveys (Google Forms or Typeform), but focus groups can also be effective here as well.
Understanding the competition can often help you understand your users. If a competitor's product is already established, with lots of users, there may be a certain set of features that your users may already be accustomed to and will expect from you. Understanding your competitors will also help you make decisions such as pricing, market segment, marketing, branding, and more. I will typically create mood boards that focus on not only general product features and design, but also the little things that separate great products from mediocre ones.
"People don’t know what they want until you show it to them”
These are the people we think (or hope) will be using our product. I try to focus less on things like hobbies and family, and more on age, education, financial situation, technical level, frustrations, needs, and goals. Once these are set, it’s good practice to make sure the design is still serving these personas. This doesn’t always happen, however, and you need to know when to make a decision to change the design, or re-visit your personas.
Putting your personas into real world scenarios is important. These scenarios need to have context and be flexible enough to handle variations. I will usually do this by sketching out on paper different scenarios the user might find themselves in while using or planning to use the product.
Customer Journey Maps
Modern digital products are no longer simple objects. They often contain complex structures and features that a user must navigate. Customer journey maps help guide the user along the product life cycle, making sure to optimize things like the initial introduction to the product and engagement during and after use.
Structure & Flow
This represents how a user might navigate through a design to a desired outcome. It is similar to the site / app map, but is less rigid. I will typically focus on the main outcomes the product is focusing on, like completing a checkout flow. For example, there may be multiple ways for a customer to add a product to their cart.
Site / App Maps
Similar to User Flows, the site / app map shows the ways a user can access information inside a digital product, but unlike user flows, it defines the structure of the entire product. Every possible screen is represented here, and is often displayed as section names with arrows to and from other sections. In the past, I’ve used Omnigraffle for its parent child relationships feature, but have recently moved to Sketch for this.
Expanding on the site / app map, we get wireframes. These are fairly low-res, but I tend to start solving some of the UI problems here. I stick to using grayscale for visuals and low-fidelity boxes for content, like images and video. I try to have some kind of system for font usage and hierarchy to make the transition to high-fidelity easier, but without influencing the final UI design. In the past, I’ve used Omnigraffle or illustrator for this, but have recently moved to Sketch.
"People aren’t trying to use computers–they’re trying to get their jobs done.”
If a styleguide has already been established, I will make sure it covers all the areas that the design will need. If there are missing items, I will discuss with the owner of the overall design (often times that’s me) to come up with a solution. If a design language hasn’t been established, it’s time to get to work on establishing that across all products and features. At early stage startups, this often calls for logo and branding design. Not only do I enjoy doing this work, but being able to establish this with the product design so fresh on my mind helps me make sure the whole design system is consistent. Having a good design system is key to scaling a product and design team. As new features are created and new members join the team, they will all need to follow the rules that have been defined so that design stays consistent. I used to use Adobe Illustrator for this, but have found myself using Sketch more and more.
Once there is a solid foundation of wireframes and visual language, we can start to apply some UI. I’ve found that the styleguide and UI design go hand in hand. It helps to work on both at the same time. This way, you can start to define conventions as they come up in the real-world design. Once you define them, you should be able to apply them throughout any UI challenge you have. However, issues arise as you build out new features, so it’s sometimes necessary to update the styleguide to accommodate these changes. I’ve relied on Sketch the past few years for this. I think it’s a great tool because it’s focused and I’ve become super fast at using it (keyboard shortcuts and symbols are your friend).
I tend to solve interaction design problems while thinking through the UX and UI. I will often make a note in the wireframes to talk through a concept with a developer or product manager. Once we move to the visual design phase, I will mock up interaction features such as unique gestures and animations, using Quartz Composer, After Effects, or whatever the design tool-of-the-week is. I find that it really helps to explain a concept to someone once they see an example or can touch a live prototype.
This can happen as early as wireframing (low-fi) and as late as the visual design stage (high-fi). Again, when someone can see or tap something, they tend to understand it more than seeing something static. I think Invision is a great tool for this. It makes prototyping super easy and quick.
What people say and what they do are often two different things. If possible, I like to get concepts in front of real users as soon as possible. Being able to sit in a room with users is ideal. The next best thing, for me, is online user testing where I can watch users perform actions. If none of those are options, written feedback is better than nothing.
After a product or feature is launched, understanding usage patterns can be valuable. General demographic and usage data is important, but doing the work upfront to track specific usage metrics and usage patterns can tell us a lot about how users are using the product, but also how well the design is working.
This doesn’t happen at a specific point. I believe you should always get as much feedback at as many steps during the process as possible. I try to get key stakeholders, especially engineering, involved as early as possible. This way, flags can be raised and we can have a discussion as a team to figure out the best solution. You will rarely get everything right the first time. I’m a firm believer in testing your hypothesis, learning from what went wrong and right, and folding that back into future solutions.