In our last article on Johnny Holland we talked about the ‘interpret’ stage of the Social Life of Visualization. This was where a visualization can be tweaked so that the meaning of the data can be seen in a different way and annotated on so that the individual insights that users create can be displayed. The final stage in the shared storytelling process that will be explored in this article is where the tweaking and annotations made to the visualization are captured so the insights can be communicated to others in the community.

We’ll be looking at the rationale for including capture as part of our design framework such as its role in knowledge management and promoting a sense of community engagement. We’ll also look at some of the implications for designing it in the way we have, including the limitation of not being able to get an overall sense of the knowledge captured very readily.

What is the purpose of capturing?

The purpose of this stage is that when users are able to interact within the parameters of a pre-existing visualisation, they need to be able to store ‘snapshots’ of the visualisation to be able to save their work and communicate their understanding of a specific visualisation configuration. Through this process the visualization shifts from being an individual pursuit (where a user visualises their own data) to a communal process of looking for inisight and sharing knowledge (where many users can work on a visualization together).

The capture process is an important part of the design framework because it allows users to become citizens of the community surrounding the visualization by making contributions to knowledge. Through this it facilitates knowledge management by storing the insights that users have made within data visualizations for later retrieval. Knowledge management is not a new concept, considering that software vendors like Microsoft, SAP and IBM have been producing technology that enables it for more than a decade. However in that time social software has emerged which has precipitated two significant changes in the field.

How is knowledge management developing?

The first of these is that read/write social platforms like blogs, wikis and other social platforms have made it increasingly easy for users to create content, leading to a significant increase in the amount of knowledge generated, and therefore the amount that needs to be managed.
In 2003, the last time a significant report on the amount of knowledge contained on the Internet was conducted, it was found that:

• the World Wide Web contained about 17 terabytes of information on its surface
• instant messaging generated five billion messages a day (or 750 gigabytes)
• email generated about 400,000 terabytes of new information each year worldwide
• and the entire Internet generated 532,897 terabytes in electronic flows of new information in 2002.

In 2007, 281 exabytes (i.e. 281,000,000 terabytes) of information was created.

The second change is that the structure of knowledge that needs to be managed is changing radically, given the free form nature of knowledge generation that social spaces like blogs, wikis and social visualization spaces encourage. Consequently new ways of approaching knowledge management are needed, as opposed to simply tagging documents that are contained within a content management system and performing searches based on those tags.

The way in which knowledge is generated is also changing across a number of dimensions.

The first of these is the workplace. No longer is it always a single place for face-to-face interaction but rather, it can sometimes be an anytime, anyplace network of electronically connected spaces. This paradigm is known as the distributed workplace and is emerging as an alternative to the classic co-located scenario. This changes the way knowledge is generated within an organization, because it becomes more asynchronous rather than synchronous.

The second dimension is the approach. As the technologies have emerged to enable it, knowledge generation has taken on a communal approach known as collective intelligence. This is the belief that pooling everyone’s knowledge on a subject together creates a greater depth of information than if one authoritative figure had worked on it alone. Consequently everyone’s contributions create units of knowledge within themselves that it is also important to capture.

Why is capturing knowledge from a data visualization important?

In specifically tying knowledge management back to the shared storytelling process, being able to see what another person saw is an important way of understanding what previous users working on the data visualisation were trying to communicate. The particular way this process is facilitated through the design is also important. The proposed interface allows snapshots to be collected along with discussion, and is a good way to illustrate the evolution of understanding around a dataset. This method allows other users to see individual contributions to see visualizations. It avoids the chaos that might exist if every user’s contributions could be viewed at the same time. Instead it allows a user to use another user’s work as a further exploration and extrapolation of the dataset.

Example of a visualization state in Many Eyes captured and attached to a user comment.

What else is important about the capture process?

The capture process ties other processes within the Social Life of Visualization together because while comments and annotations allow knowledge to be exchanged and to an extent captured, the nature of a visualization means that without seeing what the original user was seeing while they made those comments or annotations, a great deal of the insight that could come out of the process would be lost.

So capturing is the ultimate degree of sharing within the framework, because it shares the community based work that is taking place around the dataset in a visual way. It creates a trail from the initial visualization that really establishes the visualization’s role as a social object within the community by giving it a rich history.

How can an interface be designed to support this?

To specifically design an interface around the capture process, when a user is commenting on a data visualisation they should have the ability to attach a ‘snapshot’ of how they have configured or reconfigured the visualisation at that exact moment in time. They should then be given the option of attaching a text-based comment to the visualization state that they have created.

From here, another user should be able to select a comment that a previous user has made and the interface should work to reconfigure the visualisation to reflect the ‘snapshot’. From here a user should be able to recognise the contribution that the previous user has made to knowledge around the visualization. They should then be able to make a further contribution based on the work of the previous user.

However the real limitation of snapshots is that they do not provide a good overview of the insight that a community has extracted from a visualisation. It is necessary to look through each snapshot and comment to get a sense of what has transpired, when it would also be useful to get a sense of the collective contribution that the community has made through exploration of the dataset.

Conclusion

This concludes our article on the capture process, where we have particularly paid attention to the importance of knowledge management, because the process aims to preserve ideas and insights generated in other parts of the design framework. It also concludes our series on The Social Life of Visualization. For interaction designers, we feel that this is a change in approach towards visualization; no longer is it about making the most visually appealing and sophisticated representations. Instead this creativity should be constrained to giving back people control over the manipulation and control of their data, and providing a good experience along the way.

We have created detailed interaction design patterns for all the phases that we have discussed in this series of four articles. You are welcome to use them to help your own work. You can find out about the interaction design patterns that we have proposed in more detail at our website.

Background

In 2008 the Australasian CRC for Interaction Design (ACID) was approached by Deloitte Digital for their expertise in data visualization which was being developed through the Loupe Project. Deloitte Digital was preparing its accounting firm in Australia for the introduction of XBRL (eXstensible Business Reporting Language) which would see a significant change in the way business reporting was conducted. Rather that sending multiple reports to different agencies, XBRL would produce one set of data that agencies could draw upon for their own purposes when needed. As part of this change, Deloitte has released an online accounting platform called Accounts IQ which will change the relationship between accountant and client to become an ongoing conversation online. This process needs visualization to make complex business data more easy to understand for the client, and an interface to make this conversation process a good user experience. The Social Life of Visualization is the outcome of our research into this solution for Deloitte.

