How to find the golden mean between simplicity and expanded functionality in an emergency app?
Meet our recipe for emergency assistance: the “Team Alert” panic button. What improvements did we make to ensure it is well-developed and user-friendly? And how did we travel from MVP to PMF? Read the story.
Table of contents
Generally speaking, a panic button is a solution that allows you to call for help in emergency situations, like fire or robbery. Team Alert goes one step further and provides support in daily life difficulties as well — not every alert is in response to the same level of danger; Team Alert might be also used in cases like spilt acid in a laboratory, or a device failure.
How does it work? Very simply. The person who needs help pushes the button and, as a result, the system sends notifications to the particular people and services that should be called. Team Alert is available in both physical and digital versions. You can equip yourself with a panic button or just use the app on a phone or laptop.
What is important, our client has conceived this product mainly for institutional bodies like schools, prisons, hospitals and medical facilities.
How does Team Alert differ?
As we already mentioned, contrary to a classic panic button, Team Alert helps not only in life-threatening situations but also supports users in technical or everyday obstacles. What else makes Team Alert unusual? The wide range of supplied configurations. Most panic buttons just send notifications to all the resources they can reach, responding the same to every emergency or use. While working on Team Alert, we wanted to upgrade this area and give the person in need more options. Keep reading and check out the results!
- The user can choose the type of alert that he or she sets off. Depending on the type of alarm selected, Team Alert calls the necessary specific contacts. It includes an administrator role in the user’s organization to manage specific connections and assign them to particular situations and circumstances. The administrator plans who should be notified in case of emergency or technical failure, etc.
- An additional feature of Team Alert is the chat option that comes with each alarm. The app automatically sends essential information or instructions to the chosen group of recipients. But it can also offer more assistance, for example, warning people who might be in danger because of the existing situation. It’s worth mentioning that the person who calls for help has the opportunity to inform others about the location of an attacker or provide a more specific description of the situation.
- We emphasized customization and provided Team Alert administrators with a variety of actions and channels to choose from. The controller can choose the type of notification, including automatic voice calls, text messages, emails, or push notifications. The application also offers its services in all modern languages. There is a manager area that allows the user to configure the group of receivers and the type of channel. The admin can decide who exactly will receive an email and who should be informed via a phone call. Our goal was to simplify the app’s use and make it as efficient as possible.
- Using Team Alert means sending files as well. Users can attach necessary instructions and images, or use default messages and answers that the administrator had previously uploaded to the application.
Customization on the front line
Are you curious about how we worked with our client and developed this solution? Keep reading for more details.
When we met with our client for the first time, they already had a panic button application. However, the client wasn’t satisfied with their current product and needed a partner who could develop the whole system and implement new features, paying special attention to customization. The software of the previous solution needed to be renewed and simplified. The challenge that we faced was to improve quality and transfer the software to the AWS cloud, as well. Faced with this challenge, our six-person team decided to create a product from scratch and prepare an MVP.
What is an MVP?
An MVP (Minimum Viable Product) is the second stage of the Full Cycle Product Development process which we use in Boldare to build products (we split our work processes into various phases). Long story short, an MVP is an early version of a product presented to customers. It includes only the minimum number of core features. The main aim of it is to test the product with real users and get valuable feedback for further improvements or pivots.
Would you like to know exactly what Full Cycle Product Development means? Read all about it!
Our first step towards the tailored MVP solution was setting out what exactly we needed to work efficiently, what features needed to be improved and implemented, and what were the needs of the target group. To cover all these elements, we decided to conduct workshops with our partner.
Discovering the product
The two days of workshops were intensive and required lots of analysis and metrics to lead. We gathered together in a larger group. Who attended? The CEO and customer service representative from Team Alert, and the whole team handling the project from Boldare.
Product Discovery workshops are our way of finding the most effective and successful solution for a client. The overall setup of a development project with a client can be a complex and intricate process, and these two days of work and discussions allow us to determine many of the details before going ahead. In this case, we worked out the target group, the product and business goals, user goals, product benefits, and release goals. We also described the customer journeys, the app’s functionalities and lines of customization, priorities, and estimations. Last (but not least!), we also planned the first sprint, which consisted of the product backlog, the definition of done and overall sprint goal.
Cooperation between Team Alert and Boldare was based on lots of conversations, listening to each other, and creating tailored solutions at every stage of building the product. Agile work brought us a quite big dose of trust from our client, and it made the whole process even more flexible and effective. The Team Alert crew used the Boldare team’s knowledge and expertise, treating us as business consultants and experts. As a result, our client got a fresh perspective on the product and was able to see new possibilities.
All roads lead to improvement
We mainly focused on a strategy of continuous improvement, implementing more and more new features in Python, React, Xamarin and .Net Electron. The iterations included new app languages, voice calls, default messages, and predefined responses to alerts. We admit that it was challenging to prepare such an advanced and extensive tool and keep it as simple as possible at the same time. Throughout the whole development, we kept in mind that Team Alert, above all, needs to be user-friendly.
All of our actions smoothly led us from the MVP (Minimum Viable Product) to the PMF (Product-market fit) phase.
What is PMF?
PMF (Product-market fit) is the next phase of Full Cycle Product Development — our process for building products that we mentioned earlier. At this point in development, we create the full-value product. With designers and web developers on board, the Product-Market Fit team builds new product features and tests them with app users. The PMF stage is more advanced in comparison to the MVP and, among the others, focuses on improvements.
We guided our client from MVP to PMF by means of a series of workshops. The whole process, facilitated by Product Strategist, started with a Business Model Canvas workshop (which helped us look at the whole product environment, value proposition and customer segments). Afterwards, we spent some time on Customer Segments workshop where together with our client’s team we analysed sales data and went through a focused series of questions about each segment. This allowed us to notice trends we had not seen before and draw conclusions which segments might be the one we should focus our efforts on. Next, we explored these identified segments deeper, established new personas, identified the new persona’s problems and created specific value propositions to be tested with them. The value proposition in this case simply means the value that the product promises to provide to the particular target group, in its specific conditions and circumstances. The last but one step in this process was in-depth interviews with the personas to confirm a list of hypotheses that we created. We drew specific product insights from these interviews, validated our hypotheses, and learned an awful lot directly from the users. This is the basis for further product development — not guesswork, but validated insights from the market.
Hard work bears fruit
Speaking about testing and iterations, our experience with Team Alert was an opportunity for further learning. After preparing the value propositions, we focused on internal testing and created a product road map. With another step forward, we picked out the essential features that needed to be implemented to find new markets for Team Alert to grow. We continue to take a dual approach: constantly working on new improvements, and also focusing on the effectiveness of a product.
What was the most challenging part of our work? Probably balancing the simplicity of the system against the need for a wide range of functionalities at the same time. Delivering this compromise wasn’t easy but brought us great satisfaction. Also, it was a great opportunity to build a product that actually meets real needs and contributes to greater safety in society. Team Alert has to be reliable and unfailing, because it’s an answer to the real needs of citizens.
Share this article: