Why productisation, conceptual models and interusabiity are key to good mass market consumer UX for the internet of things. Slides from Thingmonk, 3rd Dec 2013 London

1. A brief guide to
UX for the internet of things
Thingmonk Dec 2013
Claire Rowland
photo by neko
Sunday, 12 January 14
@clurr

2. photo by david ward
photo by lyzadanger
photo by nickpo
photo by steven de polo
Useful, usable, desirable
Sunday, 12 January 14
I'm Claire. I'm a UX researcher and designer from a psychology background. Currently service design manager for AlertMe, heating systems, energy monitoring, security, safety and general
home automation.
I'm here in my own capacity and opinions are my own..
my interest: iot products and services that do everyday things and are useful, usable and pleasurable to use for the mass market consumer. cIOT - until patrick’s talk i didn’t know it had a
name.
i think of it as how do you get this stuff sold in argos/boots/ikea...
when you start looking at mundane day to day activities that might not superficially seem that exciting, you uncover a lot of interesting human problems.

3. Good UX is needed to
get us here
Everett Rogers, Diffusion of Innovations, 1962
Sunday, 12 January 14
not every service is going to be consumer oriented, and it's perfectly valuable to make things that target innovators, early adopters or generally engage people in more than just a passive
consumer role. but if we want iot to reach its full potential, then at some point, we need to find a way of making things that work for even the late majority.
for that, good UX is essential

4. Clear proposition
Clear conceptual model
Good interusability
(distributed UX)
Sunday, 12 January 14
need 3 things for consumer market: either unique to iot or given where we are now, particularly pertinent: clear proposition, clear conceptual model, distributed service-oriented approach to
UX design (interusability)

5. Clear proposition
Clear conceptual model
Good interusability
(distributed UX)
Sunday, 12 January 14
proposition is where the user experience starts: if people don’t understand what your thing does and why they might want it it doesn’t matter how clever your design is.

6. Value
>
Money &
effort
Sunday, 12 January 14
what the mass market wants and needs is good products, that do something of value, for an amount of money and effort that seems in proportion to that value.
I work in home automation... many examples 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 form 1986, allowed you to control appliances, lights, heating from any phone. people are still getting excited on kickstarter about that stuff but
this system is nearly 30 years old and we’re not all using it, are we?

7. product
tool
In areas where they don’t have expert knowledge
consumers tend to buy products,
not tools
Sunday, 12 January 14
we're making things that are cheaper, better designed and easier to use... not always creating clear products.
by a product i mean: 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. witness belkin demo vs
nest protect. nest protect advertising is very interesting: doesn’t talk about connectivity at all, talks about how it is a better smoke/CO alarm.
belkin has a 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 i’d argue that that’s not late majority. in the case of wemo, i’d argue that controllable sockets are a step along the road to a majority product of controllable appliances.

8. Clear proposition
Clear conceptual model
Good interusability
(distributed UX)
Sunday, 12 January 14
conceptual model: concepts, and relationships between them

9. Conceptual model of conventional heating
turns it on & off &
up & down
(bit confusing)
makes heat
(by heating water)
Sunday, 12 January 14
conceptual model of unconnected heating looks like this: box make heating come on. boiler: thing that heats up water. if i’m lucky it doesn’t go wrong very often but when it does it’s
uncomfortable. and when it does i call someone out. box might be confusing and most of us don’t use it well but we vaguely understand which bit does what.

10. Connectedness requires users to
understand system models
• What’s this mystery box?
• Why is my heating system
telling me the internet is down?
• Is that 6pm at home or where I
am now?
Sunday, 12 January 14
connected heating may promise to make things simpler, with simpler controls, but also adds in additional complexity. there are these other bits. what do they DO? hub is a mysterious box to
many people. i’ve tested this stuff.
more things, things that can lose power, connectivity or are in different places? all of those have implications as to how the system works.
why does the heating system email me when the internet is down? does that mean it’s not working? (actually it is, the alerts are sent because some users also have a security system
running on same platform which is dependent on the internet connection)
and is that 4pm in the UK where my home is, or the US, where my phone is right now?
in order to understand and predict the behaviour of this heating system, you need to know a bit more about the system model.
if i’m a user of a common or garden website, i don’t have to engage with the system model. this is why the web is consumer friendly in a way that gopher was not.
there are advantages from having a connected system, but however well the individual device UIs are designed, there are new things to go wrong and an extra layer of stuff to be confused
about.

11. We’ve broken direct manipulation
Sunday, 12 January 14
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. that’s
in a sense, we’ve broken direct manipulation: 30 year old principle in UI design: i act on things and see effect immediately. moving towards a model that’s more like programming: things run in
different places, at different times. level of abstraction that can be hard for people who are not inherently interested in tech.
if we’re not careful with design, risk of what Scott Jenson (google, ideo, apple) calls ‘surprise package’ - taking a successful mass market product and making it into an early adopter product
again
(props to Pilgrim Beart and Alan Blackwell)