A year ago UX Book Club kicked off with posts to the IAI and IxDA discussion lists on November 24th, 2008. A Sydney group was announced along with those posts; Canberra, Washington DC and New York followed pretty quickly. And by the end of that first week 28 groups were up and running, and 400 people had signed up to attend.

One year on and nearly 80 UX Book Club groups have been formed in North America, Europe, Asia, and Australasia. A ‘best guess’ estimate puts the total number of events at somewhere around 180 in this first year, and anywhere from 1,500 – 2,500 people in attendance.

As groups have started up I’ve been constantly surprised and pleased by the widespread interest in User Experience around the world. And, more pleasing, has been that these local communities have chosen to come together through the UX Book Club to share and learn from one another.

“It was fairly incredible how natural—how routine—it felt. I mean, here was a group of people, many of whom had never participated in any community event, and none of whom (to my knowledge) had ever engaged in an extrinsically focused book club. The book became the medium for discussion, though the topic remained entrenched in UX and design.” 
- Jonathan S Knoll, UX Book Club NYC

My first real inkling that UX Book Club was contributing something significant to the global UX community was the formation of a group in Israel. What was encouraging was that those events attracted just a handful of people, and yet those folks gained something that was present in New York, Sydney, Los Angeles and London – a connection with other practitioners like themselves, and an opportunity to learn.

Here’s the list of published events at the time of writing:

• 17 November: Switzerland
• 18 November: Dallas, Texas USA
• 19 November: Groningen, The Netherlands
• 22 November: Tokyo, Japan
• 25 November: Switzerland
• 25 November: Calgary
• 26 November: Zuid-Holland, The Netherlands
• 26 November: Ottawa
• 01 December: Sydney, Australia
• 01 December: Glasgow, UK
• 01 December: Brighton, UK
• 01 December: London – LBi
• 01 December: San Francisco
• 02 December: Philadelphia
• 03 December: London – IG Index
• 03 December: Auckland – New Zealand
• 07 December: Perth, Western Australia
• 08 December: Amsterdam
• 15 December: Berlin, Germany
• 16 December: Warsaw, Poland

UX Book Club Sydney, October 2009

So what is it about UX Book Club that has made it such a compelling idea for local UX groups around the world? There seem to be a few consistent themes that emerge when you look at the different groups.

Low cost of entry

By ‘low’ I mean zero. Starting up a local group costs nothing. Attending an event (usually) costs nothing, other than the effort to read a book that, chances are, you were probably considering reading anyway.

Everybody contributes; everybody learns

I was asked the other day “What’s in it for an experienced practitioner?”. I think the format of UX Book Club really lends itself to people of all experience levels. For someone new to the field there are obvious benefits:

• They get told what books to read to help them learn about UX, without having to try and figure that out for themselves;
• They get to discuss the book with people more experienced than them, and gain the benefits of their practical experience and perspective;
• They get to meet other people and connect with the community
• They get a voice. Sitting in a small group, everyone is encouraged to participate and provide their own take on the book. Unlike other professional meetings, UX Book Club isn’t about one person standing up and talking at people – it’s a discussion; a conversation; focused on the book and topic.
• The discussion is engaging (we hear this from every group.)

For the experienced practitioner, the benefits are very similar, but also different. They get to hear fresh perspectives, and ideas from other fields (in Sydney at least, about a third of attendees would consider themselves to work outside the field of UX). And, in talking about the topic with others less entrenched in the vernacular of UX, they need to think about how they communicate ideas and concepts – something that helps them when they’re next in front of a client.

“Most UX people I know are web interaction designers like me, but the book club drew developers, software UI designers, business strategists, visual designers, and various flavors of agency and in-house IAs and IxDs.” – Sarah Mitchell, UX Book Club Los Angeles

Everyone who attends talks about the level of energy in the discussions – people who are passionate and engaged, talking about a topic they work closely with regularly.

The authors show up

UX Book Club Sydney, June 2009

It has been great to see the number of authors who show up – in person or virtually – to contribute to the discussion of the books they’ve written. It was awesome to see Bill Buxton – jetlagged and under the weather – drop in on the Toronto group for their discussion of his book. The guys at Adaptive Path have been on-hand to answer questions about Subject to Change; Russ Unger & Carolyn Chandler have talked about their book – A Project Guide to UX Design – at a number of events. And Alex Wright – author of Glut – made an early-morning call to Sydney to answer questions for them. I’m doing a disservice to some authors, who’ve also made the effort to appear, and I apologise for not being able to name you all. But your involvement in the UX Book Club – beyond the wonderful books you’ve written – has only served to enhance the experience for everyone.

The Publishers have been awesome

Support from the publishers of UX books have been fantastic in their support of this initiative – contributing giveaways, discounts, and encouraging their authors to attend. Rosenfeld Media has been especially supportive, stepping in to help out early and often over the past twelve months. We’ve also enjoyed the support of O’Reilly Books and Morgan Kaufmann – offering discounts to UX Book Club members for books being discussed.

Playing with others

Directly and indirectly, UX Book Club has gained a great deal from the support and encouragement of the IA Institute and the Interaction Design Association. From day one both of these organisations have worked to help nurture and foster the spread of UX Book Club around the world. Our friends in both organisations – in the executive and the membership – have been personally involved in running local events, promoting the initiative as a whole, and providing advice and encouragement along the way. I can honestly say the UX Book Club wouldn’t be where it is today without their support.

And last, but by no means least: each and every one of the 2,000-odd people who have taken the time to read a book, attend an event, and engage in discussion with their peers – these are the heart of UX Book Club, and the ‘secret sauce’ to it’s success.

So, looking forward to the year ahead, I hope to see the UX Book Club continue to provide a forum in which people interested in User Experience can come together to connect, share and learn. If you haven’t attended an event previously, I encourage you to do so. Information on upcoming events can be found at the UX Book Club website.

Thanks again.

After over 2 years of extensive research, Todd Zaki Warfel has released the book “Prototyping: A Practitioner’s Guide”. I talked to  Zaki Warfel about his interest in the area, the surprising results of what prototyping methods practitioners actually use , and how he seeing prototyping being used in the future.

VT: What was the inspiration to write about prototyping?

Prototyping: A Practitioner's Guide

At my company, Messagefirst, we had starting doing more and more design of webapps and things that took advantage of modern technologies like AJAX to improve the user experience. We were finding that as detailed as our wireframe documentation was, it was falling flat when trying to show transitions like self heal and progressive reveals. We needed something that could show and tell the story of the experience better—we turned to prototyping.

How clued up is industry right now when it comes to prototyping?

