Design-first thinking encourages a solution-based approach to solving problems. This is different than a problem-based approach, or analytic/scientific approach, as solution-based focuses on moving forward with unknowns of the problem still existing.
Design thinking is iterative, working in small steps to achieve small goals. These small goals accumulate together to form progress on future larger goals. Design thinking encourages group thinking, expressive ideas, creative suggestions and a no wrong approach methodology during the brainstorming session. Typically broken into seven stages:
- Define
- Research
- Ideate
- Prototype
- Choose
- Implement
- Learn.
Help generate diversity by building upon concepts and ideas with great encouragement from all participants and inputs in a plethora of suggestions.
Design thinking is iterative, working in small steps to achieve small goals.
While this method of thinking can often be found in small organizations, this philosophy can be used within a large organization with just a few adjustments to process and methods. One of the best places to start is to become open to the concept of building smaller, more easily manageable features. Breaking the tradition of building monolithic products with large release dates and moving to a release cycle of smaller features includes significant benefits: Reduced stress among staff, faster time to market, higher conversion rates, empathy for customers, better product performance, increased knowledge transfer among the team, and easing the ability to sunset old features or technology that are no longer supported.
Getting started with design thinking doesn’t have to be complicated. Incremental steps over a series of releases or months can help an organization of any size use this methodology. Begin with a problem or suggested user path hypothesis that arises during a meeting, or with an actual pain point discovered from talking with users or customer support. (Pro tip: if you’re not already, talk to customer support at least once a week or review their logs. You can often find trends very easily because they’re talking directly with customers on a frequent basis.) You can also use a series of basic UX techniques with customers, such as immersion, interview, and observation to flesh out issues.
Understand and define what the actual problem is. Then research the problem – look at analytics, data, and customer service to discover, is this an issue? Ask, “Are we losing or hurting users due to this?” What percentage of our users does this affect? How long has this been happening? Try to learn as much as possible about the issue, and understand who it affects. After you’ve defined and researched the problem, move on to the ideate step.
When ideating, all suggestions are valid and accepted. Don’t spend an hour discussing all the negatives or issues that will arise from any of the solutions that are suggested. Remember, this process is solution-based, so we’re not trying to flush out every single possible flaw. Document them in a shared file so everyone can review, edit and suggest. Then, as a group, pick 2-3 suggestions that seem worthy of prototyping.
The criteria for which suggestions advance can vary per company and per problem. Criteria could be which ones are ‘easy to implement’ or ‘best user experience’ or ‘shortest path to victory’. The criteria used can and should be fluid based upon requirements, time, and priority of the issue.
Convert these ideas into prototypes – the fidelity will be determined by the issue. They could be InVision workflows, animations, a CodePen, or a larger code prototype. Then bring these prototypes to real users that this problem affects.
Did one of those prototypes test well? If so, plan for it to be built for production. Did none of the prototypes test well? Then go back to the ideate stage, and draft additional possible solutions. The design thinking process isn’t a strict linear line, but rather a fluid circle. You can jump from stage to stage as needed and when needed. It’s much better for monetary, time and product reasons to build prototypes to see if they fail, than to push those suggested features into production and discover (or even worse - never learn) that they fail.
Afterwards, have a small post-mortem. Regroup on the process, discuss what went well, what failed, what can be done better. Check the analytics, conversions, and customer support tickets. Was the problem solved? Did it create new problems? Did we get feedback in testing about problems we weren’t aware about? What is the next issue we’ll be defining for this process?
Depending on the problem, this entire process could take as little as a few days, or as long as a sprint. The point of it is to iterate in small steps to help decrease risk, increase moral along with building empathy in the team, and create a better product for your customers.
Do you have questions or thoughts on design process? I’d love to chat! Find me on Twitter @mkivikoski or shoot me an email if you’d prefer to chat in private: mkivikoski@cantina.co
