How to untangle design dilemmas
🗓 15th October, 2019
When designing products, our thought process can sometimes feel similar to a driver encountering road blocks and taking detours to reach the desired destination. As we're designing, we pass through countless dilemmas which crop up and get in the way of us reaching our intended outcome.
The space between our starting point and the desired outcome is what design is all about. As we design, detours may be exploratory directions or decisions we make which do not move us closer to the desired outcome in the most intentional and efficient way. This may happen for a number of reasons such as having strong opinions on what to execute, making irrelevant explorations for wrong reasons or simply getting tangled with design dilemmas which throw us off our path.
Before moving forward I'd like to clarify that design is indeed an iterative process which involves a high degree of back and forth and ample exploration too. However there is such a thing as iterating responsibly so that each round of iteration is an overall step forward in the right direction. Bad iteration on the other hand is directionless and often times a result of bad framing of a problem. When this is the case, it can lead to solutions to problems which don't exist or aren't in scope.
Here's how I like to depict bad iteration and good iteration side by side; Bad iteration looks like a mess of spaghetti and good iteration looks like an upward spiral.
The process of great iteration is facilitated by asking better questions and being more analytical. In doing so we may begin to avoid the unnecessary detours and start driving in the efficient routes that help us reach our goal with clarity, intention and efficiency.
This article is a distilled list of questions I ask myself or others when situations need some untangling.
What problem am I trying to solve?
May sound like an obvious question but can very easily be overlooked especially after spending some time on a project and becoming a victim of tunnel vision.
When you are working aimlessly you may also expect to work endlessly as it becomes increasingly difficult to know when you’ve reached the proverbial ‘finish line’.
Before searching for inspiration on other products or sketching ideas, it’s worth framing the problem carefully in order to gain clarity. There are two main ways to do this. You may write a Job story or a ‘How might we’ statement, both will provide different value so I suggest practicing both until you become familiar with each method and learn how to use them correctly.
A job story helps you to think about a situation, task at hand and intention, it has the following structure:
When ____ I want to ____ so I can ____
Example: When I have an appointment, I want to write it somewhere so I can remember it.
A ‘How might we’ statement (also known as HMW) doesn’t begin with the customer but forces you to specify a problem you’re trying to solve instead. A How might we statement has the following structure:
How might we____?
Example: How might we help people when they’re having difficulty logging into their account?
Both approaches will help you narrow down the problem to what really matters and provide clarity. After doing this you’ll notice that some options you may have been considering were never options in the first place.
What’s more consistent with the product I’m designing for?
We’ve all been in situations were we explored interesting alleys which stirred us away from being consistent with our product.
Aiming for what feels ideal is great, however there’s always a ripple effect on the product and team when designers introduce new ideas. Being consistent is about iterating within the boundaries that define your product, the intention should be to produce a new part of the product that fits in seamlessly.
Unless you are in the process of building a new design system, it’s worth observing what already exists in your system and in your live product as a first step. This way you can reuse styles and components which have already been thought out carefully and avoid getting tangled in a dilemma which already has a solution.
Unless it is absolutely necessary, there’s generaly little value in coming up with brand new ideas which already have solutions in functioning code. Such ideas may lead to unnecessary product bloat.
It’s tempting to tackle each design assignment in a bubble; however, understanding that you’re working on one part of a bigger picture will definitely help you put things in perspective.
When a challenge puts you on the spot with nothing to borrow from the current system in place, that’s an opportunity to enriched your system. Lastly, I wouldn’t suggest slowing innovation and overall improvement for the sake of being consistent with a system. Just be smart when deciding where to spend your time and avoid redoing things which are already done.
How have others solved this problem?
From time to time we face challenges that we haven’t faced before, either individually or as a team and wonder what the way forward should be. It may also be the case that there is nothing in our product to serve as a guide post or reference point.
In these scenarios it’s worth remembering that you may be about to solve a problem that other products have already solved and learning what worked for others may get you on the fast track.
There are two ways to use this method. You can research conventional recommendations or best practices for the platform you’re designing for such as web, iOS or Android. Secondly, you can research competing products and check how they’ve tackled the issue you’re facing.
People will use your product with expectations which they’ve gathered from elsewhere so it’s worth being aware of systems and solutions that people are already familiar with.
One pitfall of this method is the tendency to copy the competition blindly.
When copying from your competition, you’ll inevitably copy what works but also what doesn’t work. Copying should be a starting point which proceeds with some form of validation.
How would I measure success?
Sometimes design can get messy and this is especially true when what you’re designing effects multiple touch points, customer profiles and has many moving parts to top it all up.
In this scenario it’s easy to get paranoid about every micro decision you’re making and keep wondering about what decisions are sane and which are risky. This kind of paranoia may also leave you going back and forth on your decisions as you try figure out which trade offs to make.
One method that may help in this scenario is to stop and write down how you’d measure success after shipping. Doing this will shed light on what matters most and keep you focused in ambiguous situations.
Remember that anything which doesn’t move you closer to the desired outcome may be a waste of precious time so you might as well define what success looks like.
Whenever you find yourself in situations where you’re unsure what success criteria to choose, look for people in your organisation who understand the business, the customers and who also work with data frequently.
People with this combination of knowledge are usually your best bet as they objectively think about how to keep customers happy, the business more prosperous and how to keep track of things.
What’s more accessible?
Here’s another scenario that I’m sure many of you can empathise with; trying plenty of colour, typographic or alignment options and ending up more confused than enlightened. When a design challenge demands a moderate to high degree of understandability on a visual level, accessibility may be a good yardstick to measure against.
You may have your preferred solutions to problems however what doesn’t work for customers is simply not an option. If great design is accessible design, then you may use accessibility principals to weed out some of your options that provide a weak base.
When designing for accessibility always consider:
- Ensuring that your typography is sized appropriately to keep all copy legible.
- Arranging your design to feel ergonomic so that it may be accessed comfortably across devices.
- Network limitations that may compromise your design and make it inaccessible in restricted areas or developing countries.
- Avoiding drastic motion in your interactions especially if it’s not totally necessary.
- Avoid over relying on sound unless necessary to cater for people who have difficulty in hearing.
- Choosing colours which are more accessible to people who are visually impaired.
This list may go on and I’d definitely recommend you dig into this subject further.
How would this scale across breakpoints and platforms?
Before going into too many layers of polish on a design direction, exploring how your direction would scale across break points and platforms is highly advisable. The danger of not doing this is that you may have what appears to be a great solution which in actual fact will not translate across the board.
Here are a couple of things to keep consistent across breakpoints and platforms:
Journeys
There’s usually a logical way for people to navigate through products and once you’ve found out what works, you may want to stick to that across platforms. I’m keeping away from using the word ‘flows’ because you may require minor flow differences which result from platform conventions.
Copy
Avoid throwing in additional copy on desktop because there’s space or hacking it down on mobile because there’s a lack of it. Figure out what content accurately describes your message in an understandable way and design around that. Remember that content serves to communicate not to fill space.
Here are a couple of things you may need to change across breakpoints and platforms:
Interaction models
There’s a difference between interacting with a finger on a touch screen and using a mouse and keyboard. If your product is intended to be accessed on the web especially, you’d need to factor in that people may access the web on their phone, tablet or computer and these devices offer different methods of interacting. This inevitably means that you’d need to design solutions for touch screens and solutions that will work with a keyboard and mouse as input methods.
Native patterns
If your product will be available on a native platform such as iOS or Android, you’d need to be aware or the native framework guidelines in order to ensure that your design meets the platform’s criteria. The good news here is that you’ll also find a library of native components that are readily available. Moreover you can be certain that if implemented properly, customers will feel highly familiar with them too.
Making sure your design scales will ensure that your experience is delivered gracefully to your entire audience with no customers being punished for having specific platform preferences.
Can people use this?
When you’ve followed through with research, design heuristics, received feedback from colleagues and still feel some degree of uncertainty, user testing is one sure way to get untangled. User testing can help you fish for the most prominent problems that people will instantly encounter with your product if you were to ship it.
User testing is a qualitative research methodology you may use to measure understandability and usability primarily. This method is not the correct method to gauge whether an idea will be well received at scale as the sample size required for this methodology is simply not representative of the entire market you may be addressing. Another way to put this is to say that this method is statistically insignificant.
Use this method for quality input and find out if your solutions are understandable and usable.
Here are just a few good reasons to use this methodology:
- To check whether people can accomplish what they need to with your product or not.
- To watch where people struggle with your product and find out why they do.
- To understand which parts of your product work well and shouldn’t be touched for now.
- To gauge how understandable your copy is.
- To receive feedback on what could be improved from a user’s point of view.
Final takeaway
Making better design decisions may be practiced and improved like any other skill. The danger of not practicing decision making is letting the quality of your decisions become subject to factors such as mood, energy levels or influence from others.
Design in it’s simplest definition means ‘to do with intent’ and making sound decisions for the right reasons promotes designing with intent. In summary, here’s a list of questions that can help you get untangled:
- What problem am I trying to solve?
- What’s more consistent with the product I’m designing for?
- How have other’s solved this problem?
- How would I measure success?
- What’s more accessible?
- How would this scale across breakpoints and platforms?
- Can people use this?