Not very. I’ve seen a high degree of interest, but from practical standpoint, there’s a very small minority of practitioners doing prototyping as a regular part of their design process. I find it’s most common at the most extreme ends of the spectrum. Based on the research I did for my book, it was something that I found to be more likely in Agile-type shops and really large corporations with hefty budgets like Microsoft. That’s not saying that all Agile shops or corporations with hefty budgets are doing it, but those seem to be two environments where it’s more likely to occur.

Todd Zaki Warfel

While there is interest in prototyping, the two main things that prevent people from adopting prototyping into their design process are that they don’t know where to begin and they have a hard time convincing their client or boss that it needs to be.
There’s this misconception that prototyping has a high cost, adding significant time and financial cost to the design and development cycle, when in fact the exact opposite is true. Not that prototyping doesn’t have a cost, it absolutely does. The thing is, just like anything else, you’re going to pay now or later and prototyping has a much lower cost than paying later. Fixing something in the design process is much less expensive than trying to fix it once it’s been launched. Depending on who you ask, fixing a problem once your system has launched will cost 100-1000 times as much as what it would have cost had you fixed it during the design process.

Getting past the “cost” argument can be challenging for people who don’t have experience prototyping and can’t speak to it first hand. Fortunately, I’ve seen the benefits firsthand and have a number of stories I can tell about those lightbulb moments we’ve experienced with customers and clients that we’d never experienced with wireframes. I can also give our clients examples of how prototyping enabled us to uncover hidden problems, explore design solutions, and make informed decisions prior to launch that we simply couldn’t have done with out prototyping.

People just need to find the comfortable place to jump in and try prototyping, something small with a low initial cost that can provide some value they can show clients in order to make it a regular part of their design process.

One interesting concept in the book was using prototypes for communicating ideas (Robert Hoekman, Jnr. coined it “proto-communicating”).

The standard practice is to either use wireframes with behavior notes and or a spec document. Spec documents are the worst. They’re typically 60-200 pages, mostly text, occasionally include screen shots to illustrate what the text is trying to describe. It’s still a static representation of an interactive and dynamic experience.

Wireframes are a little better for communication, as they rely more on visual representations of the system with behavior notes. But like a spec or requirements document, it’s still a static representation of an interactive and dynamic experience.

Since the dawn of man, we’ve used pictures to communicate. Our first form of written communication was cave paintings—drawings. We are visual thinkers by nature. If I try and describe a system to you, your brain is wired to immediately draft a picture of what the system is, how it might look, the way you move from screen to screen, or state to state. Why not leverage that native visual thinking language?

Prototypes are about show and tell. They’re a visual way of communicating the design of a system. First and foremost, they communicate your design. That’s kind of ground zero.

You did a lot of research into the prototyping tools interaction designers currently use. Did you have any surprises?

Initially, I was surprised at the number of people using Visio and Excel to prototype. Let’s be honest, as a drawing tool, Visio is mediocre to decent at best, but as a prototyping tool, it’s pretty poor. And then there’s Excel. Who in their right mind would ever prototype in Excel? Turns out, someone who has access to it, knows it, and is comfortable using Excel.

This turned out to be one of the biggest influencers in selecting a prototyping method or tool: use what’s available and what you know. The thing is, that as bad as these tools are for prototyping, the worst tool you can try to prototype with is the one you don’t know, aren’t comfortable with, or don’t have access to.

There are a number of better prototyping tools available: Fireworks, Flash, Axure RP Pro, PowerPoint/Keynote, and HTML just to name a few. And while they might actually be better prototyping tools, if you don’t know them, don’t have have them on your computer, and need to prototyping something quickly and have it ready today, tomorrow, or in a few days, then you use what you know. Learning a new tool does have a cost. You just have to decide when you can afford a little downtime to learn that new tool.

Zaki Warfel's Prototyping Methods Matrix

What are your preferred prototyping tools?

Paper and pencil to begin. Every design I do starts with one of our sketchboard templates, a mechanical pencil and a thin felt tip pen. After sketching through several iterations of the design, I typically move right into the HTML/CSS prototyping framework we’ve built. We’ve plugged several different JavaScript frameworks into it: Prototype, jQuery, and most recently YUI. I’m really impressed with the strength of the YUI 3.0 JavaScript framework for AJAX-style transitions and interactions. jQuery is probably my favorite for doing things quickly, but YUI 3.0 has become really powerful.

I’ve also leveraged Fireworks from time to time. It’s a good tool, but not great yet. There’s some real quirkiness with the application (things like zooming won’t work on the window you have in focus until you click on the actual frame of the page). If they’d fix the buggy quirks, it would become a great tool. But my preferred prototyping tools are paper, pencil, pen and HTML/CSS with JavaScript.

Has doing the book changed how you prototype?

I’m continually evolving the design process we use, so it’s hard to say. It did open the door to some new tools that I was aware of, but hadn’t tried out yet, like Fireworks. In the past, I had only used Fireworks for visual design and production of visual assets, but not for prototyping. The more I learned about it, the more I wanted to try it out for prototyping.

We prototype almost exclusively in hand-coded HTML, CSS, and JavaScript—prototyping something in Fireworks is a significant departure from what we typically do. However, since writing my book, there have been a few opportunities where a Fireworks prototype turned out to be the most appropriate approach.

One of the things that did happen along the way, was that our prototyping process evolved to the point of being more and more comfortable creating production-level prototypes. Most prototypes are built with the intent of being a “throw away”—little if anything from the prototype will actually be recycled for production. Personally, I think that approach gives you a great deal of freedom and flexibility. And honestly, it’s the approach I would advocate for most people. Our situation is a little different. Most of our prototypes are created with the intent that eventually most if not all of it will be repurposed for production.

Since we’re creating prototypes that often make their way into final production, our approach is a little different. We use our own custom HTML/CSS framework to prototype. There’s nothing really proprietary about it—it’s all standards compliant HTML and CSS with Prototype, jQuery, or YUI! thrown in for AJAX effects. However, as part of the ever evolving refinement of our design process, I’ve rewritten this framework three times and am currently working with Jonathan “Yoni” Knoll to rewrite it again to make it even better.

I think the book has encouraged me to explore additional toolsets and continually refine our prototyping process and framework.

Are there many things in the design process you can’t prototype?

Not that I’ve found yet. The nice thing about prototyping is if you can fake it. One of my guiding principles is: If you can’t make it, fake it. So, there really isn’t anything I can think of that can’t be prototyped at some level. Some things are easier than others, but I can’t think of anything I haven’t been able to prototype to date.

