How do you solve problems? Do you wing it? Do you follow a similar process to solve most problems you encounter? Do you simply try a few things that have worked in the past?
Recently I came across an article on the Treehouse blog by Pasan Premaratne, titled Help, I’m Stuck with some tips to specifically solve programming problems. It made me think about problem solving in general and I wanted to share a little of my problem solving process.
Whether you realize it or not, you probably go through a process for solving problems. Odds are the problems you face are similar and without thinking you just dive in and attempt to solve them the same way you did the time before and the time before that.
Before you can solve a problem, you need to know what the real problem is
Naturally it depends on the type of problem. If you’re asked to add 2 + 2, I trust you know the answer instantly and don’t have to do much beyond giving it. On the other hand if you’re asked to solve 365 × (42 + 17) / 7 × 4 you might be reaching for some version of a calculator.
When I face a design problem, one in the development of a site, or any technical problem in front of me, I’ve noticed I go through a similar process to solve it. In fact I tend to follow this process for most any problem that confronts me in life. Depending on the problem I may not need to go through all the steps and other than the first step, may go through these in a different order.
- Identify and refine the problem
- Search for a solution
- Seek and read documentation
- Trial and error
- Ask someone else
- Weigh the alternatives
Identify and Refine the Problem
If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.
— Albert Einstein
Before you can solve a problem, you need to know what the real problem is. When we notice a problem, what we typically see is a symptom of the problem and not necessarily its root cause.
The first thing I do to solve a problem is work to identify what the problem really is. Let’s say you’re just starting out on the design of a site. The client paid you a deposit and you’re ready to work. What problem are you trying to solve?
The desire for a website is a symptom. The problem is really that the client wants to build an online presence or wants to sell widget x to customer y. The first thing you have to do is identify what the client really wants. You need to dig as deep as you can to discover the root problem the site you’re building is trying to solve.
There are a variety of ways to identify the root of the problem. I find asking questions is a good start. So is eliminating possibilities. For example if I can’t load this site in a browser I:
- Try to load another of my sites from the same server
- Try to load a site likely to be working, usually Google
- Try loading the down site in a different browser
- Try to connect to devices on my internal network
Depending on what happens ,each of the above eliminates a possible cause of the problem and points me to a different solution. The idea is to eliminate what isn’t the problem to find what it is.
Search for a Solution
Once I have a handle on what the problem might be, I start searching for an answer. Google, Bing, Yahoo, or your favorite search engine is your friend. Odds are someone has had the same or similar problem and a few searches will lead you to possible solutions to try.
You can search for error messages in code or write a query describing the error you’re getting. You can search for sites similar to the one you’re designing to see how other designers solved similar problems.
Much of the time your first search or two won’t lead you to a solution and you’ll need to refine your search. One of the best skills you can develop as a problem solver is learning to search better. Barring a specific error message, my early queries are often toward the vaguer side.
I’ll type my general query and click on some results if only to pick up some of the vocabulary I should be using in future queries. Even if the search results don’t appear promising, it’s a good idea to click through on some and at least scan their content to help you refine your searching. As you refine your queries you’re also refining the problem definition.
If after a time your favorite search engine isn’t leading you to a solution, you can try forums, Q&A sites, and similar. You can go to any sites you know and search them directly.
Read Documentation and Source Code
If search isn’t leading anywhere, I’ll seek out documentation that might be available. Ideally good documentation exists, but that’s not always the case. If the problem is a development issue, you can go directly to the source code and try to understand what’s going on.
For design problems I may consult books here on my shelf. I may open some up for ideas about color or type. I might consult one to better understand certain principles that can lead to a solution.
Documentation is really just another place to continue searching. It’s not always as easy to search though, which is why I usually start with search engines and sites I’m familiar with.
Trial and Error
At some point you have to do and assuming you haven’t found an exact solution to apply, trial and error is your next step. Searching may not have led to the answer you were seeking, but if done well it should at least have helped you understand the problem better and given you some ideas where a solution lies.
Sometimes you have to try a few things and just see what happens. Make changes that isolate whatever it is you’re changing. If you make too many changes at once you might get lucky and fix what was broken, but you probably won’t know why and you’re likely to make the original mistake in the future.
If you keep isolating different things to try, you’ll continue to refine the problem and solution. It’s really what I was doing above when trying to figure out why might site wouldn’t load. I tried different things to isolate a potential problem. Now it’s about trying to isolate possible solutions.
Ask Someone Else
As a last resort you can ask someone else. Sometimes no matter how hard we try, a solution eludes us. We may not have the requisite skills needed or we may become so locked into specific paths to a solution that we can’t see anything else.
When I suggest this as a last resort, I do mean as a last resort. Trying to solve the problem yourself can be frustrating and time consuming, but you’ll be better in the long run for having tried.
Weigh the Alternatives
Some problems like 2 + 2 seek absolute answers. There’s a single answer to the problem and your goal is to find that answer. Other problems, especially design problems and to some degree development problems, will have multiple solutions that work.
When a problem offers more than one solution you have to decide, which solution to use, which is its own problem with its own solution. In this case everything above should have left you with a few options from which to choose. It’s now up to you to make a choice.
You aren’t looking for the right solution, but the best solution, and there’s little way to know if you’ve found the best solution until sometime after you’ve implemented it. Weigh the pros and cons of each possibility and use your experience to make a choice.
Spend less time worrying about whether it’s the right choice and more time observing the effects of your choice so you can do better the next time.
Learning through Problem Solving
Some want to skip directly to the ask someone else part of the process above. I can understand why. It’s easier. You ask and let another person work on a solution while you go off and do something else. If that’s your approach, expect to have the problem again and not know how to solve it.
Asking someone else is accepting the gift of a fish. Trying to solve the problem yourself is learning how to fish. It’s an exercise in critical thinking.
The struggle to identify and refine the problem, to search for an answer, and to try different possibilities, contains many teaching and learning opportunities and in the long run will save you considerable time. If you’re facing a deadline, just get the problem solved, but when you can, put in the effort to get something more.
If you found code online to solve your problem, spend time understanding what it does and why it works. Figure out how to modify it so it does something a little different. Can you remove parts of the code that have nothing to do with your specific problem?
When defining problems seek the root cause always. Then refine more to see if something deeper is at work. Remember the problem you see is usually a symptom of some deeper problem.
Don’t stop at solving the symptoms. You might be able to hack together some magic numbers in your css to make a layout work on your screen, but the layout will probably break elsewhere or you’ll develop another site with a similar issue. Dig deeper to discover if your general approach to layouts is the real cause and if there’s a better approach you can follow.
Look for patterns in every problem you come across. What similarities exist between the current problem and others you’ve come across in the past? Teach yourself to observe patterns across problems. It’s part of identifying and refining the root cause and the closer to the root problem you can solve, the more future problems you’ll be able to solve quickly and easily.
To help in pattern recognition you can record the problems you encounter, the root causes you think are at play, the solutions you’ve tried, those that worked, and any observations you’ve made along the way. Keep observing even after you’ve solved a problem. Expand and refine the patterns you see.
If your first step in solving a problem is to ask someone else or if you copy and paste the first potential solution you find, you miss out on many of the benefits of problem solving. You may fix your problem, but you won’t have learned anything. You’ll be reliant on others to solve the same problem and you’ll miss out on the opportunity to solves a wider range of problems and become a better problem solver in general.
Put in the time and effort to solve it on your own first. Start by identifying and refining the problem and seeking the root cause. Observe patterns in the different problems you encounter.
Once you have a reasonable idea of the problem search for a solution. Try search engines, forums, Q&A sites, documentation, and source code. Search anything you think might contain an answer. After searching give trial and error a shot.
When deadlines are present it’s ok to find something workable as quickly as possible, but for all other times take the longer road. There’s a lot to learn along the way to a solution.
If you liked this post, consider buying my book Design Fundamentals