The power of design thinking in designing for IT
I have been designing user interfaces for over 10 years. I've seen big ideas fail despite huge budgets, a committed team and a theoretically good product. I wondered what this was due to and promised myself that when I was more empowered I would not allow failure. I started to analyse products that had failed or not even launched, as initial user feedback indicated that the product did not solve any of the problems they were facing. Often they were something 'fancy' but didn't actually change the customer experience in a significant way. At other times, they were based on an almost dogma - our customer will accept anything and no matter how 'fancy' the process is, they will still humbly go through it. Of course, in the end there was a verification and a clash with reality.
What did all these failed products have in common? They had one common denominator - they only pursued business goals, without involving the user in the process. That's for sure. Another distinguishing characteristic of unsuccessful products is the focus in the analysis phase only on the functionalities that the customer provided. This is often done by the client providing a document describing the product they want to create. The development team then prices the 'coding' of these functionalities, a timeframe is set, mock-ups are created somewhere and... it begins. Suddenly, it turns out that the functionalities described in the request did not include some aspects that came up when the designer started drawing the mock-ups and thought empathetically about the end user, or some functionalities were missing to be able to successfully go through the whole process as a user at all. What causes this? It has cosmic consequences - because the time of the project changes, the price of the project also changes and we start to lose control over the final form of the product. In addition, we are never sure that everyone understands the product in the same way and what the main goal of the project is. And ultimately - is our goal the right one at all? To answer this question - all we need to do in the analysis/discovery phase is to find space for workshops in the design thinking methodology. But what is it really all about?
Design thinking is primarily based on empathy. Empathy is the most important quality that helps us understand the needs of others. We want to understand the end user - it is for them that we create the product. We try to map the user's needs and business goals and bring them together in harmony. To understand the user we use empathy maps. This is a simple map that focuses on several aspects. What the user thinks, hears, says and does. Filling in this chart allows us to place the user and the product in a specific context - a situation in which we have to navigate as suppliers. This has one important aspect - we are sure that both the client and the project team perceive the user in the same way. Imagine a football team where the defence and the offence analyse the opposing team separately - in two different rooms. It's hard to have understanding during a match in such a situation. What the design thinking workshops manage to bridge is the difference in the tower between the customer and the supplier. We form one team playing to one goal.
Then when we understand the user, we have empathy maps filled in, we slowly start to define the goal of the product. To define the goal, we need to define all the pain points of the user and the business. There are several methods for defining these pain points - they are chosen according to the group present in the workshop. We can use simple brainstorming, the 'roses, thorns and doughnuts' method or a number of other methodologies, which I will describe in the next article. The consequence of this stage is a map or board of all the ills we want to address.
The problems need to be looked at broadly. Think about every contact a user has with the brand and map out all the pain points. We then select the ones we want to solve first - with the greatest benefit to our business and the user.
Stage three is the most enjoyable stage, as this is where we start to focus on solutions to the problems previously detailed. This is where the picture of our product begins to be drawn. Many times in projects, stages one and two are forgotten, starting straight away with ideas. Customers may carry out an internal analysis of problems and customers, but without the participation of suppliers there is cognitive dissonance. The supplier does not understand why they are creating the product - which leads to frequent misunderstandings. However, with problem-solving ideas, we can define the goal. When everyone understands the purpose, we can move on to the next stage - Mock-ups and prototyping.
While everyone understands what mock-ups and prototypes are, not everyone appreciates their preparation as part of the analysis or discovery phase. Often, the mock-ups come after the functionality analysis and cost estimation. This approach generates several problems, which I mentioned in the introduction to this article. We cannot accurately determine all the functionalities without mock-ups and the final cost of development when we cannot see what the product looks like. If you want to control costs and time accurately then you should ask the supplier to prepare mock-ups (can be wireframes of the main functionalities and paths) as part of the analysis. As well as being able to determine the cost - you can see an outline of your product and whether it meets a predefined need. The biggest treasure trove of mock-ups, however, is the ability to conduct the next stage - testing.
The mock-up or prototype testing stage allows the solution to be evaluated by a focus group - i.e. real users. It is here, using Maze or other tools, that you have the opportunity to test the whole concept, or main trends and paths, before releasing the development budget. This is where you find out if your product meets business and user expectations. This is a good time to back out of unnecessary features or add what might make for success. You get a report, data, figures and on this basis you can decide on the final shape of the product.
You already know what design thinking is and how it can help you with budget planning and determining the final form of the product. But how do you implement this methodology in such a way that you can apply it to agile projects? It's relatively simple. Many of the teams I've had the opportunity to work with follow this approach:
Analyst defines the problem -> Task goes into backlog -> mockups are created -> development -> solution tests
my proposed process in the spirit of design thinking:
Analyst defines problem -> mock-ups are created -> solution tests -> task goes to backlog -> development.
The difference is apparent. Already tested solutions at the mock-up stage go into the backlog. Of course, post go-live analysis is recommended but we reduce the risk to market of an inadequate product to a minimum. We also reduce the number of iterations and code changes to a minimum. Finally, the last point - we can launch the bare minimum, solving the biggest pain points, rather than taking an almost 'waterfall' approach to the product - all functionality at once. As long as we have hit the users' needs, the 'waterfall' approach is not bad. It's worse if we have spent a year or more creating a solution that does not address market needs and, because of a lack of testing at the mock-up stage, we have failed to notice the problem.
The design thinking approach helps not only to deliver products that are beautiful and useful, but also to optimise the budget. If you are interested in implementing design thinking in your organisation or in your product development process - contact me for a free, no-obligation consultation: