There are a lot of theories of what design is. One definition from Merriam-Webster says that design is the action “to create, fashion, execute, or construct according to plan”. Sure, when you are designing you may create something or fashion something. You may execute a plan, or construct a plan. One famous designer, Paul Rand–perhaps you’ve heard of him, supposedly said that “the public is more familiar with bad design than good design.” So, now design is a thing, and not an action. I suppose that in the right light, it can be a thing. So, I offer one more concept. Design has a purpose. Design is for problem solving.
You will likely have your own theories of what design’s purpose is, and I’m certain that I’m not the only one to come to terms with the term design. I’m certain that I’m not the only to suggest that the purpose of design is to solve a problem. Think about it. Every single thing that has ever been invented has been aimed at solving some problem. The wheel was clearly invented for the eventual purpose of creating skateboards right? The problem was that teenagers were complaining about having to walk places, and so the design came to solve the problem.
This article was written with an assumption that you have already done your up-front research. While it’s true that there are a lot of resources out there that talk about research, I hope that you consider first reading my thoughts at a high level glance on research. Check out Research first, design later.
Problem Solving with design: Creating a report
I’ve seen a few different situations where design solved a problem. One situation was when I worked on a development team at Costco. I was an RPGIV programmer. Our team usually only dealt with fixing little bugs, but one day my manager asked me to write a program that gathered a bunch of confidential payroll information to be used for stock option reporting. It was a big deal for me, and a rare opportunity for the team. That design problem needed a solution.
Solving the problem of information strategy
Leading up to actually writing the code, I met with the business. They suggested I go around and talk with some of the different stakeholders to make sure I had a good grasp of what was required for the project. I learned of various different bits of information that needed to be included in the final product. I learned of what types of information might be grouped together, and how that information might be best presented. For example, placing the phone number between the first and the last name could make the information quite difficult for someone to work with later.
There is value in having a good information grouping strategy. As a User Experience designer, I’ve come to know that this information grouping strategy is most commonly known as the information architecture. It’s the foundation for the final visual product. It doesn’t matter how pretty a design is if information is not presented in a way that makes sense to the users of the information. This information grouping strategy can determine which pages appear on a website, what navigation options there are in a mobile application, or how well a person will be able to follow your assembly instructions.
Pseudo code: the cheapest medium
I read about pseudo code in my RPG IV training book. The idea of pseudo code was that instead of writing code, I’d write (on paper) a high level outline of the processing needed to get the job done. This worked for the information grouping strategy for the application I needed to build, and it worked for the processing of the application. Lines like “loop through each record, get name, department, salary, and hire date” were all I needed to conceptualize the problem and different solution possibilities. Simple words. I could move quick. Change it. Rework and test again and again in my mind. I didn’t have to think the logic through at a developer detail level–just high level. I learned with this exercise that early in the design process, you want to start with the cheapest medium.
Interface designers have been teaching the concept of solving the problem in a cheap, visual way for years. When I started doing UX work, I drew on my knowledge of pseudo code when I started learning about wire-framing and visual design. In fact, one of the first books I read as a UX Designer was “The back of the napkin” by Dan Roam. Just to restate, he was helping folks learn to solve business problems through sketching. Sketching is, after all a cheap way to rapidly iterate through many different ideas. They can be immediately tested with yourself, or others, then adjusted. Again and again until you’ve landed on something that looks right. Just like pseudo code from my development days.
Cheap to expensive problem solving
With sketching on paper or whiteboard is cheap. Creating wireframes is becoming quicker as technologies change, but it’s still more expensive than sketching. With each step towards a final product though, the cost and time needed increases. Simulations are a next step from wireframes. The business usually loves these because they can finally see what the solution to their problem might be. Test simulations with real users in order to save time by preventing rework. Wireframes often are converted to high resolution visual designs of different shapes, each taking a new degree of skill from the designer. Pushing pixels, selecting color palettes, and taxonomy can be pretty involved. With every step closer to development, the cost of solving the problem goes up. Finally, the development process and all that goes with that is the most expensive part for companies.
Problem solving is design’s purpose. That’s what it does. It may be an activity involving several steps, or a thing as in the final product. But the most important concept to understand is that design’s purpose is to solve a problem. The best design is the one that meets the user’s expectations for the design, and at the same time solves the problem or problems. Go cheapest up to the minimal level that development needs to get the job done. Good luck! Happy designing. 🙂 ~ Lucas