The more time you spend within the actual graphic design tool designing, the less senior you are.

Designers are eager to open their graphic design tools whenever they start working on a new feature or project. You need to be able to kill that urge if you want to be successful. Opening up our design tools and designing immediately gives us tunnel vision, and you get stuck on the initial ideas that haven’t had a chance to benefit from the broader picture. 

Allowing time for discussion and a greater understanding can be challenging as can keeping a relative distance from the ideas that come to your mind. We hate spending time in what I call the “problem space,” as it is uncertain. But this uncertainty is necessary to discover new perspectives. A crucial aspect of being a senior designer is the ability to handle such uncertainty, and not jumping to conclusions helps you reduce your own biases. The more time we spend in this “gray zone” of not knowing the answers, yet using our tools to find them, the more chance we have to challenge and escape our biases. What we know or what we think we know is always biased.

A bit more about the gray zone

Our job as designers is to deal with and cope with uncertainty without forming conclusions too early. This is what the whole job is about, yet most of our problems come from avoiding uncertainty.

Spend more time on the problem.

The time teams spend researching a problem is underrated and undervalued. Our way of working is, unfortunately, too focused on solutions as opposed to taking enough time to observe the problems. This conundrum is not necessarily surprising, because our job is to deliver solutions. Since we work in a business that should be profitable, we need to deliver these solutions relatively quickly–the faster, the better for the business. Yet doing so should not lead to us losing sight of spending enough time to observe the problem. How often does it happen that we start to work and design a solution without knowing the entire problem we must solve thoroughly? Sometimes it is not even the product team’s fault when management and agile teams push the project forward.

We usually spend less than 10% of our solution delivery time investigating the problem we need to solve and 90% or more delivering an actual solution when the process should be reversed. Any designer can come up with the right solution to a problem when they have a complete grasp of every little nuance of the problem that needs to be solved.

Even though the two graphs above show the length of time you should spend focusing on the problem and delivering the solution, neither graph is completely accurate. The truth: This process is never linear. If it is linear, it is the old waterfall way–a linear, sequential approach to the product development–of designing and delivering. Later in the book, I will write about how messy and non-linear this process could be. For now, please see the graph below, which shows the ideal way of delivering a solution to a problem from the design perspective.

This problem is even more accurate when we work for a B2B business. A simple scenario: we have a B2B business and a client. The client, a main client for our business, has a feature request they think they need. The contract renewal date is coming up, so we start to work on implementing the client’s requested feature to keep them happy. We use our tools and methods to determine the most user-friendly way to implement the function. We do prototype testing and validate the design. What we don’t do is validate the actual client need and the root problem. We miss asking questions, such as: Is this what the client needs? Is this a problem to solve? Although we end up having a validated, user-friendly solution, it does not solve a problem or does not solve the right problem.

Accurate and helpful research validates and investigates the actual need—and goes beyond usability testing and validating any existing ideas and solutions. It is not just providing the most smooth and easy way for users to complete tasks. Check to ensure that the user is completing the task and determine their reason for doing so. If they complete the task, find out why and their reason for doing so.  

Evaluating our effectiveness

Most teams have a problem with evaluating their solution. When we don’t fully understand the problem we must solve, we find that our productivity is compromised. We don’t know how to check the outcome properly or how to measure our work. We sometimes don’t even self-reflect; we just rush to continue coming up with solutions to the next problem we try to solve.

Ninety-five percent of evaluating effectiveness in the current process focuses on verifying whether agile teams have delivered the features they promised. Only 5% of the evaluation examines the quality of what’s been delivered. However, it should be the other way around.

In other words, when we complete sprints, the central question that agile teams ask themselves is: "Have we delivered all the promised features?" This is a quantitative question, but the real question to ask is: "What is the quality of the features we delivered?" This question is qualitative in nature. Using a qualitative evaluation makes sure that we create value for our customers. 

Tweaking the mocks  

Another thing designers do is spend days, sometimes weeks, perfecting the auto-layouts, nesting every design component into components, and building out complex perfect prototypes. Some of these designs are so complex that even other designers–the ones that were not the creators–can’t understand what is happening due to the complexity. If design files are appropriately structured, it is probably fine. So much time is wasted on these actions. Meanwhile, the discovery phase sometimes just involves a kickoff meeting and sending out a survey when more is actually needed.

Refining your prototype and design files to the level of perfection and depth I outlined above is a waste of time, because most developers don’t care too much about file structure. They are right not to. Why would they care about complex auto layout settings, variant values, and perfectly polished prototypes? You also need to consider how our processes are changing. Maybe now we use a dedicated industry-standard tool to design, but what if it changes? To test an interactive prototype, high levels of perfection aren’t necessary to create good work. The only people you might impress with this perfection are other designers. 

A tool is just a tool.

Don't get me wrong. I like to play around with design tools. I can spend hours creating complex design files with multiple levels of components and variants. I enjoy doing this. But, at the end of the day, all you need is a file that is easy to modify and well-structured enough that if another colleague needs to work on it, it will be understandable.  

Just enough design, but creating the right design

On social media, designers engaged in an ongoing debate about whether one should properly name the layers within the graphic design tool they use. The debate escalated quickly, with some even claiming that failure to name and group your layers would result in getting fired. While I agree with the importance of organizing graphic design files correctly, failing to do so makes collaborating with other designers extremely difficult. However, I am curious how much time the person in question actually spends conducting extensive research on their projects. While they may do an excellent job with research, in my experience, the bigger problem lies in projects lacking quality research, which can have significantly more severe consequences than not properly naming layers within a graphic design file.

True design happens when the graphic design tool we use moves aside, enabling people to talk and collaborate. Leaving the safety of your design tool and starting to investigate what really matters can be rewarding. As I’ve become more senior, I’ve spent less time with the actual design tool I use for designing. I’m not saying you should not create a proper design and prototype and well-structured design files. I’m just saying that you shouldn’t spend more time on it than necessary. Make your design files just as sophisticated as they are easy to handle. Every hour you spend alone with these extra nuances alienates you from spending time with actual people collaborating and solving problems that matter.