In nearly every case in the past three years, prototypes have become our documentation. There are a few exceptions, where we need to include some supplemental documentation, say a 10-20 page document to specify some business rules that happen on the backend, which aren’t clear from the prototype. But I’m willing to do a 20 page spec document and a prototype instead of a 200 page spec. It still takes less time to build a prototype and write a 20 page supplemental spec than it would to write a 200 page spec and get consensus on it. And you still won’t know if it’s going to work or not until the system gets into production. Any design based on a written spec is a design based on theory. A design based on a prototype is a design based on experience and practice.

Any design based on a written spec is a design based on theory. A design based on a prototype is a design based on experience and practice.

Any predictions or hopes as to how prototyping might evolve in the future?

My hope is that it becomes more of a common practice in the design process of anyone making products. I know personally how much making prototyping a core part of our design process has changed the way we approach, design, and validate our assumptions. It’s also made our solutions much more creative at Messagefirst. Once we start to see how the system will work, it begins to inspire new ideas. We can also identify issues much faster and earlier in the design process. Those issues create opportunities for more creative solutions. And the earlier you find problems with the design, the cheaper it is to fix them. Frank Lloyd Wright once said “You can fix it on the drafting board with an eraser, or on the construction site with a sledge hammer.” Prototyping is the eraser. All in all, my hope is that I’ve given the community something they find will help them improve their design process, their designs and make it easier to communicate their designs to clients and colleagues. Less pain, more gain.

Frank Lloyd Wright once said “You can fix it on the drafting board with an eraser, or on the construction site with a sledge hammer.” Prototyping is the eraser.

Any other insights about prototyping that you’d like to mention?

Probably the biggest insight is that making prototyping a core part of our design process has literally changed the way we approach exploring, crafting, and validating our design concepts. Prototyping has given us the power to show and tell the story of our design solutions to any given problem rather than just tell the story waving our hands in the air to describe the magic.

I think another significant insight is that reactions we get to from our prototypes from clients and customers is far beyond anything we were ever able to achieve with wireframes and static Photoshop visual comps.

