Design thinking methodology makes us think, when we have to make a product, especially a software product, we always find ourselves in doubt – “How long will it take to make it?”, and since we rarely have unlimited budget and time, the second important question is – “How much will it cost me to make it?”.
Both are fundamental and crucial questions when creating a product, but often, those are absolutely the wrong questions to ask. The most important question should be – “Which of the things I can do is really useful?” Since the natural economic time limits of a project impose a choice, understanding which functions are to be developed and in what order becomes crucial.
A design thinking methodology known as Design Thinking is introduced in order to understand the project perimeter better, to understand which features must be included and which are really essential. This managerial design thinking methodology (developed in Stanford and then spread rapidly all over the world) increases an organization’s ability to make effective and efficient decisions, through a process of developing creative thinking.The Design Thinking methodology has a much wider application perimeter and can be used in various situations, but here we’ll discuss in more detail its use in the Software world specifically.
This approach essentially generates a unique value: knowledge.
Through a creative and experimental process, it allows you to quickly understand the best solutions to adopt in order to avoid creating something that is unusable and useless.
The Process
The process can be divided into six phases:
- Empathize: Do research to understand your users. Research can be done in the form of interviews, observations, focus groups, surveys.
- Define: Group the data of your research and define where the user problem exists
- Conceive: Prepare possible solutions. There aren’t proposals which are too strange or stupid!
- Prototype: Create immediately something tangible that allows you to verify your idea on the field
- Test: Test your idea on the field (with test users or a specific audience)
- Implement: Put the vision into effect
This sounds really interesting, but how much does it cost to make an app and how long does it take to make it?
Applied design thinking methodology – A real case
Know Unknowns: The Project Start-X
Some time ago I found myself at a meeting with an entrepreneur, some managers who all had many ideas. Their direct competitor had recently released a new application and the tension was palpable: they wanted to go out with something new on the market, to avoid losing ground.
“We have to follow what others have done, with a lower price” – claimed the Director of Marketing.
“We must create a more usable system that simplifies the life of the user in the various processes along the way.” – added another manager.
“We have to change the way we collect information, simplify it and integrate our processes with third parties” – claimed another.
“It will take months” – Technical Manager shook his head, while mentally translating all those requests into hundreds of hours of code to be implemented.
That meeting – and the subsequent ones – did not lead to a clear definition of what the product to be made actually was. We only knew that it was urgent, that we had to give a quick, better answer and hit the target as soon as possible. Company-X was a structured company, used to working on projects and applying Agile methodology partially. However, they were new to the idea of creating an MVP and testing it on the market, because – they feared – it would have an unwanted or unpredictable effect on their customer base.
“We can’t afford a half product, we need it whole.”
After about three weeks and with the competitor beginning to enjoy the fruits of their labour, the urgency became a necessity. Therefore, we decided to approach the product in a new way: we would not be going out with a “halfway”, but with a complete product. We wouldn’t have accomplished everything we had in mind – and all the huge list of wishes – but we would have focused only on those things that would really bring value to the end user. Our goal now was to beat the competition by not doing that something, but doing what was only necessary. And we had two months to do it.
So Company-X decided to start, with some perplexity and fear, a Design Thinking project aimed at understanding and learning what could be a product that would really give value to their customer base and, potentially, bring new customers.
Design thinking methodology in action – Empathize
The first phase of design thinking methodology is Empathize, which means understanding users. Become empathetic.
First step in design thinking methodology is to prevent the HiPPO (Highest Paid Person’s Opinion) from ruling our future choices.
Together with the Managers, we have compiled a list of possible stakeholders to be involved during the decision-making phase.
In a day packed with meetings, we made a first list of 30 names (including employees, functional managers and customers) who could be contacted directly and a target audience in their customer care of almost 4000 users (approximately 10% of their recurring customer base). We’ve tried to “normalize” the base as much as possible. We tried to have a distribution of gender, industry and other values, as standard as possible.
The first result of the interviews were encouraging, the interviewees were open to discuss the various points, to explain the weaknesses of the system from their point of view and what the strengths were.
The first questionnaires we sent to users were not successful: out of 300 emails sent, only 5 people answered. Disappointed by the first result, we were ready to try new ways to involve the user base and receive feedback when Chiara, a Sales Manager, jumped in with more than welcomed help.
“I don’t think they will reply to any emails, they are not used to interacting with us. But if we communicate with all those who have the renewal expiring and give them a small incentive, I am sure they will help us.”
The idea was simple and exceptional.
In a few hours we had a new list of users (3800), the list which maintained the same division between mainstream and extremes, but with the users who would have been “forced” to interact with the system.The new model of communication this time asked the users to answer a series of questions, participate in the beta and in return, get a discount on renewal. At the first submission of this new model, over 70% of users responded and completed the form.
We iterated and changed some of the questions in the questionnaire and interviewed some people more than once (fortunately, they were extremely available!) And in the end we obtained a database sufficient to understand what were the real problems perceived, the points that Start-X employees highlighted as problems but that have never been directed to management and strengths / weaknesses reported by users who have never been taken into consideration before.
The next step was to begin with identifying our target, to delineate our Personas, those who would become our potential customers and users of the product.During this brainstorming phase we involved the whole extended team (our team and the Start-X team).
The brainstorming phase was always performed remotely, using video-conferencing systems and tools to track the personas and their first approach. Design thinking methodology is exactly way of thinking that can implement those kind of ideas.
For each Persona we identified the biography, their approach to technology, the use of the social media and brands used, their needs and ideas on what would be their Customer Journey.
At this point we had to define the solution.
Define Phase
During the definition phase in design thinking methodology we tried to transform a generic definition of a problem – “We must create a product that reaches the masses and creates queues outside the shops” – into a more specific solution – “Adult men and women, between 35 and 45 years old need a solution to facilitate their communication in the digital world when they are away from home and to do so they need a device that they can bring with them.”
We carried out brainstorming sessions around our users, hypothesized solutions and kept an open mind to any possible innovation. “There are no stupid ideas.” was the mantra.In a short time, keeping in mind who our subjects were, we outlined what would serve them and what were the needs / fears that we had to address.
For each user we defined the features and the customer journey.
We decided to use a User Story Map model that allows us to correctly categorize the user process, to map the themes at the top (those in blue) and to follow the various elements. For each of the Personas we are going to define the set of activities, stories and tasks that we assume they must perform along the way.
Now we had to quickly test our idea, understand if it actually met the needs and bring it as quickly as possible to the market.
Our competitor was beginning to be successful and the numbers were on their side.
Ideate
During this phase of design thinking methodology, we began to outline possible real solutions, prepare sketches, prototypes, brainstorming, brain-writing.
Our team was completely remote and after a consultation, we decided to proceed in the simplest way to produce material, review it internally and then proceed to create a more attractive version to create.
The designers and some team members had agreed that to be as fast as possible, the best solution was not to use digital sketch tools directly, but to start with drawings directly on paper, to be shared with photos in the group and then proceed with the most interesting designs, to make them directly on Balsamiq or Axure.
The Ideate process (as well as the previous ones) are not sequential processes. During all these phases, we kept in contact both with the extended team to be able to constantly receive feedback, and with the interviewees, to be able to review notes or any questions or proposals.
We came to define which changes were to be implemented and which design in order to apply the change.
Preparing sketches digitally became easier by using collaborative software to trace the sketch and having already shared the various sections and their specific behaviors.
Prototype
Now it was the time to make it real and to prove if what we are doing, what we have hypothesized and what we want to put in practice, actually works. Real design thinking methodology test.
After almost 10 days from the beginning of our journey, we arrived at the crucial moment. We had to check our assumptions.
After a consultation and definition session with the team of developers, we weighed the stories and understood that the major component of development will lie in the creation of the back-end and interfacing with the legacy systems currently in place. Realizing the front-end component, on the other hand, would be a job that required a much shorter time.
We gave ourselves a time limit of 3 days to have a first version that reflects the product as much as possible and maintains the necessary functionality and three successive days to iterate over the collected data.
We decided to make the prototype of the front-end using the components already present, including a software for the analysis of the Heat Maps in order to have a representation of user behavior during navigation and use.
After 3 days (and a little sweat) we finally had our first version, with “false” data that reflected the behavior of the software we were going to create. There were some accessory elements that would be added later, but the software in that state represented a good deal of what would be created later.
After two weeks of work we had a software to try with users.
Test
The testing phase of design thinking methodology did not only happen at the end, but it was a constant moment of iteration and feedback.At the end of each element made, we tried to get feedback from users or customers before moving on to the next step.
Once the prototype was made, it was time to test it with the widest possible audience and check with them how effectively it responded to their needs, what their perception was and subsequently, what the expected result was during the usage.
The test phase of design thinking methodology was extended to the whole team and to some individuals outside the organization (customers and users) who, during the various sessions, had willingly consented to give their feedback on the implementation of the system.
The results were encouraging, the Start-X management could not only imagine what the product to be made would be, but could also “touch” what it would become. The extended team had the opportunity to test it and verify their assumptions, correct them over time and all that within two weeks.
Now we had to pass the final test – open it to users and understand what would happen.
From Idea to Product: Our MVP
We had data, ideas, Personas and a first tangible prototype.
It was time to roll up our sleeves and start developing.
We had a month and a half to build our system.
Hinges of the future project:
- We would have achieved what we had defined
- We would have turned quickly if there were obstacles, keeping our goal clear
- We would have used Agile methodologies
At that moment, we brought some new elements on board (front-end developers, back-end, designers) who would actually have worked on making the product and who had not participated since the early stages of the discovery.
The new team members also worked remotely and it was not possible to think of bringing them all to the same room for the time period of the project (and not even for a briefing).
The agile methodology provides a series of tools that can be used to share a common vision, instead of creating long specifications or documentation:
- Elevator Statement (30 seconds – 1 minute of pitch of the product and its vision.)
- Product Datasheet (a summary of key elements, both in terms of business and product quality)
- Product Vision Box (The box that should contain our product, ready to be shipped, highlighting the 3-4 points that should be shown in the box)
- User conference slides (use two or three slides, which could be used to introduce the product to a conference, avoiding the use of bullet points)
- Press release (The press release that should be sent to newspapers once the product has been released)
- Magazine Review (A review made by a magazine from the sector)
Both because we had new people and because we wanted to make sure that we all start from the same point and from the same assumptions, we decided to create a Press Release, as a collaborative exercise and as a way of sharing ideas. Considering that we also wanted to involve the Extended Team with Product Vision, the press release seemed the easiest way to reach all the team members.
The Press Release (which will not be really used to reach the press, but only serves the team), contains the typical structure used for a press launch:
- Headline, which indicates the product / service
- Subheading
- Picture
- Summary
- Problem that we will solve
- Solution
- Quote from a company person
- Quote from a customer
Once the vision is shared, we can move on to the second step – define what we will have to do and when. We focused sprint 0 in grooming the backlog, with the first division of activities and tasks.The activities are outlined within a User Story Map, to always keep evidence of the Personas and the flow we want to give to the product.
The rules for composing a User Story Map are simple:
The first blocks identify the activities, the second the steps to reach the activities and the third the list of stories and tasks associated with those activities.
GDPR Compliance and its effect on your business.
The stories are then sorted according to priorities (Must, Should, Could) and finally,how we draw a line to define what are the components that we must have for our MVP.
Our board took on an aspect of this type:
We divided the remaining time into three sprints of two weeks each.
The process used to obtain the product was an Agile process, with daily meetings carried out remotely every day and updates via Slack during daily processing to exchange ideas and needs. We carried out two reviews (at the end of the first sprint, at the end of the second sprint) and a Release Review at the end of the course, before the product was definitely put into production.
We used the latest sprint to prepare in parallel to the necessary material (servers and various assets) to prepare the environments that would host the new product, plus some landing pages (which had been prepared, separately, by the marketing team) .
Our product, an MVP not a “halfway”, but complete with the features necessary to meet user needs, was released into production two months after the original meeting.
Finally, users who had participated at the beginning of the process were invited to use the new product, now officially in production.The product worked, users used it and progressively new users were invited by Start-X (through email and A / B testing) to use it.
The learning process for Start-X did not stop there: in addition to having created a product, they incorporated a methodology within their organization,the methodology that was refined over time, led to discovery of new opportunities, to understanding their potential and sometimes even to decision not to carry on with a product or an idea because it wasn’t performing.
Conclusion
Outlining the perimeter of the activity of design thinking methodology that we will put in use is fundamental to focus on the main question, which is not how much we will spend or how long it will take us to carry it out , but it is a much broader one – “What are the features that really serve my target and how can I provide them in the fastest time possible to learn, correct and progressively improve?”
Need a remote team to grow your business?
Find more about me by visiting my “About Me” page.
Learn more about design thinking on wikipedia.