getting the iot into tesco: internet of things ux for the mass market - iot 14
Post on 17-Aug-2014
2.611 Views
Preview:
DESCRIPTION
TRANSCRIPT
Getting the IoT into Tescoor: IoT user experience for the mass market
Tesco Toton by Roger
Claire Rowland/@clurrBLN Internet of Things 2014
Wednesday, 16 April 14
Hello :)
- Independent UX and product consultant
- O’Reilly author: “UX design for the consumer internet of things” (due end 2014)
Previously :- Service design manager for AlertMe- Head of research at Fjord- Smarcos: EU consortium researching
interusability of interconnected embedded devices
Wednesday, 16 April 14
photo by steven de polophoto by lyzadanger
photo by nickpophoto by david ward
Consumers are a very challenging audience for IoT
Wednesday, 16 April 14
Before I worked in IoT, a lot of my design and research experience was with consumers, and I got interested in how new technology becomes mass market. In my IoT work, I deliberately focused on research and testing with people who were not early adopters, and this talk is informed by what I learned from them.
One thing I definitely learned was that the kind of mundane day to day activities to which many consumer products relate are some of the most socially complex and interesting things to design for, therefore it’s really easy to get things wrong.
In many respects, consumers are the most difficult audience for a complex new technology. Upshot: The IoT is still tech led and still not quite ready for consumer primetime. There are still many technical challenges but there is also a lot we don’t know about design.
Mass market products should- Solve a real problem
people have (value)- Offer a good solution
(desirable, usable)- Come at a cost
(financial, effort) that feels in proportion to the value
Wednesday, 16 April 14
What makes compelling mass market product?
Many examples in home automation going back up to 40 years of systems that never managed to convince people en masse that what they did was worth the money and effort to install.
This is x10 powerhouse for the commodore 64 from 1986, allowed you to control appliances, lights, heating from any phone. this system is nearly 30 years old and we’re not all using it, but those are exactly the same kind of things about which people are still getting excited on Kickstarter :)
UX for IoT is not just UI and industrial design
UI/visual designscreen layout, look and feel
Platform designdiscovery, control and coordination for interconnected devices and services
Service designcustomer lifecycle, customer services, integration with non digital touchpoints
Productisationaudience, proposition, objectives, functionality of a specific service
Industrial designphysical hardware: capabilities
and form factor
Interaction designarchitecture and behaviours per
service, per device
Interusabilityinteractions spanning multiple
devices with different capabilities
Conceptual modelHow should users think about the
system?
Many different layers of design shape the end user experience
Wednesday, 16 April 14
Platform design is concerned with discovery, control and coordination experiences for interconnected devices and services. A complicated one that’s a whole talk in itself... think of it as the UX angle on interoperability.
UX for IoT is different...We don’t (yet) expect Things to behave like the Internet
The average consumer is going to find it very strange when objects take time to respond, or lose instructions.
Wednesday, 16 April 14
In addition to the complexity of the design thinking required, also some inherent challenges putting the internet into things.
We accept latency on the internet. It’s out of our control. We also accept a little bit of unreliability. We know that web pages may be slow to respond, and that Skype calls fail. We don’t like it, but we accept it.
It’s not normal for this to happen in the physical world. We expect physical things to respond immediately and reliably.
But when you put internet latency/reliability into physical objects, that might not happen. Over the internet, your lights might take 2 minutes to come on. We’re going to have to be careful how we design this and what promises we make, or it will just feel broken.
3 key guidelines for successful consumer IoT products:-Solve a tangible problem-Keep the conceptual model simple-Make distributed interactions feel coherent
Wednesday, 16 April 14
There are lots of things we could talk about, like setup experiences, service experience, industrial design, interface design for embedded devices, platforms.
For the sake of time I’ve picked 3 fundamental guidelines that provide a framework for much of the UX:
Solve a tangible problemWhat does it do? Why would I want it?
Wednesday, 16 April 14
In areas where they don’t have expert knowledge or are short on time
consumers need products, not tools
Product Tool
Wednesday, 16 April 14
The majority market is used to buying products that make a promise to solve a specific problem and come reasonably well configured to solve it.
Nest do productisation really wellWednesday, 16 April 14
Leaving aside recent problems with user interaction, the Nest protect advertising is very interesting: it doesn’t talk about connectivity at all, it’s all about how it is a better smoke/CO alarm.
Belkin’s mobile app is good, buta connected socket is a tool that requires users to solve their own problems
Wednesday, 16 April 14
Belkin WeMo has a pretty good UX, but is essentially an example of a tool: something that requires end users to define and solve own problems.
It requires an imaginative leap even to think about what you might do with it. Tools can be powerful things, and empowering more people to use them is a great aim. But they require a lot of attention invested and I’d argue most majority consumers won’t have space for more than a couple of these things in their lives.
This, though, is a great idea
Wednesday, 16 April 14
WeMo Crockpot slow cooker, out this spring
Phone app allows you to adjust temperature, change timings, turn it on and off remotely.
There’s a clear benefit, and the remote control aspect fits perfectly with context of use of a slow cooker: left running in house whilst you’re out.
Simple conceptual modelThe user’s understanding of how it works, and what it can do
Wednesday, 16 April 14
Conceptual models should be simple
Wednesday, 16 April 14
A conceptual model is the user’s understanding of how something works and what it can do.
Connectedness requires users to think about system models
Wednesday, 16 April 14
Connectedness adds in additional complexity. There are extra bits. Some of the infrastructure devices are not very transparent in function: what do they DO? A hub is a mysterious box to many people.
There are more things that can lose power or connectivity and more places where code can run. All of those have implications as to how the system works.
In the case of a lighting system with automated rules that turn lights on and off at different times, in order to predict whether it will still run if your internet connection goes down, you essentially have to know where the code governing those rules runs. If it’s on your phone or in the cloud, then it won’t; if it’s in a hub it will.
Beware the surprise packageTaking a successful mass market product and making it back into an early adopter productScott Jenson, ‘The Simplicity Shift’
Wednesday, 16 April 14
You can try to explain the system model...
BERG Cloud bridge: transparent network comms
Wednesday, 16 April 14
...but users shouldn’t have to understand exactly how a complex system works in order to be able to use it successfully
Wednesday, 16 April 14
You have to explicitly design conceptual models, it’s not just about getting people to understand the way that you have built the system
Learn what they need and design to fit the way people currently think: existing knowledge, behaviours and beliefs
Coherence across distributed interactionsInterusability: distributed UX
Cross-Platform Service User Experience: A Field Study and an Initial Framework. Minna Wäljas, Katarina Segerståhl, Kaisa Väänänen-Vainio-Mattila, Harri Oinas-Kukkonen MobileHCI'10
Wednesday, 16 April 14
vs
CompositionDistribute functionality to suit the context of use
Wednesday, 16 April 14
Tado thermostat has no UI, it’s all on the phone. Keeps bill of materials down as UI components are expensive. Making a good phone UI is relatively cheap. It’s an elegant choice but has limitations: if you don’t have your phone to hand, or it’s not working, or you’re a guest in the house without access to the phone UI, you can’t adjust the heating.
This is the old AlertMe I worked on: a standard thermostat with phone and web apps, which are easier to use (the one you see here looks rather plain as it’s an unbranded version). This means that you, and your guests or other residents without smartphones, can still use it as a conventional thermostat. Both approaches have value in different contexts.
ConsistencyCreate device-appropriate interfaces that feel like a family
Wednesday, 16 April 14
Nest example: rotating bezel on wall thermostat makes clicking noise as you turn it. The touchscreen interface uses up and down arrows to control temperature (rotational controls are inefficient and inaccurate on touchscreens), but still makes the same click.
Continuity
Create fluent cross platform interactions... BERG Cloudwash prototype
Wednesday, 16 April 14
19
2 min delay21
...ensure data is up to date on all platforms if possible
Constrained devices often suffer discontinuities
iphone by daniel, cloud by edward boatman, router by joe harrison, thermometer by ashley reinke, radiator and boiler by axeny virtinsky
Wednesday, 16 April 14
A lot of the knottiest design problems I’ve run into in my work are continuity challenges. It sounds obvious: If i interact with the service on one device, I would expect all other devices reflect that change in state. e.g. if I turn the target heating temperature up on my wall thermostat, you’d expect the new temperature to be immediately reflected on the smartphone too.
But sometimes this isn’t technically possible.
Many heating controllers in the UK are battery powered, and sending data to the network uses a lot of power, so they only connect intermittently. It’s possible to have a delay of up to two minutes before which a command sent from a smartphone is registered by a heating controller, during which time the two devices appear to be giving different information about the status of the system.
This breaks fundamental usability principles.
Good consumer UX for IoT is deceptively hard
A final thought
Wednesday, 16 April 14
Tesler’s law of the conservation of complexity:
As you make the user interaction simpler you make things more complicated for the designer or engineerLarry Tesler, former VP of Apple
Wednesday, 16 April 14
Thank you@clurrclaire@clairerowland.com
Wednesday, 16 April 14
top related