Example of physical prototyping (taken from Prototyping: A Practitioner's Guide)

One last insight is prototyping has not only given us the ability to test out our designs early and often, quickly uncovering issues with the designs, but has also given us a method to inspire new design solutions. It’s not until you start experiencing and playing with the design that we know whether or not our theory will really work. Once we start playing with it, seeing how it works, experiencing it, we often have those light bulb moments of “Oh, now that I see it does that, imagine if we take it a step further and do this…

Prototyping has given us the power to show and tell the story of our design solutions to any given problem rather than just tell the story waving our hands in the air to describe the magic.

Getting the book

Prototyping: A Practitioners guide is available now in paperback and digital format.
Thanks to Rosenfeld Media, Johnny Holland readers will receive a 20% discount on the book with the code JOHNNYHOLLAND when buying it from the Rosenfeld Media website. It is also available via the UX Bookstore.

———-

Images taken from the Rosenfeld Prototyping: (diagram illustrations) Flickr set. CC BY 2.0

All social media involve a dislocation that de couples the act of communication or interaction from its artifact, which is a text or recording. This is a shame, in some respects, but one that creates possibilities that wouldn’t exist if it weren’t for the medium. The medium allows us to be always here and now but visible elsewhere anytime. It has a built in “anyplace, anytime.”

This anyplace, anytime is brought into focus by each of us when we use social media. For us it’s always now. When I use twitter, I use it now. If I read your tweet, it’s now. Your now, which is now “then,” is again “now” for me. In reading your tweets I experience them in my own time, even though they were written by you in your time. On your time.

These different times become irrelevant to the medium, for each user’s activity makes them present. But the differences do have consequences for some of the medium’s particular capabilities. One of these being its way of focusing and harnessing our attention.

Media theory makes the observation that media, or mediated experiences, amplify along some axes of experience while bracketing out others. The phone: voice, and talk. Tv: the eye, and watching. Twitter: the now?

If each of us is in the now but in our own now, then the dislocation and de coupling of a tool like twitter is exacted on the time dimension. We don’t experience it that way, because we’re always “in time.” But we do experience the temporal artefacts, if you will, of the dislocation.

For we in being on twitter, now, we’re paying attention to other people, seeking attention from other people, who are not there now, or not in our “now,” even though the tool makes it seem so. There’s a temporal illusion, if one may mix metaphors ontologically. And I think this may have something to do with the residual practices that develop around attention and which contribute to the attention economy.

I am on twitter now, and for all intents and purposes you seem to be too, or rather, I’m experiencing you now (even though it’s now “past” and “then” for you). If I pay attention, by tweeting, tweeting to you, retweeting you, or even simply by reading/observing (which is paying but not giving attention), then I’m being social. I’m engaging in a social act. That social act connects us virtually, because I’m paying attention to you. And if I tweet, some part of that attention wants to close the loop with you. It wants a response.

All social action, mediated especially, intrinsically seeks a return look, a response, if not from you then some other person. It’s a tacit social principle and basic social binding mechanism, meaning that it goes without saying.

“Goes without saying.” Communication, because it has other people in mind, does a lot that goes without saying. The return is what we want from twitter — and the reason that so many new users drop it. The simplest return is the follow — and the reason so many use following strategies. But talk intrinsically begs the question, makes the appeal, and suggests the response. Talk is structured so that every linguistic statement suggests appropriate, valid, responses. That’s how language and meaning work.

The dislocation of all these attention flows, for we are all in the flow of attention, from the streams that result from them, creates a fundamental social “desire” for relocation, or connection. All these mediated forms of talk are looking for ways to make communication more probable, more successful, and more valuable.

The dimension of time is a hidden dimension but one that we know is there, and which operates at a deep level, because twitter is a tool of now. We may see the streams of others, but we experience them in the flow of our own.

No single user is “special” – or maybe all users are? Either way you look at it, we as interaction designers will encounter contexts of use or knowledge domains out of the ordinary at some point or other during our career. In my experience, designers need not apply magic tools when designing for special situations. It is however beneficial to bear in mind some core differences between specialized use contexts and the mainstream use of a mass consumer product such as a social networking site or a mobile phone. And that’s what I want to focus on in this article.

In the digital work environment of a specialist such as the nurse, designing the patient vital sign monitor requires the interaction designer to use and apply domain-specific knowledge. “Systolic Blood Pressure” is not just a label in a list; you have to know what it means. And then you have to design what it means to the nurse.

So how can we design the best possible systems when faced with these special contexts? How do we ensure that interactive systems for specialized users do not become needlessly complex and difficult to use? This article provides an introduction to domain of specialized interaction design, and provides you with some key guidelines for a successful UX result.

Designing for a particular context

Think of a work arena or professional domain with highly trained users.

• What systems surround the user?
• Are the systems interactive in nature?
• What specific tasks will require a high degree of knowledge when performed?

Any interactive device can be the subject of a “specialized” use context.In the definition used here, the specialized interaction design comes into relevance when a user is subjected to prolonged or intensive periods of use on a particular system. And this is typically as part of a professional workspace. This context requires a highly trained user for operation. It can be the transaction platform of a financial instrument trader, the word processor of a writer, the table of a DJ, the decision-making tool of a surgeon or the steering wheel of a Formula-1 racer.

What makes your user special?

More and more domains of highly trained and demanding users become the subject of interaction design. Many specialized work domains were previously supported by fitting mass-produced systems to do the job; it has however become more commonplace to see interactive solutions targeted for particular contexts.

A special body of knowledge

The training or education of the specialized users is an important factor for consideration. The body of knowledge that can be presupposed for these users gives the designer many advantages in designing an efficient use of the system. To name a few:

• Specific domain symbology standards can contain important data or information, that otherwise would need extensive labeling and explanation;
• Abbreviation or shortening words can make a lot of sense to trained users. This allows for more effective real estate distribution; such as referring directly to procedure numbers or shortname references – the user will know the reference through repeated training;
• Features need not be that transparent – hidden shortcuts and interactive sequences can more easily be learned to support super-usage;
• Guidance and supportive features can be kept to a minimum. This doesn’t mean the system doesn’t have to be learnable.

Use of specialized symbology. Incomprehensible to outsiders but extremely effective to the domain user. Example shows APP6A; infantry, recon and anti-armour symbols.

The body of knowledge that supports the design process can also challenge it. No interaction designer can ever completely understand the work context of a surgeon or a pilot. A system that needs to be easily accesible to a user with multiple years of pre-training or education, interaction designers cannot target in early iterations without support. In addition, the world of the user can be hard to replicate or even physically see or visit.

For this purpose, it is very common to employ in-house domain experts. These domain advisors are not a part of the client product ownership but work closely with the UX and development teams. They are an indispensable part of designing the right solution for the end user.

Trained users and steep learning curves

A core difference when designing systems for special users is how the user accesses the learning curve of the system. A specialized interaction design can often suppose the end user to enter the interactive system relatively high on its learning curve through pre-training or guidance.

This fact allows the designer to avoid supportive low-barrier entry features that similar systems would require when designed for a broader field of users. The reduction in functional redundancy, that might make sense for exploratory use, appears as noise and friction to the trained user. The very design choice that makes an interactive system seem inaccessible to the untrained eye might be what actually makes it highly usable for prolonged use.

This can be seen when designing the overall navigation structure of a specialized system. An effective design will remove most layers of navigation by avoiding steps, wizard-like interaction patterns, states and modes. Multiple systems can be placed side-by-side with positive result. This is why financial traders love multiple displays. Effective design occurs when striving to populate the first layer of navigation as much as possible.

Challenging procedure

Users within a specialized domain will often have developed a rigid doctrine or detailed procedures facilitating task completion. This can be both a help and a burden to the interaction designer. On one hand, a process can serve as a guideline for developing an efficient system since these procedures have been sharpened over years by multiple groups of users to yield maximum output. Best practices are common. For instance, a work hazard checklist can serve as an important tool when digitizing the workflow.

Populating the outermost layer of navigation entirely.

However, the same tool can hinder improvement to the everyday life of the user. In the case of a specific physical checklist, users can be highly resistant to change. Maybe less steps in the operation are needed with a digital device. Maybe they steps can be overlapped or re-ordered with a new interaction pattern. The digital tool might also automate some features. But this doesn’t matter – users have invested time and energy and the current procedure has become a natural and reflex-like part of work.

As an interaction designer, it then becomes essential to challenge the “way we do it” and reach the point of minimum justification for change.

Designing for attention span

Monitor for patient vital signs - focused and very short periods of use.

Considering the attention span of the highly trained user is one of the key contributors to a successful design, and this design approach is not even specific to specialized users. The user directs varying amounts of attention towards any system we design. But for highly trained users, the difference can be more pronounced.

In the case of a system for analysis, such as the vital sign monitor, the specialist has a very low percentage of total work time dedicated to that system. Maybe the user just briefly turns to the display for look-up or analysis, then returns to the main task. The system becomes a supportive system for critical decisionmaking surrounding a different main task. For this, the interaction design must ensure easy access, very low friction and mostly no layers of navigation. Systems for monitoring can use sound effectively (but should be used scarcely) to direct attention.

The air traffic controller workspace - a place of prolonged and intensive use.

Other systems require prolonged periods with 100% of user attention directed towards the system, such as is the case with the air traffic controller workspace. In this case, the design of the screen must apply methods for noise- and stressfree visuals, but it can also be highly effective in the use of real estate. When anyone sits long hours looking at the same screen, small pixel changes are sufficient to indicate change or needed reaction. Combined with specialized symbology, content can be presented in surprisingly compact ways and still make a world of sense.

As we begin to feel a sense of relief that the Age of Aesthetic appeal (thank you iPhone) has finally arrived where touch, sight, and colour also mattered, we are being reminded that we cannot become too complacent. Ux is currently undergoing a silent rebirth that will see massive changes in our focus as practitioners. We have entered the Age of Sustainability and Eco-ethical Awareness – also loosely referred to as “Green.”

Is it a fad?

In my last post I was thrilled to see the visceral reaction of some of my industry colleagues on having a conviction about Usability being a commodity. As someone still practicing and who feels passionate about what I do I welcome a change in approach to UX – a rebirth. Usability, I uphold from the outside looking in, is commodified. The impression that anyone can do it is simply the reality. I again uphold: “No, not everyone can do it.” But sometimes our cues must be taken from impressions that others have of us and and not where we think we are.

The same holds true for the many overworked designers who are being asked to generate wireframes and proofs of concept as if there was no thought to the process. Moving into the age where Functionality and Aesthetics are now married, it is even more difficult to separate traditional usability from design and to say that one isn’t commoditize and the other is so.

The curve ball is now thrown when we now welcome yet another traveller on the road to UX journey. That traveller is Sustainable Design. Call it “green” or “eco ethical” but it is here to stay.

So what does this mean for the field of UX?

With this new paradigm shift, the need to understand how UX practitioners should support this evolution is critical. A more strategic positioning of UX and open dialog on the future of UX is critical. We need to become key drivers in the age of Sustainability and Eco-ethical Awareness,

Consumers have changed along with the global landscape. A recent US Forrester poll indicates that there are growing green concerns with about 25 million (approximately 12%) would pay more for green products with and growing 41%  who, while they are concerned can’t afford to pay more. Consider now – what if the cost of green products was more affordable? How then would design have to change to address a growing demand?

How can UX be roped into a “Cradle to Grave to Rebirth” approach of Product development? To first understand our many possibilities it is important that we have a good understanding of what it all means: “Green”, Sustainable, Eco-ethical awareness” and the fadish lingo that has us all clutching at air. I use the terms interchangeably and borrow from many existing definitions:

In the context of User Experience, “sustainable design” is the philosophy of designing products, space and or services, to comply with the principles of economic, ecological social, and cultural sustainability. In driving the ideas home in our respective companies we need however to think of it as:

strategy that ensures the UX field survives, thrives and evolves by following emerging trends that connects end user research to product design and overall user experience

The goal of sustainable design is to “eliminate negative environmental impact completely through skillful and sensitive design” – the idea that products must aim at being recyclable. A product designed with these new principles should work towards a model of cradle to grave to rebirth.

The applications of sustainable design philosophy range from the design on just about everything from small every day products to larger architecture structure to urban and planning, engineering, graphic, interaction and industrial design. Theses ideals of sustainable design principles also received a great thrust of attention from Janine Benyus’s theories on Biomimicry – a new discipline that studies nature and how we can use designs in nature to imitate and solve designs problems.

Why should we care as Ux practitioners?

In the future we need to be closely integrated across design and research teams to address the new challenges that we face as experience designers. There are many factors that will drive the need for tighter alliances across Ux:

1. Increasing consumer focus on sustainable practices is a trend that favours growth in sustainable customer experience management and the need for advisory and consulting services where User Research can play a role based on previous understanding of users in general.

2. Increasing compliance and regulatory requirements will create an opportunity for designers to drive insightful solutions based on informed research. Embracing this will provide tremendous advantage to those innovative companies that buy in early.

3. Significant opportunity to take share with a focus on sustainable customer experience services, integrated with managing brand perception and a focus on the bottom line.

It is expected in the next few years, as we all come to terms with understanding our role in the Green era, new methodologies, frameworks and ideas will come together to provide exciting possibilities. Currently many of us are in the stage of thought and processing of our new realities. We must collectively and openly discuss the scope of engagement as we forge ahead, with less pliability and more strategic approach. Ultimately our contribution must be tied into the bottom-line.

Top image by Micky

A few weeks ago we celebrated our first birthday by launching a contest. We challenged you to put your best UX tips on Twitter in exchange for beautiful prizes. Now it is time to announce the winners.

The contest we organized was very simple. All you had to do was put your UX tip on twitter and add the hashtags #uxtip and #johnnyholland. We are proud to say that it was a great success. In two weeks time we received well over 300 UX tips, not counting the retweets.

When the contest was drawing to an end we had a bit of a panick: we discovered you can only retrieve tweets from eight days old… Fortunately @yoni came to the rescue: he had made a backup (with Tweetbackup) with all the #uxtip tweets.

And the winners are…

There were funny, useless and even quite stupid tips… but the majority was great. So it took some time to decide what four quotes would be good enough to win a set of Rosenfeld Media books. Meet the winners:

Understanding your client is as important as understanding their audience.
@rainer3

Immerse yourself in creativity outside of your work. You will see differently, be a better problem solver.
@amyhillman

Don’t try to generate every idea yourself. Listen to and refine ideas from wider team. Be a facilitator, not a diva.
@willsansbury

Keep yourself from digital sketches as long as possible to keep yourself open to new directions
@ebacon

The quotes are simple, solid and practical. I would like to congratulate the winners. Start choosing what two books you’d like to receive. We will contact you via Twitter very soon.

View all the tips

We’ve collected all the UX tips and put them on a Johnny page: UX tips.

It’s been a long time since I’ve written anything for Johnny, which I apologize for. I’ll keep this as a short observation piece on what I’ve seen in the last several years and what I’d like to see moving forward. I’m Interested in any comments others might have.

Stereotypes

Sometime ago, I watched a video of a Microsoft developer conference where one of the speakers was discussing the Expression Blend applications; tools to help the designer/developer workflow. When it was time, the presenter turned around, put on a beret, turned back around, and pretended to be a designer. Referencing arrive to work at 10am, doing 15 minutes of work before it was time for an espresso and a break before lunch. The talk and subsequent online video infuriated designers at Microsoft [and other companies], who accused Microsoft of not understanding design; what we did, how we worked, and ultimately our value to the company.

Three years later I saw a talk from a design group at a software company with several other people from Microsoft. The presentation discussed how the group worked separate from the rest of the team (Project Management, Development, QA). How they had a cool office with coffee makers, Eames chairs, and different spacious layouts with designer desks. They talked of taking funny pictures of themselves with mustaches and goofing around with each other at work. They noted it was a “designer” culture.

The irony of the two talks seemed to escape most people…

All the designers at the second talk were enamored and wanted to be part of that team… except me. Perhaps I was the odd man out. It’s not that deep down I wasn’t slightly jealous of the cool space and fancy presentation, but I’ve found that creating a separate culture in a team can create animosity between internal teams and can separate the desired outcome (what design wants) from the real outcome (what the team can build).

All-inclusive teams

The best teams I’ve worked with have been inclusive of all disciplines. In the case of my company, we’re all here to raise the price of our stock and we do that by making great products that sell. In that way, I look at myself as a designer who ships things, not just creates them. Steve Jobs once said “real artists ship.” I’m not surrounded by Eames chairs and typographic magazines. It’s not that I don’t want those things, but I don’t require them to be creative. Great creativity comes from a great team, not great things. It comes from great partnerships, and with those, it determines the quality of the product and experience. It’d be great to have a creative area for my team, but it’s also be great to have a creative building for the entire product team. Why limit it to just a few people?

Great creativity comes from a great team, not great things.

My ask to fellow designers is simple. For those of you who work in software companies, or any large corporation where there is more than a design team. Think of your success measured for what you do with the entire team. Don’t state success as the coolest concept you can make, how much design furniture your office has, or how the design team in particular has a great culture. Don’t segment yourself or think you somehow deserve something special because you’re creative. Create a culture that focuses on the creative and experience. Create that atmosphere, that feeling, for the entire team. Measure your success on bringing great products to market and creating amazing experience. Get creativity from great partnerships. Give other people a chance to be creative, give other people a chance to share ideas and inspiration. Let in the ideas from the developers, from the marketing team… don’t worry that you’re not creating it all. Yes, we are unique, but so is everyone else, and we need to leverage that. A lot of people have really good ideas, and sometimes we miss them because we get so wrapped up in where the idea comes from. Use everyone around you to be more creative. Form those great partnerships, and change the culture.

In our previous article, we focused on the first step to developing a User Experience (UX) strategy by presenting how user stories are generated, themed and prioritised, as a means of helping us to understand the shape of the project (what) and its purpose (why).  In this article we focus on the use of scenarios and paper prototypes to support a rapid and collaborative exploration of potential implementation approaches (how).

An Approach to UX Strategy

The goal of the strategy phase is to ensure that all stakeholders are similarly focused and aligned around project goals, i.e there is agreement in principle about the purpose of the project and the priorities for implementation.  A high level agreement to what the project is, why we are doing it, and how it will be achieved reduces the risk of budget blow outs or conflicts in the design phase by ensuring that all project stakeholders have similar expectations. In addition, it is only through an understanding of the scale and complexity of the project that the design team can accurately, or at least confidently produce a budget or estimate for the project.

Our approach to the development of a UX Strategy is motivated by three interrelated, pragmatic and theoretical drivers:

1. Firstly, getting the client team on board and in agreement during the strategy phase relies on these stakeholders having a shared understanding and vocabulary. Tools like scenarios and prototypes help to externalise issues and make them available for shared conversation.
2. Secondly, they also allow the project team to collaboratively and rapidly investigate options and expose constraints. The tangible and visual nature of these tools allows us and the client team to think, explore and discuss the potential project in a more concrete way by grounding conversations about the project in its context of use. This ensures decisions about approaches and priorities contained in the strategy are appropriate to the opportunities, boundaries and constraints of the particular project.
3. Finally, the third and perhaps most important reason is that tools like user stories, scenarios and paper prototypes frame the discussion about the project strategy from the perspective of the user experience. Doing this collaboratively is an opportunity to expose, explore and align the various agendas and perspectives of stakeholders and work through how they might come together in design. As a result clients are better able to understand the implications of project objectives and priorities, and refine them based on the impact this will have on the potential user experience.

From User Stories to Scenarios

Any of the high level user user stories generated as part of the early strategy phase could be implemented in any number of different ways. Different approaches to implementation will require different levels of investment and be more or less appropriate given the project context and constraints. So, once a list of user stories has been developed (as described in the first article) the next step is to identify the key scenarios. The intention is that by fleshing out a few specific key scenarios (combinations of user stories) during the strategy phase, it is possible to expose enough detail about the nature of the website that we can agree in principle to an approach with a shared understanding of where we are investing our time and why. In our experience fleshing out 4-6 scenarios will allow us to explore enough of the key aspects of the site/application. If not, then this is a sign that the project may need to be divided into smaller phases.

The intention of doing this work is not to find the solution or define the architecture per se, but rather to explore possible approaches and agree on an appropriate UX Strategy. We also hope to expose risks or contradictions between expectations and constraints (e.g budget).

… by fleshing out a few specific key scenarios (combinations of user stories) during the strategy phase, it is possible to expose enough detail about the nature of the website that we can agree in principle to an approach with a shared understanding of where we are investing our time and why… to explore possible approaches and agree on an appropriate UX Strategy.

Selecting Key User Stories

The user stories fall, more or less, into two categories. The first are that those that are simple, familiar or unambiguous enough that we can feel confident about budgeting them and resolving them as part of the design phase. These might include user stories that use common UI patterns that we are familiar with or that we have resolved many times before. The second group are more like ”black holes”. By that we mean ambiguous, complex or particularly unique to the project; if not better understood they will pose a risk to meeting deadlines or timelines in the design phase. Our goal is that by the end of the strategy phase we can a) be sure that they can be implemented and b) put a cost against them.

