
Project succefully finished MVP stadia and started to scale, new core auditory
The new target audience spends more time on the existing design and has more unsuccessful completions of the scenario and further use of the device.
Initial device setup is implemented as a wizard to allow users to concentrate on each step.
Device settings screen has been designed, and due to technical limitations, each step of the wizard is reused in the settings.
The ratio of the number of times required to set up the device was relatively more than one, previously was – 23%. After redesign, it is 95%.

This is a battery-powered device with WiFi that connects via wire to water and electricity meters and transmits readings to the user's chosen destinations: SMS, email, management company, or via MQTT protocol.
The MVP was launched to an audience of smart home enthusiasts, with code and specifications published as open source. During this time, an audience was formed, and a sufficient number of devices were sold to validate the hypothesis and expand to a new audience.
After purchasing device, user connects to it via WiFi and performs the initial setup through a browser. The MVP version fulfilled its purpose but lacks sufficient functionality for the new audience.

If an error occurs at any step (e.g., unable to connect to the network), all previously filled fields are lost when saving the status.
Overall, the edge cases for each step of the device setup are not well-handled.
The connection status to the meter is displayed incorrectly, confusing the user and complicating the setup process.
There is no device settings section; changing the network is only possible through a full reset and redoing the entire initial setup process.

User should spend as little time as possible in the device.
Each AA battery provides a year of operation in data reception and transmission mode; 10 minutes in setup mode reduces transmission mode operation by 30 days.
The code and logic should be as minimal as possible. The device has 32 KB of permanent memory and 80 KB of temporary memory, with a processor speed of 80 MHz.
I divided work into three stages in accordance with the fifth principle of my work:







The main points have been clarified, and now we are specifying the device's behavior and seeking solutions in accordance with the constraints. These aspects can affect the happy flow; this stage clearly demonstrates how small decisions impact larger scenarios, helping the client increasingly understand what awaits in the final stage.




Gradually, at each step of the scenario, details are clarified with the client, fixed, and adjustments are made visibly to the client, affecting both minor details and the main scenario.







All approved points are reflected in the frames. The happy scenario, edge cases, and errors are organized into corresponding sections. The requirement to avoid using new interface components has been adhered to.
Due to technical limitations, it is impossible to fully instrument the interface and scenarios with statistics. Therefore, indirect indicators have been incorporated into the initial architecture of the device.

The above statistics track how many attempts user made to complete the initial device setup scenario. Statistics are calculated in the ratio: one attempt / more than one attempt.
