I honestly don’t really like talking about it. Never have. So why talk about it now? I’ve always felt that I’ve done things a little differently than other designers and none of the articles I’ve read on process really get at the way I tend to approach problem solving. Especially since my job right now is not necessarily for a product-driven environment, writing about this also perhaps gives people a glimpse into some different ways of thinking (maybe?) about how to go from idea to mockup.
Using the Wrong Process
Far too often it seems people spend way too much energy looking for easy answers. What’s the magic bullet that will solve our problems with the least possible effort? It’s the tech industry’s fascination with the idea of “low-hanging fruit”. The “low-hanging fruit” solution then becomes a battle to get churn rates down so that you can actually keep your customers. So why do people spend so much time trying to optimize everything in the company towards solving only the most shallow parts of the problem?
Then there’s the problem of defining a process altogether. People want a tried and true method to success. There’s no time to play around with different ways of working, and there’s already so much literature out there about how to get things done. Just “lean” your way to success. Use enough sticky notes and it will happen!
So let’s start with the first assumption: There are no easy answers and there is no perfect process. Design Thinking™ seems to be the big buzzword these days but even then, there’s some that say design thinking is bullshit. Having done the sticky note thing before, I personally wouldn’t go as far as to say it’s bullshit, but there are lots of different things you can do besides that stuff that can also add value to what you’re doing. It’s important to keep in mind that there’s more than one way to do something. In the end, a good process will help you discover what’s important so that you can make the right kinds of improvements to your work.
The 3 Pillars
So if it’s not “Design Thinking”, then what do we do? As a designer, I like to simplify stuff, and so I base my process on these 3 simple questions: Why? — What? — How?
In order for any design project to have any chance at success, these 3 things must be established as part of the process. The best way to deal with these is to define them in this order (Why to What to How). But what are these things? And why are they so important?
The Why
Have you ever seen a poster or interacted with a website and thought, “huh, that’s cool”, but then it sort of felt hollow? Like there wasn’t much behind it? Sometimes, design can be like that, just an aesthetic experience. But sometimes, when it feels rather shallow, it might be because they didn’t define The Why. Every piece of design needs a reason for its existence, a rationale for what it’s all about. The Why is your rationale. We talked about The Why on the podcast, so it would be cool if you listened to it if you haven’t yet. We covered a lot of stuff about it in that show.
You need to define The Why so that it can come across in the design. Without it, people won’t know why the poster, or the product, or whatever, exists, why they need it. If they don’t know why they need it, your design, your poster, your whatever, will have effectively failed.
The What
Once you’ve figured out Why, you next need to know What. These are all the mission critical things that your design will need. What is the idea? What are the goals of the project? What is the budget? What are the dimensions of the final product? What colors will there be? What typeface will you use? What technology is needed? It’s basically your design from a high level.
You need to define The What because before getting too far into the details, it’s important to know some basic things about what you’re going to do. You can burn a lot of time otherwise.
The How
Once you know why you’re doing what you’re doing, what are you about to do, you then need to define The How. These are now all the details about how it works. How many steps to get through the checkout process? How big is the icon? How much does it cost to sign up? How will someone contact us if there’s a problem?
You need to define The How as the last step because it needs to carry out all the stuff you discovered in the earlier steps. If there’s nothing coming out of those earlier steps (like, if you skipped them), it’s very easy to spend a lot of time making something that doesn’t achieve any goals. It’s possible to get lucky, but man, why waste time hoping for luck?
Ok, I sort of get all that, but how do I do this?
Now that we’re on the same page, let’s go over how to pull all this together into a way of working.
In the past, whenever people have asked me about how to get started on a project (especially sizable ones with lots of complexity), my answer is basically to just begin at the beginning. It’s tempting to jump in and start making mockups, but it’s important to resist that temptation unless you have enough background information to move directly into a production process.
Starting with Why
To begin a project, I always try to start with defining The Why. It is important to know where the boundaries of a project are, and The Why helps you know where they are. But how do you define it? The simple answer here is research, but what do you research and for how long?
People, Products, Technology
I start with what I don’t know. What questions do I have about things? What do I need to understand in order to make something a success? Especially in the beginning, there’s a lot of things to learn. So where do you begin? Typically I start the discovery process by learning about the end user.
Start with interviews. Ask open-ended questions to get them to talk about themselves. Learn what words they use. Find out what motivates them. What keeps them up at night? What helps them rest easy? Eventually, if you ask good questions, you will be able to identify the kinds of problems that you will have to solve. You can also start working with the customer service team. Become very good friends with them, because they will have a lot of specific knowledge about what sort of issues have been reported to the company.
There may also be competitors already in the space. Who are they? What are their current product offerings? How well do they fit the needs of the customers you’re targeting? When thinking about designs, I might need to spend time learning more about the competitive landscape that a company operates in.
If it’s not a redesign of something existing, then this is where you also need to start figuring out what requirements there are for the product. I do this by talking with the end users as described earlier. I would ask about how the products they use today help them in their lives. What did they wish those products did better? What aspects of those products are the absolute essentials? What do I need to know to feel more confident acting on behalf of the customer? We can use that information to help define the requirements for a successful design.
The goal at this point is to just understand. Learn about the product so that you can make better choices, and figure out what opportunities you have to develop something new.
In the end, all this research will lead to developing a goal for the project. The goal should explain what you want to accomplish and why. This is the rationale for the design work that will come next. I conclude this research phase by writing down the goal and sharing it with other people I work with. Getting agreement and buy-in at this stage is an important first step!
Leading with What
After doing some amount of research, that’s when I move on to start defining high level designs. I start with interaction models and high level principles. What is valuable about the end result? What should the design accomplish? What should the company expect in return? Wireframes are one of the deliverables but before that I usually spend more time writing.
We talked about writing on the podcast. Being able to write is definitely an important skill (effective UI text is critical for good products) but more importantly, I find that it helps crystallize the vague ideas I have in my head while trying to synthesize rather findings from research. Writing is one of the basic forms of human communication and I’ve found that being able to express ideas with the written word helps me think clearly about a design.
Sketches and wireframes come next. If, after writing, you’ve arrived at a point where some idea starts brewing, then definitely start sketching it out. For me, it’s often a lot of back and forth between these 2 activities. But at some point, the idea solidifies and it becomes more about how I execute it in a wireframe. When wireframing, I try not to get too hung up on the minutiae. Of course if it’s a detail that helps communicate the idea, then by all means include it. But focusing on too many details when wireframing will just drag the process down. Design is most definitely in the details, but fewer details at this stage means you can cover more ground in terms of different design concepts.
What constitutes a wireframe though? I think there’s a lot of different ways of doing this, but for me, it’s a question of graphical fidelity. I always start designing with incredibly low fidelity, “style-less” wireframes.
In addition to wireframes, you may need to also map things out into a flow, so that you know what to design for what purpose.
Site maps, information architecture, journey maps, user flows, these things go by many names. Quite frankly, who cares what they’re called. Just map it out to visualize how all the screens work together. Then usually what I do after that is try to chop it down as much as possible. Logistically, sometimes things turn out to be like a 5 or 7 screen multi-step process. Depending on what it is, going through a 7-step process may not be the best thing for the user, so I try to look for opportunities to condense and consolidate pages so that maybe you can take a 7-step flow and make it a 3-step flow.
And it’s not that you do this arbitrarily, the point is that it should still make sense! Be logical while requiring fewer interactions.
One last thing on maps. I also use them to see what screens or pages can be made consistent! When you map things into a flow, you get to see the whole system from a high level. This bird’s eye view of a whole product can sometime make it evident where screens can be reused. Anything that can be reused, be it a whole screen or just a widget, will help things get built faster (since there’s less code to deal with) and help the user have an easier time with things (since it’s probably something they’ve seen before).
One thing I did not want to leave out is prototypes. I like to do low fidelity prototyping during this part of the process, both for myself and even to do usability tests. Through prototypes, I get to see for the very first time how an interaction can feel like, and if it doesn’t make sense at this stage, it definitely won’t make sense when you layer on all the visual polish!
But even for testing with actual end users. As long as you “prime the pump” in the right way and get them to recognize that they’re not seeing a finished product, you can actually learn quite a lot from an early prototype and spare yourself and your coworkers from a lot of back and forth later on.
One problem that I’ve often encountered is that whenever you say the word “prototype” people start thinking about how to build something exactly as it should be in the final outcome, which is then usually followed up with complaints about timelines and/or inefficiencies. First of all, what I’m talking about is doing lightweight prototyping — Keynote, PowerPoint, basic HTML, Flinto, whatever. No special engineering resources required. I take my wireframes and make something from them so that I can start experiencing how it will work. These things are intended to be thrown away at some point, but not before I’ve used them to learn. So it’s important to not put too much emphasis on getting everything exactly right at this stage.
It’s a common myth of prototyping that you have to build something faithfully, in a precise simulation, in order to get anything useful out of it. I suppose if you only cared about quantitative analysis then you might be right. But at this point in the process, quantitative analysis is a bigger waste of time than making throwaway prototypes. So why worry about it? I find it’s more important to start answering a lot of the big questions from your research at this stage, and it’s the qualitative answers that help me get there. Using low fidelity, lightweight prototypes are the way I do it!
Defining How
So now we can finally talk about what people outside the design field consider to be design — the How. The How is the most visible part of the process, and as a result, it’s the part that everyone has an armchair quarterback’s opinion about.
*sigh*
Anyway, useless feedback aside, the visual design part is where everything comes together.
Visual concepts
A lot of what I’ve written about is more about interaction and experience, but the same kind of process works for visual explorations as well. Good visual design requires a lot of research and I always try to put some time into exploring different ways of representing ideas in a visual way.
The thing that I find that makes visual exploration really difficult is that at some point, I latch onto an idea very strongly and it’s very difficult to really create more options that can help people make a decision. It’s not that I necessarily show all the options I’ve come up with, but sometimes, getting some feedback on more than one idea can help clarify what might be more helpful.
Something to consider is, although it’s important to consider the end user in what you do, you’re also creating a body of work which is represented in your portfolio. Hopefully, like Josef Müller-Brockmann (see above) you will leave a great legacy of wonderful work.
Developing a visual concept is hard work. You can’t just do 43 minutes of work and expect it all to come together. I explore images from all over the place to help provide a visual reference for the types of things that I would do graphically. It’s important to pull that stuff together to help identify visual themes that can convey the visual concepts you’re interested in. Additionally, I like to look through competing products for how they present similar ideas, and try to identify opportunities to create something unique and different. Color palettes and typestyles all factor into the decisions. But where you ultimately need to end up is with something that someone can take and start implementing. Style guides and assets are the usual resulting deliverables.
At a bare minimum, I try to explain what core things are necessary for the design to work well, and make sure that those things get implemented first. Some of the details, with regards to spacing and type sizes and what not, can come later. Not to say that those details aren’t important, because they really are! But there’s a way to structure an implementation process with the way the software teams work such that they have time to help get all the details right!
Let’s bring up prototyping again. At this stage, you have all the items necessary to start executing a user experience product. I like to take those early builds and put them into usability tests again (when they’re robust enough). The cool thing is, if I’ve done the early testing, I now have a later test to see how he qualitative data lines up with the quantitative stuff. So don’t forget to include testing at these points as well!
Intangible Ephemera
Before concluding this essay, there’s a few other items that I wanted to mention that didn’t seem to fit in anywhere else. These are the intangible, nonlinear parts of the process.
Sometimes I spend my time contemplating ideas, just sitting and thinking. I know it seems odd, but I feel it’s really important for me to internalize a lot of the information I gather on a particular subject. Sometimes I just want to ponder. This kind of nonlinear activity is still really important to me. Sometimes, it’s active thinking, involving writing along with all the thinking (as mentioned earlier). But I try to let go of the feeling that I need to actually be working on the computer making UI stuff in order to feel like I’m being productive. After all, if I’m not confident about my own ideas, how can I convince someone else about them?
Aside from just thinking, there’s also the idea of getting away from your desk. Sometimes, I get a lot of ideas when I’m not anywhere near the office. In the shower in the morning, or out biking around, it usually happens when I’m not really thinking about anything, and then suddenly, an idea will just come to me.
But there’s also something about doing physical activity (like cycling) that can sometimes trigger a clear idea. For me, especially when I’ve had a long day, cycling home helps clear out the cobwebs and my mind can actually focus on the things that matter. It turns out, there may even be some science to back up these claims! Then there’s the additional obvious benefit of burning the calories of all that junk food you ate at lunch… 🙂
Lastly, I want to talk about this topic: designing within agile…
Eons ago, I once wrote a post on agile design methods. Interestingly, it was supposed to be a multi-part essay but I only wrote part one. Anyway, feel free to read my weird writing from back then. 🙂
So what about agile/scrum? How do I design within agile? My basic answer is: don’t. But there are ways to work within a scrum or agile process if you understand how it works as a process. The main thing to know is that agile software development is not some magical miracle methodology. It is a method of building software in short increments. It is mainly targeted at software engineers (not designers) to help them do what they do. It is a different way of organizing your production pipeline. It is not (necessarily) a process designed for creative exploration.
Implementation methodologies are all about the How. So if you’re a designer and you want to work in an agile process, keep in mind that it will mostly emphasize the parts of the design process that are all about those nitty gritty details, color, type, layout, content, etc. Once you put yourself into a process like that, you’ll have very little time to explore the other parts of the design process that I described, the What or the Why. Some people are ok with this, and there’s nothing wrong with only doing the How. But whenever I’ve been a part of that kind of environment, I’ve always felt it was important to ask the other questions too. Unfortunately, the metrics you get from looking at product analytics are simply not sufficient for answering those questions.
There might be a way to do this though.
If we agree that agile is really just about the How, then it might be possible to work on the What and the Why outside of the actual scrum process. So remember that there’s an activity at the end of the sprint involving sprint planning (usually after a retrospective). During sprint planning, everyone estimates the size of the story and commits to certain stories based on their relative capacity. Well, here’s how it could work…
A lot of the Why part is really impossible to size, because research can beget research. You can certainly time box it, but that may not get you to the right end point. The What may be easier to size, but it depends on the Why. So one option would be to reserve some of your capacity to work on those other 2 pillars. Instead of saying you have 100% capacity to devote to a sprint, maybe in actuality it’s like ~30% and the other ~70% of your time is free to work on the other aspects of the process that are just as important.
And it’s not that you’re doing nothing for that remaining ~70%. The Why and the What are things that help you flesh out user stories. The Why should be part of the user story itself, whereas the What helps give more context. These tasks are things you can do, working with the PO (or maybe you’re the PO) to help define a better backlog. A useful backlog is an important aspect of agile that can help the engineers be more effective!
Wrapping it up (finally)!
Phew! Oddly, I don’t like talking about process, but this ended up being a long essay! I find it difficult to really encapsulate all the stuff that I do. In general, I really don’t like design processes that feel prescriptive or hacky. There are no easy answers, and there’s no such thing as a perfect process. So that’s how I ended up with the 3 Pillars of Good Design — the Why, the What, and the How.
There are many ways to work through these questions, and the underlying idea is that our tasks should change as we work our way through it. And even though I don’t recommend trying to cram a design process into the agile software development method, there may be ways to do it, if we keep in mind that the How and agile development are both for implementation.
Is design thinking is bullshit? Not necessarily. There are times when it can be useful, but it’s not always a sure bet. I’ve chosen to simplify my thinking around it. Even though I may not have called it this, throughout my career I’ve found myself coming back time and again to these 3 questions to help define a design. Hopefully, this makes sense to you too! 🙂
Here’s my blog post for August! This is part of my “Year of Blogging” series for 2017. If you have any thoughts, tell me about it on Twitter!
Why design? 
[…] kicking of a series of shows devoted to “the dreaded P word!“, based on the essay that Chris wrote. We’ll have more in-depth discussion in the […]
[…] doing a series of shows devoted to “the dreaded P word!“, based on the essay that Chris wrote. We’ll have more in-depth discussion in the coming […]
[…] The Dreaded P-word — This helped form the basis for this whole series! […]