The design process is a way to ensure that you are using data to make decisions about what that user experience should be–and not making them based on your gut, or what the PM saw in a really cool app last night, or what is easiest for the engineers to build.
The design process defines your role on the project team. With no process, you’re an order-taker and have limited ability to shape the user experience. With a solid process you become a key member of the team and are able to put the needs of users and goals of the business front and center for all to see (and contend with).
The process ensures a great product.
The process comes during the design sprint, which is always one sprint ahead of an engineering sprint. It’s how you research, ideate, iterate, validate and QA the user expeirence and interface of your software.
The development process for engineers has been long been integrated into almost all product teams by now. Writing tickets in Jira, working in 2-week sprints, QAing code and holding demos and retrospectives at the end of each sprint are critical steps in a development process most product managers, engineers and designers are familiar with.
A design process is similar, in that it also is made up of sprints. It includes researching and understanding or defining the problem, coming up with ideas to solve that problem, weeding out the ideas until the best one is left, validating that solution, and QAing the feature once it’s been built. The design process does not need to be time-intensive nor should it slow down development if the team is working in a lean or agile method. A good designer will be able to follow through on each of these steps whether she’s creating a simple feature that can be designed in a day, or a brand new product that requires several weeks of design.
Step one: Research
Whether you’re starting a new product from skratch or creating a feature for an existing product, you’ll need to allocate a list a small amount of time to research the “What to build” question. This step might last two hours, two weeks or two months, but it shouldn’t be skipped. If you don’t know the competative landscape, if you can’t easily identify the painpoints that are driving your users crazy–or if you’re just creating a feature to create more features–you are destined to waste time, effort and cause more problems than you solve if you skip the research step.
Step 2: Ideate
Once you know what problem to solve, you need to come up with the best solution. This inevitabely means trying out a number of them, discarding all except the one that’s best. Whatever you (or the PM or the ENG or the VP) thought of first is probably not the best solution. Why? Because human bias is to like what we already know, and that first idea is probably something that’s already being done, has already failed or simply doesn’t consider the multitude of variables that a good solution will take into consideration. Don’t rush this step; take enough time to do the real work of a designer.
Step 3: Validate
Once you’ve come up with what you believe to be the best, most perfect solution to the problem, you must validate it with your users. No really, you must. This might mean some quick guerrilla testing in the hallway with five people who are not part of the product team. Or better yet, throwing mocks onto a platform like Usertesting.com to see how people respond to it. Better to do this early on–even before Engineers have seen anything–so that you can make minor (or major) changes and adjustments before pushing the designs to development.
Step 4: Design QA
The final step in a good design process is to QA the designs in-situ. Just as the Engs are QAing their code to make sure it functions as expected, you should be QAing the UX and UI to make sure that it’s both implimented as you designed it, and that how you designed it really does result in the user behavior you expected. It’s easy to miss problems until you see an experience complete with transitions, interactions and human participation.
How do you fit this who process into your daily workflow? That’s where design sprints come in.