Let’s talk a little bit about my design process. While I always strive to create pixel-perfect visuals, I’m equally concerned with creating logical designs that people can actually use. Coming from a business background, I try to consider all of the factors that can affect a design, and use logic — rather than personal preference — to validate design decisions. I then user-test my designs to validate my decisions.
Figma is my tool of choice when it comes to designing responsive websites and mobile apps, but I’m comfortable using XD and Sketch as well. For most of my projects I’ll create a clickable prototype with all of my screens in order to simulate the product’s behavior. When it’s all done, I’ll hand off my designs to developers using Zeplin and include any additional documentation. As a designer, I believe I possess two strengths in particular that help me create simple, unified designs: I am able to immerse myself in new topics that I am able to learn and apply quickly, and I empathize with busy users to understand the complete scope of their needs. With everything I do, I try to follow my own principles of good design: relevance, simplicity, and unity.
I consider myself somewhat of a power user and am always looking for new ways to automate my workflow. You can read more about some of the extensions, plugins and resources that I use to do that here.
I’m a pretty structured thinker, so whether it’s a website redesign or building an app from the ground up I’m always trying to understand the nature of the problem we need to solve before jumping into designing solutions.
For me, it’s about asking the right questions, including but not limited to: What is the primary business goal of this project? What metrics or other methods are we using to define success? What are the ‘must-haves’ — followed by the ‘nice-to-haves’?
I get it — design can be messy; but for me it’s important to create order out of chaos. That’s why although I may not always follow this process in a linear sequence, the steps below are always in the back of my mind when I’m working on a project:
Understanding what the business goals are helps me understand why the product should exist. Does the business compete based on differentiation or cost? What are our competitors doing? What constraints do we face (human capital, financial, time)? What KPIs are we using to define success? At this stage of the process it’s critical to get stakeholder alignment to avoid any mishaps later on.
What are people struggling to accomplish? How can we help them achieve their goals? What is the context in which they will be using the product? What’s their story? It’s all about understanding the target audience.
Taking all of the qualitative and quantitative user research data that was gathered, look for patterns and create personas that reflect each user group we are designing for. It’s also important to understand the context in which someone is accessing the website or mobile app in order to define more accurate user scenarios.
This step is all about investigating multiple solutions. Sketch a bunch of different design options that take into account user needs as well as business requirements. Top of mind, the focus is on empowering the user to accomplish their goal in the most efficient, effective and delightful manner as possible, keeping in mind the business objectives. Before proceeding, I like to hold working sessions with colleagues and stakeholders in order to solicit feedback and confirm the overall direction.
I’m pretty quick at digital prototyping, so most of the time I’ll use software to create something that can be tested with users rather than a paper prototype. I’ll be honest though, sometimes I’ll jump straight into high-fidelity designs. The reason why is that based on my experiences, people don’t understand low fidelity. Even when I preface it by saying that “I am showing you wireframes as a way to present the layout alone, not focus on the colors or images”; still, people seem to have a hard time getting past the wireframe concept — especially when they were expecting to see full-color layouts. I get it though; we’re visual beings at the end of the day.
Even though this is a single step in my process, I don’t look at testing as a one-and-done event. It’s something that should continually occur in order to save money and time — and reduce the risk of users rejecting the end product. I look at testing as a two-fold process: First, I like to test with internal stakeholders to make sure I get their approval. Then, I like to meet with 3-5 users from our defined target audience to conduct formative research that allows us to understand what is and isn’t working, and optimize our designs as a result.
Prioritize. Prioritize. Prioritize. Understand that you can’t please everyone. Based on the feedback you receive, it’s important to rank what needs to be refined and then go to work in that order. Then, test it. Refine it. Test it again. Okay, you get what I’m saying. The goal here should be to align with the user’s mental model as much as possible.
Create your final prototype, prepare any assets and relevant documentation that the development team will need. There shouldn’t be any surprises or major roadblocks here because ideally the development team has been involved in the design process from the start and made you aware of any obstacles early enough.
Did you solve the problem you set out to solve? Were the business objectives achieved? Now it’s important to monitor and track analytics in order to determine how users are using the product and identify any areas of improvement or potentially any new product offerings.
While it’s our job to know our services, website and/or app inside and out, our users are just trying to get things done using our product. So instead of thinking we know everything about our user, we should really be focused on learning as much as we can about them. One thing we can do is give them multiple opportunities to accomplish their task. It’s all about empowering them to choose and making different parts of their experience enjoyable.
Long story short — I’m pretty adept at knowing when to pull the plug. Having been a part of a few startups, I know that it’s easy to continue pouring time and resources into an idea/endeavour because you’ve become attached to it over time, but sometimes you have to accept it as a failure and move on. When you win, you win. When you lose, you learn.
Style Guides, Design Systems, Grids, Brand Guidelines — these aren’t just buzzwords; they’re effective systems that allow you to scale your designs quicker and build trust among your users. People like familiarity, and consistency is the key to great design. I also believe that placement should be intentional, and that every design decision can be justified.
Simple design occurs as a result of continuous distilling — removing the unnecessary, until only the bare essentials remain. In my opinion, to achieve simplicity users should be able to understand my designs the first time they experience them — every time. Simplicity occurs in the way we demystify problems and in our ability to communicate a complicated concept so that it is easily understood.
My goal isn’t to create one-size-fits-all experiences. I understand that each and every individual is unique and our needs are different, so it’s important to be thoughtful about what, to whom, and in what context we present information.
Coherence helps build familiarity and trust. This means designs should follow the system already in place. Reuse rather than reinvent. Good experiences should be scalable and be able to manifest themselves across different environments — whether it’s an app, website, or across the real world.