Zero to one · UX strategy · Mobile app & connected hardware
Smart water bar application
Defining the first app for Strauss Water's connected water bar, and focusing a broad concept into an MVP built on personalization and full control of the bar.
Context & problem
A home appliance becoming a personalized connected product
The initial brief
The app was first framed as a broad water app. It would cover water consumption and water quality in your area, with managing the water bar as one added value among several.
What made it complex
One device, many users. A household shares a single bar, and each person has different drinks and habits.
Two markets, two roles. UK models were planned without a screen on the bar. There, the app had to configure and operate the bar, not just add value to it.
Hardware set the limits. Temperature levels, container slots and the bar's icons were defined by the hardware team, outside our scope.
Pairing. UX had to overcome a technically cumbersome pairing process.
Preliminary research. Market research was made by the product team. We were requested not to go through a discovery process with users.
Concept
From technical to personal
Due to the discovery approach, my scope was narrowed to define value, hierarchy, and architecture according to desired capabilities from product team.
My main point was to encourage users to download the app not only as a technical "remote control", but to make the bar-app a personal extension, with a broader drinking experience.
From technical: "Boil water to a high medium temperature, and pour 180 ml", to personal experience: "Prepare my morning tea in my favorite cup".
Concept pillars
Personal on a shared device. The bar recognizes each household member. This was a design decision to make a shared appliance feel like yours.
Drinks, not water. Users create a drink, such as tea, coffee or a morning bottle, and the water is part of it. Temperature and quantity follow from the drink, so users don't need to think about the water itself.
Define on the phone, act at the bar. Drinks and settings are defined in the app and used at the bar. Remote actions were kept to those that involve waiting, like boiling.
Engagement as a second layer. A drinking buddy to encourage drinking more, coffee suggestions to try new drinks, and water-quality information to keep filters in mind. All were meant to make the bar a centrepiece of the home.
Scope
Defining the MVP
What stayed, what moved, what was cut
Some of the engagement layer required content and resources that weren't available, and there was no evidence that bar owners needed it or would benefit from it. The first version kept only what had clear value.
Core: personal drinks, configuring and operating the bar, and bar health (purifier and UV status, fault alerts, support).
Secondary: water consumption tracking. It stayed in the app, but no longer at its centre.
Cut: external water-quality content, coffee suggestions, and the drinking-buddy persona, since it's no longer in the center.
Wireframes
Structure before visuals
Information architecture
The app was organized into five areas, with priority shown by size on the home screen. Water consumption started at the centre. After scoping, personal drinks took its place.
Personalization experience
The app defines the bar's default cups which are then activated on the bar itself. The app's icons match the bar's, and the colour of each scale echoes the bar's light halo, so app and bar work as one product.
Configuring personalized drinks should be clear and fast. The variability of the icons help the users understand which types of *drinks* they're making, and not just settings up the water.
From a drinking buddy, to hydration tracking
The hydration tracking is still part of the capabilities, together with statistics about the total water consumption. putting the personal before the general was still reflected in this pillar as well.
Final design
From wireframes to product
I managed the visual design process through an external team, while working closely and guiding them for each step according to the values defined. My role included orchestration of the whole experience throughout the different assets. The information architecture, hierarchy and drink model carried into the final design, and previous bar icon language also contributed to visual decisions.
The hardware allowed only relative levels, so temperature is set from Hot to Hottest or Cold to Coldest, and quantity ranges depend on the preset, reflected as clear choices and not as restrictions.
Each drink has an option to count toward the user's water consumption. Water poured for cooking isn't water you drank, so this keeps tracking accurate.
Impact
A focused first version, shipped
Leadership
How I led it
Focus. Turned a broad concept into clear values with the product team, and excluded whatever couldn't be justified.
Structure. Designed the information architecture, drink model, and pairing and settings flows.
App–hardware orechestration. Aligned app interactions, icons and visual cues with the bar's physical interface and hardware limits, while I was leading the workflows for the bar capabilities as well.
Design direction. Directed external studio from wireframes to final visual design, including alignment with bar design.
Partnership. Worked closely with Strauss's in-house product team, which owned the product and its roadmap.
Learnings
What I learned as a UX
Big ideas need proof. Without research and validation, scope comes down to someone's opinion.
Build the MVP around clear values. When evidence is missing, build what has clear value and defer the rest.
Simple can still be engaging. A clear, colourful way to set up your bar created delight without an extra content layer.