The process of fleshing out this latter group in more detail allows the scope and nature of the project to emerge through a focus on user experience. At the same time it exposes and challenges some of the assumptions and expectations held by stakeholders, or embedded in existing documentation.

The following is an example of a key scenario from the redesign of a university website:

As a potential student I can find out about the application process, find an available supervisor and apply.

This scenario is derived from these user stories:

• As a potential student I can find out about the application process
• As a potential student I can find an available supervisor
• As a potential student I can apply to study

The example scenario above was chosen because it represents a complex pathway that would be completed by a potential student over several weeks or months. Walking through such a scenario forces us to explore and confront a number of strategic, political, technical and user experiences issues.

Mapping out scenarios as user pathways

Once the key scenarios have been identified and agreed upon with the client, they are mapped out as user pathways.

Initial pathways are generated using a walkthrough process represented by post-its. We take each scenario and ask ourselves what would we would need to provide in order for that scenario to be achieved. We have to hand personas, business objectives, content examples, accessibility guidelines, and any relevant technical specifications to assist our decision making about how people might proceed and what they might need to do so.

Each step gets a post it/sketch to represent it, as shown in the image below. We aren’t working at the level of pages yet, just creating a trail of things that would need to exist in order for it to be possible to fulfill that particular scenario. This process allows us to think about the experience as a dynamic thing that happens over time.

