Every developer has experienced the dreadful moment when the least technical person tries to demand technical features. It always results in bad design patterns, unhappy customers, and frustrated developers forced to build features that no one will use. “Can you animate this please?” “No, we want a loading bar like this.” Or any iteration of “It needs to be able to do anything”. At the end of the day it always comes down to inside out thinking, going from product → user. The person requesting the product or features usually doesn’t know enough to understand the ramnifications of their request.
For example, making an app work both online and offline requires a complete overhaul of the design and is more than just downloading the online app. Obvious to any developer. But a non-technical person will not understand this and think it’s a matter of just downloading the website.
So how do we flip this around and change our inside-out thinking to outside-in?
By flipping the dialogue we are able to focus on the user-first and understand their requirements from a different perspective. Design thinking is an incredible tool for this. Using this, we can understand that the non-technical person might not want to download the actual app but rather have one feature from that app available offline. Without understanding the user we can’t put this into context and understand where the question comes from, but by putting ourselves in the users’ shoes we can understand the need behind the question and build features that users actually need.
Why do we need design thinking?
The typical development process involves a product owner who defines the product in user stories and developers who transform these into code. From what I’ve seen, most product owners and developers believe these should be as self-explanatory as possible. Requiring no background knowledge from the developer. A product owner will define a user story such as “as a user I want to see a prediction of how well my article will perform as I’m writing it”. Then, the developer will pick up this user story and develop it into a feature in whatever app they are working on.
The problem this brings is that the task of translating the users needs into complex code ends up resting entirely on the shoulders of the product owner (who are often not as technical as they like to believe). On top of this, developers often like to forget the users while they’re developing and simply build bigger better features.
Design thinking is a tool that developers can use to understand these needs and translate them into features that the user actually needs. Given the aformentioned user story, the user probably doesn’t need an actual forecast of their article’s performance. Especially not when the product owner or user finds out how well AI actually performs in these situations. What they actually need is probably much closer to something that checks if they meet certain simple requirements.
What is design thinking?
Design thinking (in the development process) typically involves following five steps to understand your users. This doesn’t have to be something your boss, product owner, or user is actively aware of. In fact, 99% of the time this entire process takes ten minutes of me asking the PO or user what they intend to do with the feature.
Empathise
The first step of design thinking is where you try to empathise with your user. As simple as this seems, it is often the hardest and most overlooked. This is where we try to figure out how the user does their work and why they might want the app. Who are they? What do they want to achieve? What are their main problems? What makes them happy (in the context of the given features)?
By empathising with the user we can understand where the desire for a performance prediction tool might come from. Maybe they spend lots of time researching the content of their article or they have complicated SEO requirements to meet. Or maybe it’s something completely different, maybe the user wants the prediction tool because their boss keeps bothering them about their articles underperforming 20% of the time. In that case we could make both the boss and the user happy by instead finding a way to analyse their current articles. Either way, before you blindly implement a feature try to first understand the need that comes before it.
Define
The second phase of design thinking involves defining the actual problem behind the problem. In this fase you want to take the requirements and understanding you took from step 1 and mix it with your domain expertise to define the problem in terms of their actual needs. By redefining the problem this way you can figure out the real solution. Often times the client or PO will know exactly what the problem is and use that to try and define a solution for you, but by taking a step back like this you can redefine it and help them understand as well.
For example, you might get the request to build an automated tool for developers to effortlessly build any type of website in any situation. But after empathising you come to the understanding that the *actual* desire is for developers to build e-commerce websites 99% of the time and only once in a blue moon a blog style website. By redefining the problem for them you can propose a simple e-commerce framework that gets 99% of the work done in a fraction of the time.
Ideate
This is the toughest part of the process and where the magic happens. Try to keep your ideas as visual as possible and manage expectations properly as well. This is where 99% of the scope creep happens so you want to set expectations in writing *before* you get here. If the client expected a simple template before they see visual feedback then now they will want an interactive development ready product. Try to find the right balance between keeping them excited and reminding them of what you originally came for. If you dont’t then no matter how much you go above and beyond they will never be happy. Manage expectations.
Meanwhile, make sure to ideate as visually and tactile as possible. Get them to use a demo as soon as possible and get things visual early. Another wonderful tool for this stage is a persona analysis. Here, you will map out the different users and stakeholders and try to empathise and define how they will interact with the product and why they need it. Try to understand what they want, what they don’t want, and why they want this. By maintaining this empathy you keep it easy to manage when things get tense (which usually happens here).
Prototype & Test
Officially these are two separate fields, but in software I believe they are essentially the same. By moving to an MVP as soon as possible and ideating early you get to test alongside development with a continuously working prototype. By mapping out the previous three steps well you get to keep this phase in line and in scope. Try to get as many things in writing here as well so you can circle back to the PO or who ever pays the bills and remind them why they should be happy.
In these steps it seems like a long process, but this can also be as short as a thirty minute user-story. By internalising these frameworks you can continue to get better at understanding the problem behind the problem and ensuring that you develop software that people actually need, not what they ask for.