Specialised application for BWT Aquatron
Sales representatives spend a long time customising Aquabot robots with numerous adjustments to ensure customer satisfaction. Because customisation are done manually — using Excel spreadsheets and printed mockups — sales reps find it difficult to fulfil their targets. Many have complained that the dialogue between the customer takes too long with all the revisions. This is an issue because if targets are not fulfilled, the company risks losing revenue.
The sales representatives used an Excel spreadsheet to configure the Aquabots robots in accordance with the client's specifications. With such a rigorous list of fourteen stages of customisations, the exchange of this dialogue was timely. The process was very unorganised and not very user-friendly as customers couldn't see what they were consenting to.
Discovery
Due to the nature of this project, I knew the exact users who would be using this application. I began my research with one-on-one interviews to better understand users journeys and specific issues (pain points) that the app would need to address. I also used competitive analysis to gain an understanding of the approaches for comparable gamification configurator user flows. These research methodologies helped to identify functional and usability problems the application would need to address and resolve.
Armed with a better understanding of users requirements, I felt it was important to establish two sides of the personas: an expert in Aquatron; and someone who lacks experience in Aquatron. The persons represented heavy emphasis on the key differences between the user types. Creating personas provided some clarity and will serve as important reference points for design decisions moving forward.
Rapid sketching enabled me to quickly experiment with various page layouts and user flows. This exercise assisted me in investigating design patterns and trends prevalent in personalisation applications. In early concepts, I focused on displaying all the customisations on a single scrollable page, which was later retired due to feedback from Low-fidelity prototyping.
Low-fidelity prototype testing allowed me to better understand how users expected to complete the Aquabot robot configuration. I presented two distinct user flows. Through user input, I learned that providing a step-by-step layout with neatly organised modules and adequate negative space resulted in the most natural user flow.
The high-fidelity prototype brought consumers closer to the real thing, but it also exposed some issues. It became clear that the spreadsheet we had received to configure the Aquabot robots was incorrect, resulting in an inaccurate prototype. To overcome this challenge, we held weekly meetings to discuss our progress and identify any project roadblocks.