Mapping Pathways

Analysing pathways

All the scenarios are mapped out in the same physical space and in relation to each other. If there is some cross over between the scenarios then that is shown physically by an intersection in the pathways.  It is likely that the pathways of earlier scenarios may have to be adjusted in response to what emerges out of the later scenarios. It is an iterative process and depending on the scale of the site, might take a few days to complete. In the image below, intersections in pathways were exposed via clusters of different coloured post-it notes.

Identifying Pathways

Rather than exploring or defining the approach to design or user experience from the perspective of features, this process allows the shape of the site to emerge through an exploration of user activities. Particular patterns about potential use can then be identified, which feed back into the strategy development process. For example, we are able to see that particular areas of the site, or pieces of content contain information relevant to most stakeholders, while others have value for only a small number. These patterns can inform decision making about priorities for the site and help clients to come to agreement in principle on approaches to various aspects of the project, including where time and money is best spent in the short term.

Drilling down through prototypes

Visualising the user pathways also reveals underlying technical and content needs and raises questions around feasibility, content and functionality. In some cases the issues and questions raised are better understood at a more granular level, i.e how they impact on specific interactions via the interface. Paper prototypes or mock ups are then used to rapidly drill down into these “high risk” areas. The image below displays an example of a paper mock-up used to explore possible ways of supporting a searchable index of university scholarships.

