How to Create a Clinical App Using Google Design Sprints
You may be familiar with Google’s Design Sprints and be aware of how frequently this method is used during a product’s Ideation Phase. Why is this method required?
A number of errors and ideas for improvement can be missed, for instance, if user tests are conducted improperly (for example, by asking questions in a way that prevents users from being completely honest in their criticism of the product). Thereafter, what was overlooked initially will have to be done again, increasing both the cost and the time required to create a complete and final product version.
However, in order to know what tasks to set up for users, you must first develop a strategy and reasonable business metrics to achieve. Next, create UI/UX layouts, discuss the appropriate architecture, and evaluate work at later stages of the timeline. And it all stems from the initial ideation phase.
Following that goes the Development Phase, which includes Software Development, UI, and subsequent User Tests.
However, one must remember the most crucial aspect so that the company does not suffer significantly due to this phase.
It is necessary to implement the Design Sprints methodology, which, for example, includes the previously mentioned User Tests approach, in order for the business to save time on the Ideation Phase.
By using a design sprint, a company with Clinical Product can benefit in several ways:
1. Improved user experience: by incorporating user feedback early in the design process, the team can create a platform that meets the needs of the users and provides a better user experience.
2. Reduced development costs: by testing design concepts with users before development, the team can identify potential issues and make changes before costly development work is done.
3. Faster time to market: by using a design sprint, the team can compress the design and testing process into a short period of time, allowing the product to be developed and launched more quickly.
4. Increased stakeholder buy-in: by involving stakeholders in the design sprint process, the team can ensure that everyone has a voice and is invested in the final product.
And now, we’ll demonstrate how the Google Design Sprints tool functions.
I. Where do the Design Sprints start from? With concepts and… metrics for these concepts
A concept exists to get us to question the obvious and come up with something new, as Don Norman explains in Revamping Design Thinking. It can also imply rethinking existing solutions.
Using Clinical Products as an example, let’s suppose we are treating neuromuscular disorders. All parties involved in these disorders’ diagnosis and treatment processes, including patients, medical professionals, and other stakeholders, must have their needs acknowledged in this scenario.
We analyze the issues and the market to see existing solutions and what we can provide that is entirely novel (here, we brainstorm). Additionally, the “novel” can refer to features and their presentation as well as positioning.
Existing concepts should be incorporated into the Product Vision, which is governed by particular objectives and financial metrics. Business metric examples include retention, MAU/DAU (what influences engagement), subscription conversions, etc.
And most importantly, if you already have an interview with users or feedback about their competitors, then this should be taken into account when developing a prototype.
II. After the discussion, we create a prototype and develop UX
Once the critical problems have been determined, we discuss the Design Brief Document and create UX wireframes.
Consider a situation where our clinical app uses a lot of data, and users have expressed concern regarding this.
This was because people were forced to use multiple record systems to access the data required to complete their tasks. As a result, they were forced to move from one massive set of data to another to find the information needed to answer their queries.
Finding data took time and was frustrating. Yet, they could have just worked on sorting to improve the user’s experience.
In order to create a complete UX without fixes, we previously needed to conduct user testing. But in addition to user feedback, we also need to understand how UX is used in the real world, so let us explain the fundamentals.
1. When a user enters such an application, you need to establish trust with them right away using evidence and data: use as little advertising as possible, don’t ask for a lot of personal information during signup, provide links to thorough studies or trustworthy sources to vouch for the accuracy of the content, and offer social proof in the form of statistics and expert reviews.
2. Make the content simpler by using straightforward terminology, avoiding clinical jargon, and visualizing information using images, infographics, and animations.
3. Keep in mind engagement control and retention, so it’s needed to demonstrate compassion by acknowledging their condition and the challenges that come along with it, and use tools that encourage the user’s discipline and motivation (for example, gamification).
4. The final point applies to any health application: consider the laws and modify UX accordingly.
Next, we compile the deliverables for product design into the Vision Scope document. With the aid of partner-partner vision scope discussion calls, this step should be completed internally.
And create a prototype for the generated ideas. Если у вас он уже есть, то далее мы переходим к валидации идей.
При отсутствии прототипа его необходимо создать в Figma. Выбор Figma обусловлен тем, что нам нужно как можно быстрее получить обратную связь, чтобы затем создать работоспособный MVP.
III. Next, we run User Tests
We have discovered a basic pattern while communicating with many companies in the multifaceted niche of clinical products: everyone understands the importance of clinical tests perfectly well, but few people consider, for example, User Tests.
After all, User Tests allow us to understand better where UX / UI errors and development points may exist. So, in our practice, there was a Digital Health App with a user outflow and low engagement rate.
After conducting User Tests, we discovered a serious defocus and high cognitive load among users. They couldn’t find the necessary information and features in the application, they took a long time to complete the tasks, and it was difficult for them to navigate. The link leads to a detailed Design Review.
As a result, there was an understanding of what should be paid special attention to and improved. So that later on, some aspects would not have to be reconstructed from the beginning. It is the primary reason User Tests are essential.
How to run User Tests?
1. Identify the target audience:
- Within the current database;
- In other locations where your potential users stay, such as Facebook groups with discussions of valid problems, thematic websites and forums, or communities/blogs of your competitors.
The thing to keep in mind: Separate tech-savvy users from others to determine whether, for example, older people can also use your product.
2. Prepare questions and tasks, such as finding a specific button in the application or providing feedback on what is lacking in the gamification.
3. You can also do CustDev concurrently, though we advise reading “The Mom Test” because the subject is too extensive to cover here. But generally speaking, you need to ask questions about the past rather than the future (‘will you use this?’ instead of ‘how did you solve such a problem in the past?’).
4. Record the test results:
- Did users remember the brand’s primary colors after the test session?
- Were there any navigational issues?
- Were the tasks completed?
If the initial prototype received a negative experience from users, then we go to the second round. Completion of the second round takes place with ready-made materials and feedback. Due to this, the repeated stage lasts several times faster.
IV. If we go to the second round, we do the final test and compare it with the previous results
The team decides to make changes after identifying areas for improvement based on the feedback. A final design specification that can be applied to the application will be created once the team is confident that the design satisfies user needs.
Let’s go back to the previous example from our practice: remember we said that when using the application, users had a lack of focus and a high cognitive load? Take a look at the image below.
The heat map demonstrates that the improved design has no discernible impact on focus. The elements that should draw attention are precisely the ones that do.
However, because all the blocks are distinct and prevent user confusion or information overload, there are no issues with cognitive overload.
Pay attention to the unevenness of the previous version for comparison:
According to testing, the platform’s ease of navigation increased by 22%. As a result, the application’s registrations and visits have increased.
The old version of the application had 100 students from Swedish schools a month later. The new version of the app reached 10,000 Swedish student users in six months.
The number of users who finished all tasks on time increased by 32%. Users can now find the information they need more quickly. As a result, engagement and registration rates have increased.
Therefore, a subsequent user test will demonstrate whether past performance has improved and whether further improvement is necessary.
Let us recap what Design Sprints entail:
1. Vision formation, with setting up ideas and metrics.
2. Minimal prototype and elaboration of UX Design based on user feedback and world practices.
3. User Tests, during which we find out whether improvements and repeated tests are necessary.
All these three points are included in the Ideation stage, which is necessary in order not to miss a lot of mistakes and ideas. As we said earlier, this leads to a greater loss of time.
After all, without this stage, we will not know about the negative UI and UX experience in advance. Without it, we can immediately move on to creating a scalable version of MVP, but at the risk of huge redesigns of the design and the entire logic of the application, including the full user path.
And in the end of Ideation Phase we should:
- make a technical vision demo: there we share the technology and compliances vision;
- make estimations for the Development Stage;
- begin to develop a scalable version of the product with a full-fledged UX/UI for the entire application.
We hope you’ve found our article helpful.
Also, if you want to read more about Digital Experience in Healthcare, then check out our blog Here.
