Today is #WisdomWednesday ?!
Have you ever had an amazing idea, built a product around it, and found out no one wanted it? I have, plenty of times.
Part of the issue is we started from the solution, but there is a better way.
⭐ This is a thread on Design Thinking ??
Creating a product, whether a software, a physical thing, or a service, is all about solving a problem.
? Someone has a problem, and you offer a solution.
But we often start with a solution, in the hope that someone wants it, and we end up solving an inexisting problem.
This happens because, in real life, problems are not cleanly written in some kanban board.
⚠️ We often know that something is not right, and we think we know how to solve it but, actually, we don’t even have a clear idea of what’s wrong.
Enter Design Thinking ?
Everything stems from these principles:
1️⃣ The problem is never well defined.
2️⃣ The problem and the solution must co-evolve together.
3️⃣ The solution is never completed.
And one key idea:
⭐ The human being is the most important element of the solution.
Based on these principles, the process itself is a continuous cycle of five steps:
? Understand
? Define
? Ideate
?️ Prototype
⚗️ Test
? You start by observing people, your potential users or clients. Ask yourself:
❓ How are they solving the problem now?
❓ What is their critical pain in doing so?
❓ Why is that happening?
? These questions sound familiar to you?
Useful tools and practices:
? Observation. Just watch people in their routine and take notes.
? Interviews, but not with standardized questionnaires; instead, talk openly with people, and listen.
? Ask “why” at least 5 times to get to the core of the problems.
? Then you have to clearly define one problem to solve. Focus is key here.
A good definition is actionable. It describes a situation that is easy to validate when it has been solved.
? Go deep, you don’t want to solve the superficial problem but the underlying cause.
Here are some techniques:
? Use a board (physical or virtual) and put a note for every potential insight or problem.
? Make clusters, group similar problems and insights together.
? Select (or vote on) one cluster and write a clear definition of the problem it represents.
? Now it’s the fun part, it’s time to come up with ideas!
This is the creative part of the process, so don’t be afraid to have too many ideas. This is a rare case of quantity before quality.
?️ The best tool is a brainstorming session.
A good brainstorm has these qualities:
? Only one person talks at a time, no interruption allowed.
? Set a maximum time for each intervention, around 1 minute.
? No idea is too crazy or impossible.
? Build on top of others: instead of “no, because”, just say “yes, and”.
?️ Next, it’s time to finally build something!
Select one, or a few related ideas, and turn it into a prototype. You want to build a Minimum Viable Product (MVP), the smallest piece of functionality that lets you learn something new.
? Don’t overengineer.
You know you are overengineering when:
? You care about how it looks (unless that’s the problem).
? You care about how fast it is (unless that’s the problem).
? You feel sad if you have to scrap that prototype.
⚗️ Finally, you have to test that prototype.
If your problem was clearly defined, you should know what a successful evaluation looks like.
? This is not about software testing. Test the prototype with real people.
Things to keep in mind:
? Shut up and watch, people should discover how the thing works by themselves.
? Test with a variety of different profiles.
? Write down every complaint you get, but don’t mind about the proposed solutions.
Once you reach this phase, you should have an answer to the question “is this problem solved?”, which probably is:
? Somewhat, but the problem was not so well-defined as you thought.
That great! You just completed one cycle and learnt something new.
? Now start over.
⚡ Design Thinking applies not only to software but to any creative process.
Whether you are planning an event, writing a book, building a physical gadget, or launching a service, you can use this strategy.
This is not a bureaucratic methodology you have to follow, nor is a silver bullet. The key idea is this:
? You’re trying to solve someone’s problem, so you have to understand them first.
Everything else is just tools to help you do that.
As usual, if you like this topic, reply in this thread or @ me at any time. Feel free to ❤️ like and ? retweet if you think someone else could benefit from knowing this stuff.
? Read this thread online at
https://apiad.net/tweetstorms/wisdomwednesday-designthinking
Stay curious ?
? https://t.co/8j9gkntvPG
? https://t.co/WbpWHq2R5P
?
https://www.ideo.com/post/design-thinking
https://en.wikipedia.org/wiki/Design_thinking
https://youtu.be/UAinLaT42xY