App Design
From complexity to simplicity: allowing lone-engineers to install and configure a wireless fire alarm system and its devices (B2B)
To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of the client.
The company was developing a new device to expand their range of wireless fire panels. These are quicker to install, suitable for engineers that need to install many a day to reach an acceptable level of income.
To help engineers quickly install the panel, which means connecting up parent/child devices, a brief of developing an app to ensure the process was:
- quick
- comprehensible under pressure
- able to be used for first-timers and experienced pros in installing these devices
With the client, we helped them to create the main problem statement that they felt they were facing. From there, we further dissected the main key points that helped to define users, scope and MVP specs for each part of the project: the hardware and the app.
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%25207.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%25208.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%25206.png)
Next we work-shopped with the client to define who were the stakeholders as part of the project: who would be affected, what industries and systems did we need to know and what constraints did these hold. The below matrix diagram explained this.
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252010.png)
With these explained, we created a system diagram of the hardware product: of what each step of its use was and who, from our explained user personas, was part of this product lifecycle system.
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252013.png)
Below are user personas that the scope of the project was going to focus on for the hardware and app.
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252017.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252018.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252019.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252020.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252021.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252022.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252023.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252024.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252025.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252026.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252027.png)
(J000966%2520Hyfire%2520%25200%2520workshop%2520presentation)(Doc)%252028.png)
To show to the clients the user problems they were experiencing with the current products on the market, but also which to prioritise 1st by which end/influenced user: I created the radar map as shown. I have found that visual communication tools are the best way to express problems and solutions.
(J000966%2520Hyfire%25200%2520workshop%2520presentation)(Doc)%252030%25201.png)
The competitor analysis as well as general feature explanation helped to convey the differentiaton and/or similarities the app needed.
As part of the success of both a new product and app is customer help, I stressed the importance and the set-up other competitors had, that helped their users instruct them on how to set up the devices and use the software.
To further clarify to the client that we understood the ecosystem the product and app sat in, I designed this diagram to show what else was needed in their business/tech stack.
With no direct competitors, I researched other apps that provided similar functions of data-display, demos and device collection.
The client came with a brief of what the app had to do as a basic MVP. As a designer, it is to design at scale and to be aware of any potential feature that could be part of the development roadmap, and who it served.
I created this tablulated feature list to define clearly to the client as to what was needed right now and a good to have at some point.
(J000966%2520Hyfire%2520workshop%2520App%2520exploration)(Doc)%25203%25201.png)
I created pen/paper diagrams initilly to clarify to the lient what I envisiged. This helped them to confirm to them whether this is what they needed.
This helps to define specs before going further into high-fi prototypes.
%2520Hyfire_app_project_userflow%25204.png)
%2520Hyfire_app_project_userflow%25205.png)
%2520Hyfire_app_project_userflow%25206.png)
%2520Hyfire_app_project_userflow%25207.png)
%2520Hyfire_app_project_userflow%25208.png)
%2520Hyfire_app_project_userflow%25209.png)
%2520Hyfire_app_project_userflow%252012.png)
%2520Hyfire_app_project_userflow%252013.png)
%2520Hyfire_app_project_userflow%252014.png)
The user journey was kept simple for an MVP, where they:
- entered site details
- ran through a demo of how to use the app
- connected to and configured the main fire panel device
- scanned and connected up child devices
- where this made a 'project' to be uploaded to the main fire panel
The project underwent staff changes and was awaiting further definition of the main device before the app could progress any further.
.png)
.png)