Sketch Prototypes

Seeing the potential user experience mapped out in this way provides the client with a different perspective on the project and this allows them to discuss the project the different ways. For example, this process will  expose how a scenario or user story, currently prioritised by the client team translates in design into a potentially very complex requirement, or requires the availability of a certain set of content not currently available. It can expose tension or conflict between a priority objective and what it would actual take to make that happen.

Often at this point, project realities begin to sink in and project teams are forced to realistically assess what could be achieved in the allocated time frame and budget. The visual pathways, mock ups and paper prototypes become visual and tangible aids to explain the issues and options, and support discussion, negotiation and resolution about appropriate approaches and priorities. We have found this technique is very effective for generating and supporting constructive discussions with the client when decisions about priorities are needed. The client has the opportunity to understand the impact of various decisions and requirements about technology or content in relation to the user experience. This supports the development of design principles and guidelines, and helps clients come to an agreement on approaches to particular aspects of the site or application. It can also lead to a revision or shift of emphasis for the project objectives.

The process of thinking through actual prototypes provides these stakeholders with a new way of seeing and new language for describing what is most important. As a result the client team is better placed to decide and describe the most valuable outcomes and confidently direct resources towards the most important elements of the project.

Summary

Creating an effective User Experience Strategy requires the alignment of perspectives such as technical, business, content and brand with that of the user experience. In this article we have described how we support clients to develop a User Experience Strategy that takes into account all these perspectives, based on an understanding of how it will translate into design.

We believe that a core part of developing a design or User Experience Strategy is about interpreting how ‘abstract’ business goals are translated into a specific design project. Scenarios and prototypes are light weight, visual tools that can be used to assist clients to rapidly envision the potential experience for users. They bring a tangible quality to conversations that can otherwise be ambiguous, allowing team members to collaboratively think through project goals and approaches to implementation. They force us to deal with the concrete issues of use in situ, provoking and facilitating critical conversations about overall strategy, opportunities and constraints prior to moving into the design phase. Most importantly they frame questions and decisions about functionality, brand, content and technology in relation to the impact this will have on the potential user experience.

As designers, we deal with users perspectives and the concrete situated issues of use as part of our daily practice. These collaborative tools enable the user perspective to sit at the centre of the discussion and decision making for our clients as well.

Acknowledgments
The reflection on methods outlined in this article was largely made possible through project work completed on behalf of Digital Eskimo, a social design agency in Sydney whose Considered Design methodology makes embracing these methods and approaches possible. We would also like to thank our clients UNSW, Melbourne Journal of International Law and Inspire Digital and our project partners Zumio and Redrollers for their generous commitment to sharing the design experience and process, and to all the participants who give time to our projects.

After 10 years in the field, I woke up one day to realise that my service as a UX practitioner had become a commodity. Usability had become the ‘in thing’ and everyone could do it and show that their products were better than the competition. Usability as a buzzword, populated Product Lifecycle processes in many organizations. So it comes as no suprise when the general attitude of stakeholders these days is one of a shopper saying: ‘One McUser Experience with usability fries please.’

Usability as Commodity

Usability, as a practice, has evolved over the years with the primary goal of understanding the product use by ‘representative users.’ Around the same time our field shed its more academic title of “Human Factors” to eventually become User Experience.  We started focusing on the overall experience a person had as a result of their interactions with a particular product or service.

The term User Experience for the most part has been adopted as the operational title for many firms and other in-house teams encapsulating interaction design, user research and visual design. In some organizations the groups evolved to include other peripheral groups such as audio-visual designers and in rare instances brand & marketing. Nonetheless what is evident is that field as practice has become a commodity.

We aren’t rare anymore

A working definition of commodity means “a good for which there is demand.” But these goods are produced without qualitative differentiation across a marketplace. I will take creative liberty to also add to the definition and include “service” as well.  Today across the board, it seems, that “anyone can do usability” – harkening to Chef Gusteau’s motto from the movie, Ratatouille, that “anyone can cook.”

Like usability, UX is also slowly becoming commoditized. As a practitioner the evidence is blatant and often disturbing. As companies add visual and interaction design to their stable less attention is being paid to the the quality of the designs. For proof of this only look at the mobile field where it seems that every mobile phone is slowly beginning to look the same in aesthetic appeal. The absurdity of this is more evident when seen in analogy to plastic surgery where the surgeons craft of redesigning body parts has evolved into a store front where someone can ask for a J-Lo behind and a Halle Berry nose. But perhaps this is the nature and end game of design as we know it. Or is it what happens when Right Brainers are thrust into a Left Brain environment with the only goal of design production.

And we wonder why Designers are often of a melancholic nature… I feel the sudden urge to scream back at Gasteau that in fact: “not everyone can do it!”

From Clicks to Sexy

Incidentally in the last year I have had four different job titles as my peers and I continued to remold and refocus to stay relevant in the technical space. This fluidity of titles signals the ever-present lack of comfort we feel, where we constantly have to justify our collective existence as necessary appendages to development teams. And if you are a UX professional who has never had your value questions, I stand corrected and ask: “How can I join you in this mystical world?”

Today UX is once again on the verge becoming as institutionalized commodity of the technological landscape. Earlier our focus shifted from purely functional to both functional and aesthetic. But is that the end? When the first iPhone was released in the US in 2007 – the technological design space was like “Whoa.” Apple brought sexy back in stroke of creative genius by turning a little box into the most desirable piece of metal and plastic on many minds. Time magazine even went on the name the iPhone “Invention of the Year” in 2007. With the debut of Apple’s iPhone just about everyone in the industry started wondering how they could also make technology sexy.

A friend of mine, then working at Microsoft, called me wondering if I knew any designers who would be interested in working on new server designs. They wanted to make the products more desirable. “Servers?” I asked, just completely puzzled and blown away by the impact one little sexy device was having. Designers had arrived. We had entered the age of Aesthetics in Technology. Usability and UX in all its sentience had come a long way…Baby!

What had happened was that UX morphed to understand, not only the functional aspects of product use, but also the more aesthetic and experiential parts of product design. A few years back the most critical aspect of user experience was lessening the number of steps in an interaction. “How can we be faster and more efficient?” was the prevailing question of the day. In the post iPhone launch CEOs everywhere were hushed up in boardrooms using the “S” word, asking questions like “How can we create a sexy solution?”

But now we have reached the point of aesthetics, and there’s already the feeling that it’s a commodity again. So we have to keep on evolving. Fortunately the next traveler on the way to design paradise has arrived, but more about that in my next column.