Like many technology-driven projects, the project has a number of scenarios that are used to guide its technical work from the end-user perspective. These scenarios will be developed into prototypes that are intended both to showcase the various technologies that will be developed, but also to provide reasons to develop these technologies in the first place by illustrating what people would actually do with them.
Sometimes the focus on technology leads to unnoticed implausibilities in the scenarios and prototypes. It's essential that any such tendencies are counteracted by thinking creatively about people and what they need.
In this post I describe some prototyping techniques we have been using to ensure that the user perspective is a genuine presence in our work.
The MediaScape Scenarios
Briefly, the scenarios are:
1. Extra Media
While watching a Formula 1 race in their living room, Ana and Jon in Barcelona can access synchronised statistics from other providers on their smartphones, which they can also use as remote controls; their friend Kevin can listen to an alternative commentary in English via his phone; any of them can place related synchronised information (for example the statistics) overlayed on top of the TV programme.
2. Quiz
Peter and Eddie play a TV-related quiz together, joining the same game by touching phones; they can play while travelling on their phones, or at home on their TVs; either participant can pause the game.
3. Hybrid Radio
Andy discovers an interesting audio stream online and instructs his radio to play it it. He can transfer it between any of his radios in the house.
4. Social TV
A service knows what James, Jo and Sara are watching and who their friends are; it gives them notifications about what to watch and when based on this information.
For these scenarios there are already ways to solve the underlying need. For example:
- Ana and Jon could find related content by searching on the web. Kevin could find text commentary in English on the web, even if he can't find synced audio. They could read stats out to each other, or share links to them via social media.
- Peter could play a game on his own, if the underlying issue is that he's bored - or he could phone a friend, or chat on social media, or watch the TV.
- Andy could get up and turn on his radio, or listen to the stream on his laptop.
- James could look at a newspaper or the programme guide, or use social media, or phone or SMS his friends to find out what they are watching.
These scenarios, although fully formed, only represent small improvements to the existing world.
The technology that underpins them will hopefully enable future scenarios that are much more revolutionary, that we haven't thought of yet. But for now, because there are existing ways of meeting the same underlying need, if you were making a product that did any of these things, it would have to be very easy to use: there are lots of alternative ways of meeting the need, and there is always an associated mental cost to learning a new technology.
In MediaScape, we are not making products - but we are making prototypes, which we will develop using the scenarios above as a starting point. Does this problem of marginal benefit matter for research project prototypes as much as it does for products? Does it render them implausible?
To answer this we need to think first about what exactly the prototypes are for. A very interesting paper from 1997 called (Houde and Hill) brings clarity to this question by reminding us that it's essential to identify and articulate the purpose and audience for a prototype.
A prototype is not a product ("artifact" in the paper). It's a means to explore and evaluate "design questions" - which can be of various kinds:
"Selecting the focus of a prototype is the art of identifying the most important open design questions. If the artifact is to provide new functionality for users—and thus play a new role in their lives—the most important questions may concern exactly what that role should be and what features are needed to support it. If the role is well understood, but the goal of the artifact is to present its functionality in a novel way, then prototyping must focus on how the artifact will look and feel. If the artifact's functionality is to be based on a new technique, questions of how to implement the design may be the focus of prototyping efforts." [..]
""Role" refers to questions about the function that an artifact serves in a user's life—the way in which it is useful to them."
The prototype can be about understanding if and how it is technically possible to do something, answering questions about the experience of using the system, or answering questions about what role it fulfills in the user's life. Any given prototype is often a combination of all three of these things, but it can be just about one particular aspect.
In the terms of the paper, the role in peoples' lives is one dimension that we have identified as potentially problematic, because the scenarios don't address unmet needs: they represent a different way to meet them, probably one that requires people to learn how to use new technology. Although we don't need to actually change peoples' behaviour (because it's not a product), we do need to demonstrate how the proposed step change in technology will enable real (and ideally dramatic) user benefits, as well as show that the technology actually works.
What's great about the paper is that it makes it explicit that we can and should use prototypes to explore questions about those user needs as well as questions about the implementation and interface.
Below I describe some prototypes we've created so far within MediaScape at the ±«Óătv. I've borrowed a technique from Houde and Hart - placing the prototypes on a triangle, showing where they can be placed with respect to role, look and feel and implementation - in order to help understand the function of each prototype within the project.
Some prototypes are a mixture of these features. The closer the prototype is to the named corner, the more it only deals with that aspect of prototyping.
The point of this exercise is to explain why we are creating prototypes of different kinds and to show what functions they play in the overall project, enabling us to figure out if there any design questions that we haven't answered yet.
Prototypes 1 and 2: Drawing scenarios
A useful and commonly-used way of thinking about how people would use a product or prototype is by drawing a story about it as a sequence of cartoon-like panels. The focus is the people who will be interacting with the products or prototypes. This is a technique we have used heavily within MediaScape, both with the partners in the project, and at the ±«Óătv. Here's a sequence drawn by my colleague Andrew Wood, showing aspects of the "Hybrid Radio scenario" (1), with each panel describing what would happen together with an illustration:
Here's another, also drawn by Andrew, describing a scenario where people interact with similar technologies as the "Extra Media" (Formula 1) example above, but applied to the Eurovision song contest, and this time using post-it notes (2):
Both these scenarios drawings were developed in group discussions: the first after a bout of pretotyping (see below) and the second in a more conventional meeting. Within MediaScape we have also used them as a way to express the initial starting points for each partner from the user perspective.
Because drawings of scenarios are a useful and quick way of describing the role a technology might play in a person's life - how it would be useful to them, and how they might use it - I've placed these prototypes at the top corner of the triangle:
introduced me to scenario drawings when we were working on the , and she drew some lovely ones (for example ). Pretty much anyone can draw a scenario - they don't have to look particularly good (though they can), but they usually help focus the minds of people working on the project on the end user, rather than thinking: "we must implement our technology X".
Prototypes 3 and 4: Pretotyping
Drawing scenarios is a good way to start to include the user perspective, but doesn't give you a physical intuition about the plausibility or otherwise of the role something would play in someone's life. For this we have used a range of techniques that I've grouped under the heading of "Pretotyping". I think it's a particularly useful technique for projects which are about interacting with physical objects.
is a range of methods for pretending - acting out interactions with prototypes before building them with stand-ins that are similar in some way. The most famous example is a story about Jeff Hawkins, one of the founders of Palm, the company that produced a very popular Personal Digital Assistant (PDA). Hawkins carried round a block of wood in his pocket to stand in for the functions that he anticipated the Palm Pilot would do, for example getting it out when he wanted to write down someone's address, even though a block of wood couldn't perform that function. It is a technique most commonly used by designers of potential products to get a sense of the usefulness of the thing they are trying to make.
We have used pretotyping for two purposes in this project, both for the Hybrid Radio scenario. In the first case, we acted out the scenario with people pretending to be devices in order to identify any issues with the protocol (3). One person was the user, "Andy" - another played the role of his laptop, another was the networked radio he wanted to control, another was a networked vacuum cleaner, and others were various radios and TVs on the same network. Giving those items a voice, and speaking their interactions out loud is a way to tease out some of the complexities of a protocol in a way that is visible and obvious to everyone participating. It becomes very clear what each device needs to know and what the flow would be, and helps us think about possible hiccups and extreme cases. For example, what if there are hundreds of things all clamouring for attention on your network? How do we distinguish them and find the ones we want?
This is prototyping to understand the technology, and so we place this near "implementation" on the triangle.
I first came across this technique in the NoTube project, where as far as I know this process was . It is also a more physical version of .
A slightly different variant of this technique brings out the detail of the user interactions with the focus on their behaviour: it is plausible? What would they naturally do? What would they see? We used paper and cardboard and a brief script to make by acting out the scenario.
The physical intuition we got from placing the devices in space and describing the messages flowing between them, as well as what the user would see and do, helped us understand very clearly where usability problems might occur. For example, how do I know device am I talking to? What would I see? What happens when I turn off the device that initiated the interaction?
Interestingly, this technique appears to deal with all three aspects of the prototyping triangle, but in a lo-fi manner. We are still showing the protocol (though it's not the main focus). The look and feel is approximate but is considered, and the role of the system as a whole to the person using it is key to the whole set up. So I'm going to put it in the middle of the triangle, even though it's not an integrated prototype in the sense of something that could be used by real users.
Prototypes 5 and 6: Lo-fi videos
We used a similar technique for a different scenario specifically to help us understand the user interactions. In this case, we created a video about using a physical device to (5). The activity of creating a video of that interaction as a group gave us a very clear intuition that the physical interaction was implausible. I'm placing this prototype about half way between role and look and feel on the triangle diagram, because the elements of look and feel gave us enough information to reconsider the role the artifact would have for people:
Videos are extremely useful tools for prototyping with, because the act of explaining to another person what you are doing helps you to be honest about what it would look like and what would happen. Making our own simple videos (which are just static images strung together with subtitles) helped us understand that some interactions were implausible and some difficult.
Having the videos as an artifact to show people later is also incredibly useful. This applies to many different levels of prototyping - essentially whenever it's difficult to reproduce the prototype in real life (for example because the code isn't complete or likely to code rot, or the props are bulky, or the prototype depends on something in a given location like a broadcast feed or an internet connection, or because it's made of paper and string).
We have also . We took existing videos of people interacting with devices and edited them to pinpoint the significant interactions (6), which helped us analyse which user experience elements were intuitive and which not, and which I place in the "look and feel" area of the triangle:
Prototypes 7 and 8: Code
We also create working prototypes with rough and ready user interfaces to help us understand the technology better. We use enough interface to make them just functional, but the focus is on the technology: how it works, how difficult it is to make it work, and whether there are any pitfalls with using it. Recently within MediaScape we have made prototypes to understand (7) and to make discovery (8). In the latter case, this work enabled us to verify that it was a useful thing to be able to do; so, although this was primarily an implementation prototype, we also learned about roles - so I'm placing it between the two corners, but nearer implementation. The discovery protocols code is closer to a pure implementation prototype.
Conclusions
I've argued that taking into account the user perspective is particularly important in technology-driven projects, because we need to need to demonstrate how the proposed step change in technology will enable real (and ideally dramatic) user benefits, as well as show that the technology actually works.
I've described various prototyping methods which help make us think about the role of the potential prototype in peoples' lives. I've described the MediaScape prototypes we've made so far in the ±«Óătv within the framework of the excellent Houde and Hill paper.
I've also described the role of video as a useful tool for exploring roles and user interfaces, and most importantly for explaining to other people what you are doing, particularly if other prototypes are in some way fragile, or because intentionally or otherwise they will have short lives.
We found, somewhat unexpectedly, that it was possible to do implementation prototyping using acting; that you can learn about roles and usefulness even with a technical prototype; and that it's possible to do a paper prototype that is nonetheless an integrated prototype, covering implementation, look and feel and role.
Here's what all our prototypes so far on one diagram look like:
1. Scenario drawing: "Hybrid Radio" 2. Scenario drawing: "Eurovision" 3. Pretotyping: technical protocol 4. Pretotyping: user experience 5. Lo-fi video: More detail on the radio 6. Lo-fi video: User experience of controlling devices 7. Code: Discovery protocols 8. Code: Chrome extension for controlling a radio device
The main gaps are between role and implementation and implementation and look and feel, which is what you'd expect with the lo-fi approach we have taken. Our next steps are to decide on the design questons we want to answer and the audience for each new prototype.
To try to answer the question posed in the middle of this post - does it matter for research project prototypes as much as it does for products that there alternative ways of meeting the needs described in the scenarios? - I think the answer is no, because we don't have to persuade everyone to use our new technology. We only have to persuade some key people that it's worth a punt. But to do this we do have to get them to see its potential usefulness to people.
Links
The (very) lo-fi videos we made as part of our work on pretotyping for user interactions and roles are here:
You can read more detail about the and the , and about our .
The Houde and Hill paper is available (pdf).
Tristan Ferne has written about and .
Many thanks to for introducing me to the Houde and Hill paper, and to him, and for very helpful comments on this post.