12. Designing a conceptual model
!=
Training users to understand
the system model
Sunday, 12 January 14
you have to explicitly design conceptual models - not just about getting people to understand the way that you have built the system
learning what they need and and they have to fit with the way people think, existing knowledge, behaviours and beliefs

13. “My teenagers skulk in their bedrooms.
They’re not out, but they’re not really in
either...”
photo by wendizzle
Sunday, 12 January 14
one of those that i've bumped into a lot is the mismatch between the conceptual model of a lot of home automation, and the way people think about their home lives. for example, we have
this idea of tracking who's in and who's out, that superficially seems logical… but actually turns the home into a big computer that people have to log into and out of and someone has to be
the sysadmin and allocate permissions, and when you put that in front of users you discover that doesn't work with the way people live. teenagers exist in quantum state and permissions
are negotiated and flexible.
sometimes throwing tech at a problem overlooks human issues - creating a system that doesn’t fit with the way people live and expecting them to adapt to it isn’t going to work very well

14. Clear proposition
Clear conceptual model
Good interusability
(distributed UX)
c.f. 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
Sunday, 12 January 14
You’ve heard of interoperability: making things work with other things. There is a parallel in UX: interusability: what UX looks like distributed across multiple devices with different capabilities.
Surprisingly little in academic literature. My favourite model for thinking about interusability is from this paper:

15. Composition
Which devices you have, how functionality is distributed
vs
Sunday, 12 January 14
(related to conceptual model but choices you make affect functionality and UX of system)
http://www.tado.com/en/
example: tado thermostat has no UI, it’s all on the phone. probable reasons: it’s expensive to make a good thermostat UI, (and no-one understands the bad ones), so just make a good
phone UI, which is relatively cheap to do. 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.
AlertMe chose differently: we have a standard thermostat with a conventionally bad UI but also the phone and web apps, which are easier to use (the one you see here looks rather plain as
it’s our unbranded version). This means that you, and your guests or other residents without smartphones, can still use it as a conventional thermostat. It’s less elegant (we didn’t redesign
the thermostat UI, in order to keep costs down), but it doesn’t lack anything you’d expect from a normal heating system.

16. Consistency
Device-appropriate interfaces that feel like a family
Sunday, 12 January 14
nest example: twiddly knob on the wall that clicks. touchscreen: up and down arrow. (twiddly knobs are inefficient and inaccurate on touchscreens). BUT it still makes the same click :)

17. Continuity
Fluent cross platform interactions...
Sunday, 12 January 14
Set goal on phone: displayed on fuelband via bluetooth. (Jawbone, up until recently, had to be synced).

18. ...up to date data on
all platforms
!!possible 2
minute delay!!
Sunday, 12 January 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.
In the case of the AlertMe system, there can be a delay of up to two minutes before the smartphone app is updated. This is because the wall thermostat runs off a battery, and
sending data to the network uses a lot of power so it only does it every two minutes. If it sent it more frequently than that, it would run the battery down very fast. We could make
mains powered controllers, but engineers don’t like those in this country as they are more complicated to install.
So for the time being, the UX is a compromise, albeit a small one as the main use of the smartphone app is when you are not standing in front of the wall thermostat, and 2 minutes
isn’t a long delay in turning the heating on.
The important thing is to ensure that users are as informed as possible about what’s going on.

19. UI/visual design
screen layout, look and feel
Interaction design
architecture and behaviours per
service, per device
Interusability
interactions spanning multiple
devices with different capabilities
Many layers
of IoT UX
Industrial design
physical hardware: capabilities
and form factor
Service design
customer lifecycle, customer services,
integration with non digital touchpoints
Conceptual model
How should users think about the
system?
Productisation
audience, proposition, objectives,
functionality of a specific service
Platform design
conceptual architecture and domain
models spanning products/services
Sunday, 12 January 14
so... UX for IoT. it’s not just about building systems and slapping UIs on things.
many product companies making a platform play... UX involvement in a platform involves thinking about conceptual architecture and domain models. That might be my language, maybe
we’re talking about meta models, from Rick’s talk. Meta structures that help people make sense of the stuff around them and get it working together to do sensible things without spending
their lives on sysadmin.

20. Summary
•IoT is tech centric: we’re still figuring out how to
make compelling consumer products
•When user experiences are extended across
multiple devices with different capabilities, users
need strong conceptual models
•Distributed UXes need good interusability:
• Composition of functionality across devices
• Appropriate consistency of interfaces
• Continuity of interactions across devices
•
PS: There’s loads more. I’m writing a book...
Sunday, 12 January 14
So,that was a brief introduction to some of the challenges.
We’re still figuring out how to do this stuff and there are lots of challenges.

21. Thank you
@clurr
claire@clairerowland.com
Sunday, 12 January 14