Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Moving Interaction Design Off the Desktop and Into the World: Lessons from the Field, BayCHI, Nov 9, 2010
Semelhante a Moving Interaction Design Off the Desktop and Into the World: Lessons from the Field, BayCHI, Nov 9, 2010 (20)
Mais de egoodman
Mais de egoodman (13)
Último
Último (20)
Moving Interaction Design Off the Desktop and Into the World: Lessons from the Field, BayCHI, Nov 9, 2010
- 1. Moving Interaction Design Off the Desktop and Into the World Lessons from the Field Elizabeth Goodman BayCHI November 9, 2010
- 2. The project
- 3. Interaction design has moved off the desktop TranslationAugmentation AugmentationNew service StephenShankland/CNET
- 4. Deliverable Don’t forget the overall presentation! Visual design is here Wireframes are here The project manager is keeping track of budget and schedule
- 5. Intensity of implementation: a broad landscape Deliverable fragility Market horizon Mobile travel app Cross-platform media strategy Prototype clinical tablet Speculative future Near-term strategic goal Prototype magazine reader In the product pipeline Concept vision Specifications for implementation “Working” code Appliance vision video
- 7. Solution: Acting out Allow me to demonstrate
- 9. Challenge 2: Translation between media and platforms Paper magazines Digital magazine working file Magazine sketches
- 11. This device doesn’t actually exist outside of this video Challenge: Representing complexity Mag+ concept video: Berg Design for Bonnier R&D
- 12. Solution: Multiple representations Not shown: Powerpoint presentation with personas Trend map Scenario posters
- 13. So. Why is this important?
- 14. A few conclusions about interaction design, complexity, and deliverables
Notas do Editor
- S02-2010-02-23-IMG_3625.JPG How many people have experience designing and/or prototyping off-desktop applications – particularly ones that are not for well-understood platforms? The point of this talk is not to give you an ideal set of methods that are “the best.” Nor am I going to give you prescriptive “lessons’ in the sense of a sequential series of steps that will help you improve. Instead, what I’m going to do in this talk is examine a set of techniques that people use when they are busy, So I’ll be talking about some lessons I’ve learned about interaction design for These are lessons gained both in my own experience as an interaction designer over the past seven years and also through my own dissertation research, a field study of interaction designers in their native habitat – the studio. How many people have experience designing and/or prototyping off-desktop applications – particularly ones that are not for well-understood platforms? The point of this talk is not to give you an ideal set of methods that are “the best.” Nor am I going to give you prescriptive “lessons’ in the sense of a sequential series of steps that will help you improve. Instead, what I’m going to do in this talk is examine a set of challenges that commercial designers face in practice, and some techniques they use in response.
- For the past nine months, I’ve been studying Bay Area interaction designers in consultancies and corporations. What is interaction design? The specification of digital behaviors – digital systems respond to stimuli from other systems and from humans. I use the word specification very deliberately. First, because interaction design does not necessarily include implementation into working code – in fact, it usually doesn’t. However, interaction designers are responsible for creating representations of how those behaviors will take place and what they mean to users. So they are typically quite concrete and detailed. They are specific. I started out with a simple question: are new technologies creating new challenges and hence the need for new skills? The role of academia Participant observer – I do design, but I also try to address long-term questions and take a broad view As a neutral observer, look for best practices and then teach them This project Impetus comes from my own experience as a working interaction designer over the past seven years and from teaching Treating designers as the users of academic work participant observation method along with interviews Three projects at two companies, and I’m looking for more host sites! Watched work sessions and client meetings. What I was interested in is how decisions are made, Looking for more host sites!
- I’ve also been specifically interested, as the title of this talk suggests, in the way that the attention of interaction design as a profession has been moving from computer-based applications – websites and software – to mobile devices and thence to the world. As a commercial design profession, interaction design is increasingly present in everyday life - through the shaping of websites, mobile applications, consumer electronics, medical devices, environmental controls, and more. It’s becoming a key part of the commercial production of what’s been called ubiquitous computing – computing integrated into tiny devices, objects, buildings, and even people. But I don’t need to tell you about that. I am particularly interested in two consequences Degrees of new-ness Augmentation of existing product, like a dryer with a sensor that automatically shuts off the machine when the clothes are dry Porting existing media to new platform, like a magazine to an iPad Totally new service or product, like an oyster card, with a new business model and accompanying technical and organizational infrastructures Intensity of implementation. Those who work in interaction design know that projects can cover a tremendous range of technical relationships to that future. Credit: screenshot by Stephen Shankland/CNET
- This relationship is often articulated as what we call, a “deliverable. ” Through my research, I began to get more interested as well in how what are often called deliverables – the artifacts that encapsulate negotiated outcomes between two different organizational groups. That is, a deliverable is something you deliver, right? Particularly, I’ve gotten interested in something that doesn’t necessarily come up in academic research: deliverables. (In fact, when I first got a job in interaction design, I was completely confused by the term – my first career was in graphic design, and we didn’t talk in that language) Deliverables are artifacts that two different groups use to communicate. Often, the deliverable embodies explicit agreements between those groups, often shaped by long negotiations. In the case of interaction design, deliverables are particularly interesting because they are usually not the final, working product or service. Instead, they incorporate representations that will enable someone else to create or implement that product or service. So they have to be convincing representations of something – an interface, an interaction, an overall experience that doesn’t actually exist. If you’re talking about a routine webdesign project – like the design of a catalogue for a clothing company – it may be that even though the actual site doesn’t exist, there’s already a well-established genre of sites like it. But in the case of a lot of these new products and services, it may be that there are only a few products or services like it already on the market, so there are few other analogues to convey what it’s going to be like. Deliverables are ways to communicate across boundaries – between organizations, say, or between disciplines. This talk will look at some of the lessons I’ve learned from my own work and from watching others. Some will be particular to interaction design off the desktop, and some will be issues that also take place in web or software design, but are still relevant. Deliverables take us to a problem that a number of researchers and interaction designers have been thinking about for some while in terms of ubicomp: what it means to represent experience. Bill Buxton wrote a book called Sketching User Experiences, for example, in which techniques of sketching are seen as one way to “get the design right and the right design.” The notion of an “experience” and how you represent gets particularly pressing for designers with these new technologies – and these are the lessons I’m going to convey.
- So not all cases are made the same. Here’s how those two dimensions relate to the selection of examples that I’m going to be talking about today.
- This is something that a lot of people have talked about. I’m involved with a conference called Sketching in Hardware. Bill Buxton has a book called Sketching User Experiences, which I recommend. I’m not going to talk a lot about this challenge, because it is so widely discussed. But it’s a real problem in practice, because of the exigencies of commercial work, and because it’s more widespread than you might think. Exigencies: fast, cheap need to get approval from clients - who may be elsewhere (hence, no control over their infrastructure or in staging demos) - who may have limited time in person (hence, it can’t take a long time to set up) The problem: designers and businesspeople understanding and being able to communicate the complexities at work in making these new devices. But I think the larger issue, which we get from fieldwork, is how those questions of representing and communicating the experience of new products and services in bound up in questions of organizational priorities, disciplinary boundaries, time, budget, etc.
- Solution: Acting out, ie, literally handwaving Ex: Making evocative noises to create a mood Ex: Waving hands to demonstrate motion Pro: It’s fast and cheap and works well in meetings Con: There’s a lot of opportunity for misunderstandings
- Solution: Device stand-ins: using one device to represent another Ex: using an iPhone to represent a tablet Ex: using a mobile web device to represent an imagined controller Pro: Quick and dirty Con: Pitfall: devices don’t actually represent each other The jpg that needs to be reviewed on an iPhone screen The clinical information device that really needs to be used in practice
- A common goal is to take an old service or experience and move it to a new platform. That’s harder than it looks – and clients underestimate how hard it is because it seems like all the assets are available. The temptation is to think of it as porting old media to a new platform – or maybe even emulation. Ex: a new magazine e-reader, which takes paper magazines and translates them to a touch-screen tablet. The problem is that a new platform usually demands an entirely use set of interactions, often under very different circumstances than what the original experience faced. Think about mobile phones. They’re not tiny computers, and mobile apps now are designed with an expectation that people will not use them like desktop software.
- Solution: Even clearer metaphors the cake (a metaphor of process) the mountain range (a metaphor of form) Pro: The metaphor helps explain what is to be retained, what lost, and what added Con: The metaphor is a model, and the model is still a simplification. You can still argue about the details. And the devil is in the details. Take the project for the magazine reader. The initial clarity of the metaphor created common ground. But when it came time to actually take existing magazine articles and turn them into a snazzy new experience, there was a lot of work. The clarity of the metaphor actually obscured the messiness and variety of all the possible content types. This happens all the time. What’s interesting here is that even the subject matter experts – the clients – were invested in the simplicity of the metaphor as it was implemented in an initial concept video. This happens all the time, right? But when combined with the previous challenge, it can make it hard to figure out when and where a metaphor is not actually working in practice because it may be hard to see in the prototypes shared at meetings. Lots of writing on metaphors. Oftentimes, it’s seen as a kind of an internal process – the designer has an internal metaphor for the project or the process. What I’m pointing out is that the metaphors come to taken on weight and meaning as means of communication between different groups.
- One of the things that interaction designers are increasingly being asked to do is strategic design – envisioning entirely new products and services that depend on the world being quite different. I’m sure you’ve all seen a lot of concept videos – I’ve pasted in a frame from one above, by the design firm Berg for a new magazine reader device and interface for the Swedish publishing company Bonnier. Strategic design often deals in futures. The normal way of telling stories about futures is through scenarios and personas. But if we’re dealing with new products and business models, then we also have to outline a believable set of infrastructure for the product, and a believable set of economic and social relationships in which such a service would make sense. That’s one of the problems with the futurity of these new projects – to believe in them, you also have to believe in their entire context. Usually, we talk about “context” in terms of individual behaviors. I use my phone at home, that’s one “context.” I use it at work, that’s another. Context includes both – the situations in which they’re going to be used, but also in terms of the complex business relationships that these technologies imply. The design of the product, the design of the services it connects to, and the design of the business which is based around the delivery of these services through these devices. That’s very complex. Sometimes, it can be blackboxed if that’s what the client wants. Note that this video doesn’t explain the underlying technical infrastructures that make it possible to subscribe to a magazine from an e-reader. To a certain extent, it doesn’t need to be, because those technologies are already in place. Ie, there’s the Kindle. One way a lot of people recommend is to make a concept video, because you can communicate a lot of scenic richness. But the question is, how do you represent the assumed infrastructures and business relationships required to actually accept that those stories would happen that way? Photo: http://www.bonnier.com/en/content/digital-magazines-bonnier-mag-prototype
- So here’s one solution. Communicating future cross-platform media experiences Weaving back and forth between multiple representations of “the future” Trend map: the future business and technological context of interaction, told as a story over the next four years Scenario: personal stories Interface mockups Not shown: linear power point presentation; segmented personas The posters were a last minute solution to a real problem: how do you help people keep the stories on the trend map in their heads as they’re going through the linear power point presentation? They contain the scenarios, blown-up interface mockups, and references back to the trend map. Not necessarily new tools – paper works just fine. Instead, what you had was somewhat more complicated choreography on the part of the design team, who had to help their clients move back and forth between the multiple representations during a single meeting. Pro: it’s paper! Con: It’s paper. And it needs explanation. S02-02-2010-08-11-IMG_6018.JPG S02-2-2010-09-29-IMG_6394.JPG
- What’s the point of all this to the designers I studied? It’s in service to creating credibility, and hence consensus, and hence relationships. Or, as two study participants said, Designer: obviously we want to make the client happy, but… Researcher: projects are measured for success, it’s “the margin” That is – of course people want to do good work. But the definition of “good work” is at least partially shaped by how it helps build and continue organizational relationships – and keep their companies alive.
- In conclusion, I want to talk about how some of the complexity of interaction design “in the world” is surprising because it emerges in action, as the product of a dialogue between different groups of people – say, designers, developers and clients One temptation is to say that these challenges are produced by moving interaction design “into the world” – which suggests somehow that designing for a desktop environment would be simpler. It suggests that the complexities I’ve discussed – of prototyping, of translating media, of representing complex futures – are produced unavoidably by “the world” out there; that they’re inherent in the technology. What I want to suggest, however, is that when we follow “off the desktop” interaction design projects in action, we see that these complexities don’t just reside in the complicated workings of new technologies. Instead, they become “challenging” in action – in the changing context of organizational priorities, negotiated expectations, and circumstantial constraints. Here’s a slightly more complicated example: Here’s another example. This designer isn’t talking to me. She’s talking to a client. The client isn’t the room – she’s calling in from her iPhone, which she’s using both to look at the presentation and talk to the designers. This sort of thing happens all the time, right. It’s just another everyday hassle. The designers originally made a document with some helpful animations to explain the interactions…but the client didn’t have access so it had to be hurriedly remade as a pdf. They had to make a new 176-slide presentation in one day. So the client can’t see the animations. And since this kind of interface is a pretty novel one, there’s no common vocabulary for interface conventions to rely on. And the client isn’t in the room, so the quick solutions of acting out and using a device stand-in aren’t going to work. All they have is some movement icons and their own verbal dexterity. Because, you know, deliverables never just speak for themselves. And here’s where I step back and point out that this isn’t unique to ubicomp ixd. But a number of factors interweave to make certain kinds of projects more tricky when designers and clients don’t share a common language. Even when working with powerpoint and paper, we can still be surprised at the last minute by the difficulty of adequately communicating a complex future vision. In this world, perhaps we should think less of delivery and more of choreography. Maybe we need to talk about performables rather than deliverables. They’re not like parcel post, you know – especially in the all too common situations of remote collaboration, lack of common vocabulary, and chronic shortage of money and time. We should think of deliverables not as documents but as instruments – instruments whose effect depends on the skill of the performer. The challenges aren’t necessarily “out there in the world,” and they aren’t necessarily in our lack of tools – they’re in the surprises that inevitably happen when the two meet up.