DYSON UK - 2022
B2C Health, Fitness, Air Quality App & Smartwatch
Context
In 2022, after 6 months as a Product Designer at Dyson, the Design Director Jon Marsh asked me to start leading and managing the creation and delivery of an all-new secret-connected wearable product & form factor. The product vision & end-user experience had no clear leadership and tight deadlines. I became the design & experience front-man of this 120+ people project, and successfully delivered a validated POC of the product on time.
What is it?
ā ļø This product's planned launch is 2024, therefore I can't detail much of it.
It is an all-day Health, Fitness & Air Quality tracking product, that combines an Android/iOS mobile app with a screen-based IoT wearable, having its own OS and set of micro-apps.
ā
āThe wearable product records multiple metrics all day long and provides warnings, notifications, stats & recommendations to the user via the embedded screen or the mobile app for larger pieces of content.
What I did
New Product Discovery - 2mths
-
Drive China/USA consumer & competitor analyses (20+ exploratory interviews) to target Personas & market-fit
-
Drive James Dyson & C-suite approval on MoSCoW prioritized backlog of 50+ embedded & mobile app features
ā
Delivery - 10mths
-
Lead squads of 7 designers, 10 mobile devs, 20 WearOS Watch devs and 3 Data Analysts
-
Development of new UX patterns for the bespoke Dyson watch OS and watch apps
-
Set-up of 15 bi-weekly quantitative & qualitative user validation cycles (usability & card-sorting interviews)
-
Cross-function management (marketing, legal, compliance) to keep the product focused on solving clear user needs amidst daily project shifts at multiple company-wide levels
ā
OKRs
-
Delivery within tight schedule of mobile app FE (50 screens to set-up, view and edit health & workout data)
-
Delivery & real-life testing of a working smartwatch rig with Dyson WearOS & 6x Dyson watch apps
-
9.2/10 end usability testing score, great qualitative user feedback
Illustration-purpose only
120+
Ppl. Project
100+
Screens delivered
2
Dev teams
1y
Involvement
14
Designers
2024
Release
15+
Testing sessions
9.2/10
End test score
PHASE 1 - 2 MTHS
UNDERSTAND.
As a newly assigned Product Manager on this huge project, I had to gather & analyze dozens of data sources, defining our target audience, user needs and product vision, ensuring optimal market fit (EMUC methodology).
0. Product Definition & Origins
The 1st Dyson wearable connected product to launch is the Dyson Zone, an air purifier headphone that also monitors live pollution (cf. AQ value) and live-streams it to the Dyson mobile app. It launched on 02.2023.
ā
I had the opportunity to work as a Product Manager on another IoT wearable device with this unique set of features:
-
An embedded screen with a dedicated OS & set of micro-apps
-
An all-new form factor/product category for Dyson
-
Tracks users' Health, Fitness & Air Quality metrics 'all day long'ā
-
Connected to a mobile companion app that showcases the measure data
-
High-end product
ā
ā ļø To know before reading further
-
I can not disclose any specific details about the product itself, including its actual form factor, design, unique features, direct competitors... I will stay voluntarily vague on these elements.
-
The word 'Product' will combine both the IoT device & the mobile app because both had been designed together as one seamless product experience
-
'AQ' will be used for 'Air Quality', which follows the W.H.O AQ scale
-
Dyson splits the Product Design role between UX & UI, each having its own set of 'specialists' within a dedicated team
1. What are we solving for which market?
"Empower citizens by making the invisible local & surrounding pollution threat visible to them"
This product's main objective and differentiating factor is the surrounding Air Quality (cf.AQ) 'pollution' tracking and the unique value it brings to the users once combined with other health/fitness metrics. The challenge is to bring these data together and make them useful & appealing to users on a daily basis.ā
ā
This Product vision strategy made China the main target market for these 4 reasons:
-
Pollution awareness: Pollution in China causes 2M deaths/y, and air pollution awareness is high. The Chinese anti-pollution solutions market was valued at US$1.5 billion and is expected to reach US$2.5 billion by 2027
-
Large health-tracking market: In 2022, China accounted for over 30% of the global high-tech wearable health-tracking market
-
High-end brand success: China is the world's second-largest luxury market, after the United States. Chinese consumers accounted for 21% of the global luxury goods purchase market in 2022
-
Dyson is highly popular in China: The brand is renowned & trusted for its home air-quality cleaning & sensing technology, which makes customer acquisition for this new product category easier. However, convincing them to 'wear Dyson' outside their home will remain a challenge/risk to measure and tackle.
2. What are our direct & indirect competitors?
Group Commercial established a comprehensive breakdown of existing competitors for each market (China, USA, EU). I became an expert in each of these product categories, by testing most of these hardware & software solutions myself.
ā
Intensive surveys & interviews helped us gather feedback on each one of these competitors (cf '4.Gather user needs & feedback' below)
Health-tracking devices
Direct & Indirect Competition
Smartwatch, smart bracelets, body band. These products cover a wide range of users, from casual, to high-elite sport. It's a highly competitive market
Workout & Fitness apps
Potential Competition
Very market-specific. Stravia and Nike are strong in EU & USA, but Keep is the leader in China with 300M users.
Air quality mobile apps
Indirect competition
These apps are highly popular in China ('Air Quality China' has 10M users). Apple, GG, Samsung now implement it directly within their OS, making competition much harder.
Health-tracking apps
Direct Competition
Leaders are the embedded OS health apps (Apple, Google, Samsung Health), making it very hard to create value as a 3rd party out of their ecosystem.
Air quality tracking devices
Indirect competition
A growing market all around the world with new solutions measuring pollution levels at home and on the go. Flume, TZOA, and Atmo-tube are a few main brands on this growing market.
3. Who is this product for?
Together with the Commercial team, we defined the key user Personas from both perspectives:
-
Commercial-led requirements: profile of customers that we could easily target with ads)
-
UX-led requirements: focusing on the end-user's daily journey, needs, accessibility requirements...
ā
Intensive surveys & interviews helped us gather feedback and daily-life needs for each of these Personas (cf '4.Gather user needs & feedback' below)
Persona 1: Active Citizens
Typical 30 to 45yo active citizen, used to commute, go out and work-out in a busy city environment most of their time. They seak better AQ awareness.
Persona 3: Fitness Enthusiast
20M people in cities run actively in China. These users care about staying in shape, and are happy to use technology to achieve their goal. Outdoor AQ awareness is high.
Persona 5: Fashionista
Typical early adopters users if the product becomes a fashion trend. The visual and customisation aspects of the product experience would matter to them to build social status.
Persona 2: Health Sensitive
246M people in China are sensitive to AQ-related diseases (pollen allergy, asthma..). These users are highly aware of their environment and look for efficient solutions to improve & track their health.
Persona 4: Family Carer
570M parents live in cities in China in 2020. There is a social trend to educate & protect children from AQ exposure.
ā
ā
4. Gather user needs & feedback
Our Chinese, USA, EU User Insight teams ran extensive user interviews and research campaigns based on the various personas established prior:
-
'Day in life' video documentary: In-person follow-through of the Persona's day, covering their daily routine & habits
-
'Exploratory interviews': Qualitative feedback about competitor health, fitness, AQ tracking devices and AQ-awareness perception
-
Large-scale survey: Quantitave feedback about competitor health, fitness, AQ tracking devices and AQ-awareness perception
The device being all-day wear, I defined our Persona's needs at each step of their work days, home time, commute etc...using the multiple data sources listed above. It created a 'Day in Life' user-need matrix for each Persona that was key for this stage of the project. See below a dumb-down version of it:
5. Technical software & design requirements
I had to understand the technical & design requirements of the different platforms the product would be working on. Here are some of the key highlights:
Platform 1: Embedded IoT OS
-
Battery life & Data ping: Getting data from the cloud to the IoT product was extremely energy-consuming. We had to design features that would avoid as much as possible to 'ping' these data sets (GPS location history, weather data..)
-
Form factor usability: The new form factor of the IoT came with its set of new usability & screen interaction challenges that had to be tested and explored
Platform 3: Cloud based services
-
Cloud-based services: Both the IoT & Mobile app would be using Dyson & 3rd party online datasets & services. We had to work collaboratively to ensure the end-user on-screen experience would work seamlessly with these services (load time, data available..)
ā
-
Region-based: These online services would differ from one region to the other (especially in China vs the rest of the world). We had to ensure the features would work/adapt accordingly
Platform 2: IoS/Android Mobile app
-
Use & stream IoT data: Mobile data could get off-sync with the cloud or IoT device. We had to anticipate these edge cases & define how to communicate it to the user
ā
-
Android/IoS: Widgets, design guidelines and other specific requirements and available features from each OS had to be taken into account while building our feature-set later on
Phase deliverables
-
'Product vision requirements': Set the product target personas, technologies, objectives, and their associated requirements
-
'User research, feedback & insights': A sum-up of all the key outcomes from the various user testing
-
'Day in life user need matrix': User need breakdown for each Persona at each step of their day
Phase challenges
The project was already in the work within the Engineering team for several years (sensors & hardware tech dev.). That created a set of employees & VPs that had developed their own vision of what the product should be, which wouldn't rely on any market and user need analyses. Part of my role was to mitigate and explain the design process, by ensuring great communication, transparency & by including these valuable opinions when setting the product vision.ā
PHASE 2 - 1 MTH
IDEATE.
Using all the data, user feedback, business requirements, strategic vision, and competitor analyses gathered previously, I kicked-off a 2 sprints of feature ideations, from blue-sky workshop to an organized & ranked feature set for each platform, to explore and trial later on.
1. Find features & solutions for each user need
The first step was for the UX team & I was to review the previously established "Day in life" user need matrix and come up with blue-sky solutions & features for each need, at each step of the day, for each Persona.
The device being all-day wear for city-life users, it's key to find solutions for each need throughout their work-days, but also time-off, business travel... This document would later become referenced and consulted many times throughout the project duration.
ā
See below a dumb-down version of it - Actual file contained 50+ features (most of it can not be disclosed):
2. Build the 1st feature matrix for each interface
Once I had this library of blue-sky feature ideation covering all Persona's needs throughout their day, it was time to sort & rank them.
Because our product experience would be made out of 2 main interfaces (mobile app & IoT device), it was key to define what experience would we bring on which interface, using the MoSCoW ranking:
-
Mobile app purpose: Used for extensive & proactive past/cross-data browsing
-
IoT device purpose: Used for short-term instant & day-level data browsing, warnings & notifications
ā
A first early technical feasibility & feature ranking pass was made, to ensure no unfeasible ideas would stay in the process. However, the feature proposal would be defined later throughout the iterative trial & error AGILE process.
ā
See below a dumb-down version of the feature matrix created (most of it can not be disclosed):
3. Combine features into meaningful Groups
Once I had a well-structured and ranked feature list, the challenge was to find the best way of combining them into groups that would resonate with users:
-
On mobile: Groups would become 'tabs'
-
On the IoT device: Groups would become 'micro-apps'
ā
That allowed us to organize our work as if we were working on 6 separate Products, each having to be interfaced on both the IoT and mobile app
We ranked and prioritized these 6 groups based on the established Product vision requirements set prior (for example: AQ features were the key differentiating factor of this product, so we made it a main priority).
This Group ranking was different from a feature ranking that would occur later within the Iteration Phase, in which we would focus on each Group individually for 1 or 2 sprints.
Feature Group 1
AQ-related live & past features
Contains live AQ data, historic charts, notifications & other undisclosed features.
Feature Group 4
Undisclosed
ā
ā
Feature Group 2
Health-related features
Undisclosed
ā
ā
Feature Group 5
Undisclosed
ā
ā
Feature Group 3
Fitness related features
Undisclosed
ā
ā
Feature Group 6
Undisclosed
ā
ā
Phase deliverables
-
'Day in Life feature set': User need & associated feature breakdown for each Persona at each step of their day
-
'Feature set matrix': Detailed breakdown of all the features ideas, which data they require, and on which interface (mobile or IoT) they would be most relevant
-
'Feature Groups definition & Prioritization': VP approved list of feature group that would make up the micro-app set & mobile app main content
-
'Workload sizing estimate': High-level estimation of how many screens needed design for each micro-app & mobile
Phase challenges
Organising the features into groups ended up being a strong challenge. The product proposal being a first in the industry, there was no pre-existing products to base our feature-set on. Many of these features could have been combined in many different ways to provide radically different experiences to the user. We would test a few of these iterations in the following Iteration Phase.
PHASE 3 - 1 MTH
PLAN & ORGANISE.
We now had delimited the scale of the product proposal. My new challenge was to create new processes to deliver 100+ tested & designed screens in under 6mths for both the mobile app & the IoT device, within a company structure that had never done more than 10+ screens delivery at a time cross projects. Find below how I solved this riddle.
1. Setting-up new AGILE workflow between teams
This project was the first software-based product ever worked on at Dyson, it implies that very few AGILE design ways of working were implemented.
Part of my role was to advocate and implement them and ensure cohesive end-user experience despite the multiple devs teams, design teams & complex management hierarchy for this 120+ ppl project. That's why I updated the existing VPs Design Review Process, going from a x1 every 2 mths Approval Review to a x4/mth, adapting it to the unique fast pace of this project.
ā
I designed, in close collaboration with the Product Owner and VPs, a seamless and efficient software delivery flow for both the embedded and mobile app software.
ā
The design delivery I built consisted in 3 sets of loop cycles following one another, done for each mobile tab and IoT micro-apps (following the Feature groups approved previously):
-
Concept Validation: Design/validate the feature set & hypotheses made for each micro-app, then hand off to Devs to build the back end
-
Usability Validation & UX Patterns: Design/validate refined mockups, UX patterns & fleshed-out IA , then hand off to Devs for components implementation
-
Look & Feel Validation: Design/validate the UI, colour schemes, animations, copy, GUI, then hand over to Devs to re-skin the existing components.
2. Setting-up AGILE tools
I advocated, implemented and managed the AGILE Jira & Confluence solutions for the design team, for them to be able to collaborate with the Product Owner and Devs much more efficiently than previously.
Here's a high-level breakdown of what these platforms allowed us:
JIRA Sprint, Backlog, roadmap
Jira was my go-to tool to oversee and assign tasks to the design delivery team and ensure perfect synchronisation with the Devs.
ā
By working closely with the Product Owner, we worked in sync. with 2w sprint delivery, refining and grooming the backlog & user stories.
ā
The AGILE rituals allowed amazing work efficiency & involvement from the entire design team.
Confluence Collaboration
It was used for cross-collaboration content & file-sharing. I built and managed the confluence tree structure, allowing designers to get instant feedback from reviews, engineers and managers without losing time in meetings.
Bi-weekly user testing
Together with the Design & Research/Insight team, we established a bi-weekly user testing process which redefined how Dyson trials and validates its product.
ā
Each in-person user testing session was about 30/45m long, with 6 to 12 Participants.
This was done in parallel with quantitative testing using the online Userzoom platform.
Phase deliverables
-
'Project delivery flow-chart': Cross-organisation approved delivery processes
-
'Jira backlog & roadmap plan': An organised & prioritized backlog of Jira epics for each micro-app & mobile app tab
-
'Updated weekly Dyson Design Review process'
Phase challenges
It was a hard but exciting challenge to implement new WOW in a slow hardware waterfall-based structure
PHASE 4 - 8MTH
ITERATE.
Once the Backlog & Workflow signed off, it was time to kick-start the 3 design cycles for each micro-app and mobile app tab: Concept, Usability and Look & Feel. Throughout this process, because the design & dev teams we focusing on small parts of this large project, my role was to ensure we never lost track of our original product vision.
1st testing loop: Feature triage & Concept validation
Using the feature Groups established in the previous Ideation Phase, we now had to challenge these features for each micro app (for the IoT) and mobile app tabs. The goal was to find what the most efficient MVP of this product would look like from a feature-set standpoint.
ā
Find below the key steps we followed:
Concept validation - Step 1
Design low-fid. wireframes
We designed dozens of high-level wireframes for each micro-app & mobile app tab, testing what best combination of data & features would provide the most to the user.
Concept validation - Step 3
Run Concept Validation test
We ran 10 participants' bi-weekly in-person user testings (45m Card sorting, Tree Testing, Concept Validation interviews).
We ran a quantitative survey using Userzoom to quickly find answers to some impactful hypotheses.
ā
We made our User insights team run interviews in Shanghai to get feedback from our ideal market target.
Concept validation - Step 2
Identify & Rank the hypothesis
For each feature, we established a list of hypothesise that would justify its relevance. We then ranked those based on a 'Risk vs. User testing cost' matrix, which allowed us to sort which test to prioritize for maximum impact.
Concept validation - Step 4
Build the back-end
Once the feature set proposal refined & validated, I handed over our micro apps & mobile app epic requirements & user stories for the back end to be built.
In the meantime, the design team would kick off the 2nd testing loop, refining the IA & experience.
2nd testing loop: Exp. refinement & Usability validation
Now that each micro-apps and mobile tab had a validated feature set & wireframe structure, we had to refine the user experience by designing IA, UX patterns and running usability tests for each of the following:
-
Embedded 6xmicro-apps 30+ screens
-
Embedded IoT onboarding journey 10+ screens
-
Mobile app Connection journey 10+ screens
-
Mobile app screens 30+ screens
-
Notification systems
ā
Find below the key steps we followed:
Usability validation - Step 1
Mockups, IA, UX Pattern
The Design team designed the screens and built all the associated IAs. It all came together within a UX pattern component library and its guideline book that rules how the interactions should work across mobile and the embedded OS.
Usability validation - Step 3
Implement in-app UX pattern
The validated & and updated UX pattern components were then handed over to the Devs with annotated wireframes so they could start building the user-facing interface of the mobile app & and embedded micro apps.
Usability validation - Step 2
Run Usability testing
Usability tests occurred bi-weekly with 10 participants and were run in person by myself and the design team. The goal was to validate the usability and interactions of each screen & feature.
To do so, we created our own prototype of the micro apps & Mobile app screens, using Figma or Android Studio.
3nd testing loop: Look&Feel dsg & Perception validation
The last main design step was for the UI, Motion & Copy team to make the UX wireframes look on-brand with Dyson. Here are the 4 areas that we had to deliver at that stage:
-
Embedded 6 micro-apps screens GUI kit
-
Mobile app screens GUI kit
-
Text copy for dozens of languages (feature/data/app on-brand names)
-
Lottie and real-time animations
ā
Find below the key steps we followed:
Look&feel validation - Step 1
UI the UX patterns & screens
UI team created bespoke Dyson brand guidelines for the mobile app & IoT device (colour scheme, typography, iconography..). They applied it to the UX mockups and created a GUI kit based on the UX patterns component library.
Look&feel validation - Step 3
Update GUI & Devs implementation
Once validated, the dev teams would then implement the GUI kit on top of the previously built components, and release it back to us for the POC validation.
Look&feel validation - Step 2
Run user testing
New great visualization ideas came out of this UI process and had to be tested using the bi-weekly testing set-up in place for the project.
For example:
-
Which gauge design was the most accessible?
-
Which 'notification' colour scheme infers what purpose?
-
Which micro-app name resonates the most with users?
4.Full-product POC testing
Because we followed the previously detailed steps in an asynchronous manner for each micro app/mobile app tab, we were regularly getting POC software releases from the devs to review & validate. Those allowed us to run tests with real-time data, which was key in validating 2 elements:
-
Notification cross-app in real-life situation: The notification trigger scheme had to be fine-tuned to ensure the user wouldn't be overwhelmed by alerts
-
Cross-platform navigation: Getting the actual on-device software allowed us to test the IoT & mobile combined experience like we couldn't with fake prototypes
ā
To do so we organised real-life outdoor testing to get realistic pollution events & charts. We ran Gorilla testing internally to provide some quick feedback & and refinement to the Devs to fix.
ā
My implication on the project ended after 1 year, when we successfully ended the project over to the Dyson downstream team, responsible for the launch & software follow-up of the project.
Phase deliverables
-
ā'Un-tested edge-cases': Exhaustive list of all un-tested hypotheses and edge-cases
-
'Design content for Dev': Tested and validated IAs, UX Patterns, GUI kit, screen designs released to the Devs
-
'Requirements for Dev': Requirements & user stories documentation for each feature/epic handed over to the devs
-
'Lottie & live animations': Lottie animation files & embedded code to implement within the screens UI (scrolling animations, icon animations..)
-
'Multi-language main Copy': Main brand-related features & micro-apps names, user tested and validated
-
'Project Risks': Exaustive list of all Project risks (list I managed and kept up-to-date throughout the all project)
Phase challenges
-
We lost our product vision focus by trying to follow user feedback too much. Patching a concept for weeks can make it loose its original purpose and meaning. My role was key to take a step back using all the data and cross-product knowledge to come up with a new solution that would fit the overall vision.
-
We couldn't legally provide the user with actions to take to protect his health (open the window..), which was a real need found in user testing. We had to find ways of making them come up with the actions by themselves
