Round Edges

Interaction Aesthetics versus Visual Aesthetics

[Infragistics] Joel Eden — Sun, 28 Feb 2010 18:01:00 GMT

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 When people talk about “aesthetics,” usually they are talking about how nice something looks visually, for example when a client tells you they want their website to be “aesthetically pleasing.” Well, there’s a lot more to aesthetics than just visual beauty…take a look at the following definition for aesthetics from the Merriam Webster online dictionary:

“a particular taste for or approach to what is pleasing to the senses and especially sight”

Aesthetics have to do with human perception from all of the senses, including how it “feels” to interact with something (e.g., as a result of physically touching an artifact, or moving your body through a space).

I use the term “interaction aesthetics” to refer to the qualities of a design that lead to the feelings, emotions, and the behaviors that result from these more bodily types of interactions. An important element of these types of interactions to note is that they happen over time. This is why when we talk about interaction design, and user experience design it is important to not forget that interactions and experiences happen over time (even if just for a brief moment while someone moves their mouse from one area to another).

Contrast this with “visual aesthetics,” which is a term that I would use to talk about the qualities of a design that lead to feelings, emotions, and behaviors that result stopping and being more deliberative about the visual aspects individually. When we stop and deliberate about these types of visual qualities of a design, we’re noticing things in a much different way than when we actually use the same designed artifact for a real world activity. This is where the danger occurs of clients asking for “better looking” designs, without realizing the potential negative implications of focusing only on visual aesthetics.

So why does this even matter?

We don’t stop and deliberate about visual aesthetics when actually using a tool to accomplish an activity…we are more likely to notice the interaction aesthetics during actual use. So there’s a bit of a trap you can fall into…when evaluating a design by looking at it, it is easier to notice, and therefore focus on attributes of the design that are completely different than the attributes of the same design in use. More generally, humans don’t stop and deliberate about most actions as much as many designers think…this is why if you ask people what they do and how they do it, you are likely to get a very convincing story that in most cases will be far from what actually happens.

Consider this screenshot of a website for an interior design/architecture firm. Many people think this "looks nice," but it's very hard to use...you need to spend a lot of effort just figuring how to get to information, not only the first time, but every time. The little vertical bars lined up near the bottom of the page are the navigation; as you hover over each, the navigation text shows up in the middle of the page. This is an example bad interaction aesthetics, but what many think are good visual aesthetics ("it looks nice") because you are forced to move your mouse to bring up the text, then move your eyes to a different area to see the text (assuming you know the text should be there), then repeat for each possible navigation item until you find what you need. This also taxes our weak human memory by forcing us to try and remember which little vertical bar represents which item (users won't be able to do this, so they'll be forced to play the game of mousing over each bar every time they come to the site):

Many would say that craigslist.com that has good interaction aesthetics (e.g., you can efficiently get to the info you want with a small number of clicks and mouse movement in a top-down and left-right flow), but I've heard many people complain about poor visual aesthetics (e.g., many clients have told me they would not want a design that looks so "plain"):

Amazon.com is another site that allows you to quickly find what you're looking for (products and information about products), and it has very good interaction aesthetics (buttons are just where you seem to move your mouse). In many cases, it seems that Amazon has anticipated where you expected something (this is a result of good design). But again, I've heard many clients say that amazon.com is too busy, and they would never want a visual design that looks like that (long pages, use of orange), but these are all things that you don't really notice in use...you're too busy being productive:

The goal of good user experience design is to end up with artifacts that are useful, usable, and desirable…the most important word here is “and;” we want to end up with designs that have good interaction aesthetic qualities and good visual design qualities. When people use the things you design, they aren’t having separate experiences, e.g., one interaction with the visual design, and a different parallel interaction with the interaction design; they are having one single, unified experience. It is only the designer who separates out these aspects and discusses them. What we want to design for is beautiful designs that also have great interaction aesthetics.

So, how about an example of something that has good interaction aesthetics and visual aesthetics? The pricing page for Basecamp from 37signals is a good example of using good visual aesthetics and interaction aesthetics together, in a way that create a single, unified experience. The visual design is not over the top (I wouldn't call it "beautiful," but it's good as far as web app marketing pages go), it uses colors that are pleasing, and most importantly, the visual design hierarchy guides your attention to key information (the most popular pricing plan, info useful to compare plans are given stronger treatment, and the sign up buttons are easy to notice):

The concept of “preattentive attributes” (I’ll cover this in detail in a later blog post) is one example where the two can blend together, for better or worse…basically, because of how our visual perception systems work, certain aspects of a design get your attention whether you want them to or not, before you actually spend cognitive effort or think about what you want to notice. You can use visual design to take advantage of these types of attributes, or your designs may suffer without you even knowing (you want to make sure that the visually appealing aspects that draw visual attention are moving that attention to the right places). That extra bit of color the client demands may interfere with the overall visual hierarchy of your design (e.g., using extra color and weight for headers of information may draw too much attention away from the actual information).

Going back to what I started with about the difference between attributes we notice during use versus attributes we notice when we stop and deliberate about how our designs look, of course users may notice the visual aesthetics (e.g., “oh, I like how this one looks better”), but that doesn’t mean that you have to use this information to drive your design. Many things that look good during this kind of non-use deliberation actually serve as distracters when a user is trying to get something done.

Creating Successful Style Guides - New post on Johnny Holland

Amy Quinn — Tue, 16 Feb 2010 19:46:00 GMT

An article I wrote titled Creating Successful Style Guides has just been posted on Johnny Holland. Johnny Holland is a prominent interaction design community website that has regular features on user experience. In my piece I explain what makes a good style guide and provide some guidance on how to effectively create a style guide. I hope you find the article helpful!

Telling a Good Story with Interactive Line Charts

Amy Quinn — Tue, 02 Feb 2010 19:31:00 GMT

The New York Times does a great job using interactive graphics to tell a story. Recently the New York Times reported on the details of the United States 2011 budget proposal and how the projected budget deficits may affect US policies and power in the upcoming years. As part of this article, web designers created an interactive line chart that shows how US budget forecasts match up with reality. This animated line chart is a great example of how interactive graphs can tell a story that words alone cannot tell.

The first view of the line chart gives a snapshot of the past budget and budget forecasts. Tooltips provide detailed information about individual data points on the chart.

Additional steps in the chart animate and illustrate how budget projections are often incorrect regarding deficits and surpluses. The user is invited to examine individual years through using the slider below the chart.

The later steps in the chart outline possible reasons for inaccurate budget projections, such as changing assumptions about the unemployment rate and the overall health of the US economy.

As you can see, these interactive line charts tell the story of budget forecasts very well. They clearly illustrate a history of inaccurate budget projections and possible reasons behind these errors. In addition, the interactivity and animation found in these graphics engage and entertain the reader.

I hope you are inspired by the great work the folks at the New York Times is doing as I am. I recommend you explore their website to see what else they have produced.

Label Alignments in Long Forms - New Edition of “Ask UXmatters”

[Infragistics] Tobias Komischke — Tue, 19 Jan 2010 04:09:00 GMT

UXmatters is a peer-reviewed web magazine about the complete breadth of user experience. I like their professionalism and their spirit. I published a couple of articles last year there. They also have an “Ask UXmatters” column where readers can send in questions and experts submit their answers which are compiled and presented by the UXmatters editors.

Today’s edition revolves around the topic of label alignment in long forms and I was one of 7 experts to contribute my 2 cents. Read it here!

Blog series: User-Centered Data Visualization. Part 2 - The Pizza Effect

[Infragistics] Tobias Komischke — Tue, 05 Jan 2010 20:31:16 GMT

In one of the recent editions, Time magazine featured this graphic:

The underlying data set is pretty simple. It consists of just 8 numbers which are used for four target/actual comparisons: how many swine flu vaccinations 4 organizations have requested and how many they actually received. And still, the way the data was visualized is problematic.

Estimating the area of a circle is hard. The area of a circle grows quadratically with the radius. You double a circle’s radius and the area gets four times as large. You may know this from ordering pizza: the difference between a 14-in pizza (medium) and a 16-in pizza (large) doesn’t really sound significant if you just look at these two numbers. After all, it’s just a 2 inch difference. But eating a large pizza is quite a different challenge than a medium pizza – the effect of the area growing quadratically with the radius.

Columbia University requested twice as many vaccines than Goldman Sachs. This is very hard to see in the circle sizes: with both red circles being the same size (showing that they both received the same number of vaccines), Columbia’s large dotted circle does not look twice as large as Goldman’s – but it is. That’s the pizza effect. Were the actual numbers not shown below the circles, the visualization would be not very expressive. Because estimating the area of circles is so difficult, it's also tough to compare the size of the red circles against the dotted circles for all of the organizations.

Here’s one suggestion to visualize the data in an easier to interpret manner:

Because it’s much easier to estimate the length of a bar than the area of a circle, this graph makes it easy to see that Columbia ordered twice as many vaccines than Goldman – even without data labels next to the bars. It's still a challenge to estimate the number of received vaccines for Goldman and Columbia. A logarithmic scale could resolve this problem, but people have hard times understanding log scales (see the first blog of this series).

People often say that bar charts or column charts are too standard and therefore boring ("not sexy"). These chart types are standard because they are superior to other ways of visualizing data. There are still ways (within limits) to make them attractive, but from a user-centered design perspective I believe that usability has the top priority.

Here’s another interesting fact that neither the original visualization nor the bar chart reveal. It doesn’t seem like it was the intention of Time to focus on this, but since the ratios between requested and received vaccines are shown, it’s straight forward to calculate the actual value which then makes it very easy to see which of the four organizations got better off than the others. Here’s what the result looks like:

Again I didn’t put data labels next to the bars. Not necessary. It’s obvious that the cancer center and Goldman Sachs have approximately the same ratio between requested and received vaccines – roughly 5% and that’s a third of what Citigroup got and twice as much as Columbia. It’s interesting that, unlike pie charts, bar charts require you to think about how to scale the x-axis. I put it to 100% max to show the distance between the optimum relative return (100%) and the best achieved relative return (17%). So the message is that none of the four organizations got a good portion of what they had asked for. If I had put the max on the x-axis to 20% it would’ve shown more clearly the differences between the organizations. So the message had been: Citigroup got a much higher relative return than the others. Which scaling is better? There is no right or wrong answer. It depends on the underlying question at hand and what you want to express. Doesn’t this demonstrate how manipulative data visualization can be? You betcha.

More blogs in this series to come!

New blog series: User-Centered Data Visualization. Part 1

[Infragistics] Tobias Komischke — Sun, 22 Nov 2009 23:25:00 GMT

One of the trends in UI design is data visualization. With data volume and complexity continuously rising, data visualization becomes more and more important as a means to translate data into information and further information into knowledge. Edward Tufte, who is one of the best known visualization experts out there, says that good graphical treatment of data can be found in scientific journals like Nature while more popular magazines oftentimes feature bad visualizations. What’s good and what’s bad? To me, the quality criteria are meaningfulness first and attractiveness second. A visualization is meaningful when it’s valid (in the sense of true) and understandable. It’s attractive if it’s appealing and intriguing.

Time Magazine has a long tradition in visualizing data about all sorts of things in life. They vary the way they depict data and so sometimes I find their data visualizations better and sometimes worse. In this blog series I will use some of their work together with visualizations from other sources to share some thoughts about data visualizations.

Earlier this year Time had this graphic that puts the number of unemployed Chinese migrant workers in perspective with the total number of migrant workers, total number of the labor force and the Chinese population.

Pretty complex stuff. It’s multiple part to whole relations, so one number is part of another number. When I saw this graphic I thought it’s attractive. Yet, it took me a while to understand it. The intersections stand out because of the darker color so they draw some visual attention. Turns out, that neither their position nor size have any meaning. They merely try to convey that there is a relation between two bubbles/circles. Based on that one could think that there is no relation between circles that don’t have an intersection. But the 20 mio unemployed migrant workers are part of the Chinese population. Both bubbles are so far away from each other that this relation is not easy to see, nor is it easy to compare their sizes.

I think there are a couple of other ways that would be more understandable. How about this:

This visualization places each bubble inside another one so that the part to whole relationships are easier to understand. All bubbles are also placed on the same basis which makes it easier to compare the sizes. OK, at least easier than the original graphic. The problem is that it’s hard for people to estimate sizes of circles, so using bubbles in this chart was a bad call from the beginning. I will write about this in more blogs to come. For now, how about using a single stacked column to show the same data:

Because it’s easier for people to estimate the height of a bar than the area of a circle, this chart should be easier to visually read it. As a side note: purists would probably argue that the width of the column does not convey any meaning but still requires you not only to estimate a height but an area which is a harder task. Anyway, the column shows that despite the large absolute number of 20 mio, the unemployed migrant workers only make up a small fraction of the total labor force and a tiny fraction of the Chinese population. In fact, the number is so small that it’s actually hard to see on this chart. The Nature magazine way of mitigating that scaling issue would probably be to use a log scale, but see for yourself how easy or hard to read the result is:

Now the small number of the unemployed migrant workers is stressed a lot against the huge number of the Chinese population. Same data, totally different look and I think the vast majority of Time magazine readers would have trouble understanding this. I generally don’t use log scales for that reason.

Also check out a video on Pixel8 that discusses this data visualization example!

More blogs in this series to come!

HCII2009 & BASTA2009

[Infragistics] Tobias Komischke — Fri, 02 Oct 2009 18:20:00 GMT

Part of what we do to stay up-to-date is attending technical conferences. It’s great to learn what others are doing, what topics are hot, and also to get feedback on own work and thoughts. Here are some notes on two conferences that we attended, one that's geared towards UX pros and one towards developers.

In July Joel and I attended HCII2009 (Human Computer Interaction International) in San Diego. It’s one of the central events for UX professionals out there. Typically, there’s a mix of industry folks and folks from the universities. Joel gave a very well received talk on wow to ensure that UX findings actually make it into the product. I gave a presentation on the topic of integrating UX into a company. We also had a booth in the exhibition area where we demoed Quince, our UX pattern explorer. So there were plenty of opportunities to get to talk with folks. Here are some random notes from the conference:

There was a full session, run by Aaron Marcus, on UX strategy and corporate maturity. Unfortunately, my presentation was not in that session although it would’ve fit in there very well. Anyway, a couple of maturity models were discussed and even though they were rather similar, they provide a very powerful tool to not only communicate what should be done to grow UX in an organization, but also to track the progress. Aaron presented the results from a survey that he conducted, asking leading enterprise software companies (incl. IBM, Microsoft, Oracle, SAP, Siemens, Oracle) about their UX practices. One of the findings was that in most cases UX professionals don’t do any programming. Another one was that in most surveyed companies UX is separate from development. Sound trivial? Maybe so for UX pros, but definitely not for A LOT of companies out there. And that’s about corporate maturity. It’s a long way from point zero to fully operational and integrated UX teams (Jakob Nielsen talks about many years).
Among our neighbors at our booth were several eye-tracking companies (SMI, TOBII and others) and a lot of presentations included eye-tracking work. One guy from Japan reported on an analysis of eye movements when users browse multiple search results pages on the web. His findings were that results on top of the 2nd page are looked at longer than the results at the bottom of the first page. It’s not that users would not actually scroll down to the end of page one, but they seem to apply the simple heuristic that items on the top are more relevant than at the bottom.
For fans of touch screen applications there was an own session that presented some interesting data on the size of UI elements. The ANSI/HFES standard 100-2007 suggests that the minimum button size on touch screens should be 9.5mm x 9.5mm. One presentation that reported on the development of a touch screen app for people with motor control disabilities came to the conclusion that button sizes for this population should be at least 20mm x 20mm and that this sizing would be generally more appropriate for any users. This reminded me of the epic text size discussions: sure, the larger the font size (in limits, of course), the better the legibility. Yet, at the same time you cannot display as much content on the UI. Same thing here. So my take-away was: for public kiosk-type apps 20x20 makes sense, but talking about PC apps (e.g. a Dell XT2 running Windows 7), it would be very hard to follow through on that size. What about the Microsoft Surface? I’m not sure. I guess it depends on the application that’s running. And the Surface is not only multi-touch, it’s also multi-user.

Last week I attended BASTA, which is a .NET conference in Germany. Totally different audience obviously. We had a booth there as well and it was very interesting to talk with folks about their work and needs. Here are some random notes from this one:

Many topics revolved around moving existing applications from one platform to another one (e.g. WinForms to WPF). So people wanted to get an update on our controls suite.
In terms of UX, folks were more interested in how to train their developers in UX methods and processes rather than bringing in external consultants to do the work. I gave a presentation on how to get from an information architecture to a screen design and had deep discussions about that afterwards. Last year, my presentation was after the free beer started. This year, the free beer started after my talk. Big difference!
Markus Egger gave a great presentation on the power of styling in MS Expression Blend. He was showing how he used styling in a WPF application that had like 150 forms. He created styles in Blend that define the complete look and feel for these. For example, for the labels and fields in the forms, he defined everything in a style so that he only needed to throw the labels and fields in there without positioning or any other treatment and the style defined the rest (layout, alignment, padding, colors, fonts, … all the properties involved). So in the app he showed, styling was a productivity tool primarily and an aesthetics tool secondarily.
Last but not least: different from last year’s BASTA, this time the all-you-can-drink beer was served in 17-ounce mugs. Last year they had the political correct 34-ounce mugs (after all, BASTA coincides with October Fest). Not sure what this was all about. A sign of the recession? Or did people take home too many of the 34-ounce mugs last year? :-)

It's So Hot - Sink a Drink of Aqua

[Infragistics] Peter Meany — Wed, 26 Aug 2009 15:49:00 GMT

Nestling into the "dog days" of August, musing where did the summer go? Think positive dude, football ahead. But still I slip back to June, when the mornings were cool, and summer stretched ahead in an endless expanse, like the feeling you had on the last day of school. This past June, I had this same "schools out forever" feeling, so nicely described by Alice Cooper, when we finished the Aqua reference application which mimics a Health Information System (HIS). But OMG, I do miss the fun from working on Aqua, so let's "sink another drink (of Aqua), it'll give me time to think". I decide to revisit the Aqua application and get a refresher on WPF, UX, ADO.NET, Live ID, Azure and the coolest control around, the Tiles Panel Control. This control allows the useful interactions that any doctor or nurse would love to use.

So, I lounge back into the mineral-laced 114 degree "lobster pot" here in Pagosa Springs, Colorado (forgot to mention I'm vacationing in an area known for its hot springs) and turn on the Making of Aqua Video. I watch as Aqua grows from the mere notion of a reference app to a full blown interactive system, which is usable as any real application currently deployed in modern hospitals today. The fluid movement of the UI panels as they expand and compress, providing the right information at the right time for the doctor, the dazzling visual design and easy access to charting, the realistic data retrieval from the cloud, the presentation of X-Rays in the carousel, the chat I have with an expert clinician......now this is quality UX. I can only think of one term to describe it (with thanks to my daughter Emma), its got that "boom boom now, that boom boom pow".

I them move to Aqua's home (Healthcare. Codeplex.com) where I download the source code again onto my personal laptop. Lots of info here to help you learn, besides the download. There's 3 Hands-on-Labs that allow a view inside Aqua and remind me why the MVVM pattern worked so well here with WPF. Looking at the UI code for the Tiles Panel, I think of other verticals that will surely benefit from this control. Lots of them. I retrieve X-Rays from Blob Storage and realize the full potential of Azure for easy, quick, and inexpensive data access and storage. So many features, so many opportunities to learn, and all for free.

Finally, I use Aqua, imagining I'm a doctor and they have just wheeled Michael Jackson in. Aqua enables me to quickly access just the info I need to save him. The King of Pop trots out to an adoring crowd gathered outside the hospital!

You Can Quince, Too!

[Infragistics] Ambrose Little — Wed, 26 Aug 2009 14:02:27 GMT

Thanks to everyone out there who is using Quince and leveraging it in your daily work. We couldn’t have asked for a better reception and the continued usage and comments we hear speak to Quince as a valuable reference tool for people.

But it was never our intent to put Quince out as a finished product—as something we are claiming is done. The body of knowledge around patterns is constantly growing—new patterns are being discovered, old patterns are being refined, and every day people are building new solutions based on patterns. We made Quince with the intention of inviting you—yes you!—to participate and help build out the UX patterns body of knowledge. You don’t have to think you’re an expert to contribute!

Quince may seem a bit finished—nearly of the patterns in it today have three stars. That’s because we were relying on the existing body of proven patterns as a starting point for Quince. It is by no means to say that every pattern needs to be perfected before being proposed. In fact, it’s quite the opposite—the star ratings, the “I Use This,” the “This Could Be Better,” and the examples are all there and open to you, the community, as a means for us to collaborate to come to the best possible knowledge.

So please, don’t let the finished-ness of the patterns in Quince stop you from proposing new patterns. You don’t have to personally make sure your ideas are fully baked. Here are some ways that we can work together to help each other out using Quince.

Propose a pattern!

1. Just Sign In:

2. Choose Propose a Pattern:

3. Download the template, write up your pattern, and propose it!

That “all” there is to it! :) And there are much easier ways for you to build out the community body of knowledge, such as…

Share Your Thoughts!

When you’re looking a pattern (and signed in ;) ), just click “I Use This” in the “From the Field” section to show that you use it. If you have something to add about how you used it—what worked in your case, just type that in. Similarly, if you want to suggest how to improve it, type that in under “I suggest…” and propose your revision. You can also vote on if you agree with others’ revisions or think their comments were helpful.

Share an Example!

1. Choose I Have an Example:

2. Then just upload your example, comment on how it implements the pattern, and provide a source URL if you like:

When I share an example, I say I Quinced it. You can Quince, too! :)

Discuss!

And don’t forget, if you have a question about Quince or something you want to submit or UX patterns in general, feel free to post in our Quince forum.

MSDN Webcasts on Complexity and User Experience

[Infragistics] Tobias Komischke — Thu, 16 Jul 2009 13:11:00 GMT

We published two webcasts on MSDN that focus on the way user experience design can help users cope with complexity. Check it out!

Summary:

Technology is advancing and complexity is increasing – that’s not necessarily a bad thing. But we have innate cognitive constraints that limit our capabilities to effectively cope with complexity. Also, if a system is inherently complex, it may not be possible to hide its complexity entirely on the UI. Nonetheless, there are powerful methods and techniques that allow to present UIs in a manageable way for users. Some of them are:

Provide a clear layout (balance + symmetry)
Do not display too much
Base your design on a grid
Show what’s signal and what’s noise
Group elements that belong together and separate elements that do not belong together
Externalize memory
Show things to select from rather than expecting users to recall them
Select the chart type based on aesthetics ***and*** human cognitive abilities

Summer Drink: UPA Highlights, Shot of Lewis & Clark, & a Twist of Dylan

[Infragistics] Peter Meany — Wed, 15 Jul 2009 19:55:00 GMT

In 1803, Thomas Jefferson commissioned the Corps of Discovery, to be led by Meriwether Lewis and William Clark. They were asked to explore the land obtained via the Louisiana Purchase, a deal that doubled the size of the United States, adding a vast parcel of land stretching from the Mississippi River to the Pacific Ocean.

In mid-June of 2009, I set out on an exploration of my own to Portland, Oregon and visited some of the same locations explored by Lewis and Clark. My expedition, the Corps of Meany, was to the Usability Professional Association’s (UPA) (note they are considering a name change) annual conference on User Experience (UX). I hoped to learn about the latest work and advances in the UX field and see what the leaders in the field were thinking these days. Moreover, I personally thought that some aspects of UX were changing, and was hoping to better understand these changes. And then I could use the changes to improve my work.

I don’t know about you, but I feel overwhelmed at times by all the new technologies and their associated complexities. Although it’s simple now to access info of any kind, sometimes there’s just too much info coming at me to allow a reasonable comprehension. My cognitive capabilities have really not changed all that much from the mental capabilities of Lewis and Clark back in 1803. But while our famous explorers faced wild animals, unknown terrain, and wild Indian tribes, I face Twitter. Pick your poison.

Conference Highlight

The conference was well attended by over 500 people, a good sign for these economic times. Another good sign was my initial experience after registering, for as I reached into my tote bag to obtain my badge, my hand rested on a cool-looking flyer on Quince, the UX Patterns Explorer.

I found the conference offerings were “hit and miss”, not unusual for a conference that tries to cater to both the novice and the expert. So, I’ll provide a few of the highlights of my “hits”, the sessions where I really learned something new, but my main focus here will be on the keynote by Jared Spool. I’ll blog further on the other highlights in future posts.

The reason I focus on Jared’s talk is that he posed a few simple ideas and principles that are universal in my opinion to any software endeavor and everyone needs to seriously consider implementing now, even if the first steps are baby steps. I believe the more that people hear these principles, the quicker they will become part of our everyday work. So, I’ll describe the gist of Jared’s ideas, followed by the actual principles.

Jared began by asserting that the UX field was clearly experiencing a transformation. Over the past 20 years, UX work has achieved many successes, removing user frustration with poorly–designed software and products. But now was the time to delight people and focus on the full product experience, not just usability.

UX work is operating in a different product space now. And some of the traditional UX methods might not work so well in this new space. For instance, how would one approach a UX assessment of Twitter with its millions of users? Would you conduct a usability test? Or maybe an expert review?

As Jared spoke, the lyrics from Bob Dylan’s song Times They are a Changin (of course, sung in Bob’s nasally voice), drifted into my head, “Your old road is rapidly aging. Please get out of the new one if you can’t lend a hand, for the times they are a changing.” I thought, well I can lend a hand in building this new road to developing better UX and damn it, let it start with me spreading some of Jared’s ideas as I related to them, and then by working these principles in my day-to-day work activities.

Spool continued by comparing caterpillars to worms. Both are useful for sure, but caterpillars change into butterflies and delight, while worms are just worms, living a contented life of eating dirt and helping some of us catch a fish now and then. What do you want to be?

As those of you that attended the last UX training session know, part of the UX process focuses on UX assessments or critiques. Spool wants to move the sometime role of UX professionals from being critics to coaches, from just pointing out problems to actively working within a team to find solutions. (As an aside, Jared took the opportunity at this point to directly “diss” Jakob Nielsen, one of the leaders in the UX field as an example of how one can be too much of a critic rather than a coach. Jakob had published a comment to the effect of “the answers this group of designers supplied were as good as flipping a coin for the solution". This type of criticism sets the UX field back years contended Jared, especially when it comes from a leader. Jakob sat just behind me with a poker face, looking like Lady Gaga during this “trash talk”. Clash of the Titans. But to be serious, everyone does recognize Nielsen’s many contributions to UX, and I suspect these two fellows enjoy poking fun at each other.

Valuable UX Principles

Finally, Jared described 3 critical principles or attributes that in his opinion were critical to the success of a UX team and their work. I believe these attributes apply to any team and all should think about implementing some of these concepts. Let’s do it now!

Shared Vision, 5 years future - each member of a team should envision the product’s UX five years from the current date. This vision is integrated; everyone is on the same page and knows when they are taking baby steps on the road to that vision or when they are taking steps away from the vision. I say, this is hard but the message is invaluable, to look beyond the current day-to-day problems and ensure that the team has a common vision; otherwise we are doomed “to sink like a stone” (more Dylan).
Strong Feedback Methods – look not only towards the future, but gaze back at where you have been. For instance, has anyone on your team spent a few hours watching people interact with your product? Now, I know that I have not done enough, and correct me if I am wrong (and dudes, I’d love to be wrong here), but I suspect not enough UX practitioners have watched one of their customers using their cool products on a regular basis. So, big time improvement opportunity here. I can say that my UX team is taking steps in this area though and the management team has been supportive. We are working on obtaining feedback from our customers on their total experience with our products. Stay tuned and get involved.
Embrace Failure – it’s not unusual to take the conservative approach that will allow one to be somewhat successful, but won’t likely dazzle anyone. Better than failing right? Shame! We want a culture that views failure as an opportunity to learn. Embracing failure just might keep the reasons for that failure fresh in our minds and avoid repetition of the conditions that led to failure in the first place.

More Highlights

Below is a quick sample of other sessions I attended. I’ll try to add to these synopses in future posts, along with info on some of the other sessions I attended.

SketchFlow – Microsoft’s new addition to Expression Studio is designed to allow UX professionals and other designers to easily produce sketches and early prototypes of user interactions. The tool looks promising, but clearly the success of the tool depends on its ease of use and integration into the development process. I really want to use this tool before I can judge its worth, as you all know; it’s a lot different to see an expert demo a tool compared to actually using it yourself.
Personas – Experts in developing and using personas as part of the UX process presented their views based on practical experiences. The one panel member who attracted my attention was Tamara Adlin, who I later learned had conducted a workshop here at Infragistics a few years ago. She started off by stating that based on some of her consulting experiences, she had changed some of her methods for developing personas within her UX work. Although she didn’t mention any companies specifically, I would have loved to participate in the session that occurred here, I can only imagine that the interactions were quite “interesting”.

She’s found that many participants in her persona workshops don’t really know what they want and it’s important to establish a common understanding of business goals, brand goals, value propositions, the problems that the personas will help solve, and the differences between marketing and UX personas.
Unmoderated Remote Usability Testing – This type of UX assessment is relatively new but is gaining an increased amount of usage when your product has a large number of users in remote locations, and the intent is to obtain some quantitative (time to perform task)measures as well as qualitative measures (attitudes). This type of testing is geared to web-based, not desktop app's. And it’s applicable to situations where you don’t have to tightly control a users’ environment.

I saw a lot of benefits to this assessment method as one can quickly and efficiently get measures of users’ full experience with a product, especially useful for comparing products or alternate designs. There’s a variety of tools out there that allow one to collect data from a large number of users (hundreds, thousands) and a free tool developed by Tom Tullis is available. I am going to be looking into this method further to see if we can use it to help assess some of the behavior patterns of our customers when using our products. And of course, with any assessment, it's best to use a few different methods to help one understand the big picture.

Corp of Discovery vs. Corp of Meany

So, you might wonder whether I think my little adventure was as successful as the Lewis and Clark Expedition. First, I think it’s clear that the name of my expedition was more creative, I mean, Corp of Discovery is a fairly obvious name.

Lewis and Clark returned with detailed maps of a vast unknown area, found new sources of natural resources, identified dozens of new plants and animals, and initiated relationships with new Indian tribes.

I returned with a confirmation of my initial sense that the UX field is undergoing a transformation and is continuing to evolve, for “UX is like a shark, it has to move forward or it dies”. (This is not a Bob Dylan quote, I got it from a Woody Allen movie where he talks about love.) Like Lewis and Clark, I have a broad-brush direction on how to embrace this UX transformation and make it work. But I also know that the way to continued expansion of great UX into more products is to be out on the trail of the explorer, learning followed by concrete implementation. Understand, then design well.

Obama, Healthcare & Aqua

[Infragistics] Peter Meany — Thu, 21 May 2009 16:49:00 GMT

At Monday's meeting at the White House -- which President Obama called a "historic" and "a watershed event in the long and elusive quest for healthcare reform" -- healthcare industry leaders pledged to trim healthcare costs by 1.5 percent annually over the next decade.

At a similar meeting last month at Infragistics, leaders also embarked on a historic, watershed event as we began work on our first healthcare “product” named Aqua, a CRM reference application for Microsoft. (Note that the President was planning on attending our meeting too, but an emergency with Bo the “first” dog caused him to cancel at the last minute. More on this emergency later.)

Aqua Overview
Aqua illustrates a variety of best practices and techniques using Windows Azure, MVVM, WPF, and ADO.NET Data Services so that you can employ these technologies in your own work. Over the next six weeks, stay tuned for videos, hands-on labs and blogs describing how we built this reference application. And as we move into the first days of summer, you can take a break from the sun and the surf to explore the completed application and the controls that comprise it.

We decided early on that Aqua would mimic a healthcare product. Healthcare is in the news everyday and the field continues to focus on the move from an all paper environment to reliance on electronic records, which will vastly improve patient safety and care outcomes as well as improving efficiency. Even though we were developing a reference application, we knew that in order to demonstrate best practices design and coding and optimize the UX, we had to approach this as if we were developing a product that would indeed be used by doctors and nurses and allow optimal treatment for patients.

UX Activities
We used a classic User Centered Design (UCD) process to ensure that Aqua was usable and appealing for doctors and nurses, allowing them to quickly assess the condition of a patient and prescribe care within the sometimes hectic environment of a modern big city Emergency Department. To qualify the scope of our reference application and design a quality UX, we first sought to understand our users and their requirements. We then started to produce simple designs, initially, just scribbles on a white board which then turned into concrete wireframes. We validated our designs early- on and then throughout development to continually identify improvement areas.

We had an advantage as a few members of the team were experienced with healthcare software development, so we already had a good understanding of the context of use for Aqua, that is, an understanding of the users, their tasks, their equipment, and their environment.

Overview and Early Design Video
Check out this video, Overview and Early Design for Aqua, which gives an overview of the project and the flavor of our early design activities from concept to wireframes. You'll also have a seat in some "top secret" design meetings. The video lasts about a half-hour.

Finally, in case you were still wondering about Bo, the first dog and the nature of the emergency..., it really was not too critical, Bo had a slight “accident” on the polished hardwood of the presidential bowling alley, and Barack was pressed into cleanup service. Just another tricky day.

He’s promised to take a look at our work though over the next several weeks, hope you do too!

Bill Buxton : Sketching versus Sketchiness, what’s the difference for UX design?

[Infragistics] Joel Eden — Tue, 12 May 2009 18:30:03 GMT

A couple of weeks ago, Bill Buxton gave a nice talk at Princeton University, and a bunch of us from Infragistics attended. Bill is a great speaker and each talk he gives is different, based on where the talk is, usually covering just a little piece of his experience, and usually only covering content from just a few of the chapters in his book, Sketching User Experiences. I recommend checking out this list of online talks of his, which includes this recent Princeton talk.

In this blog post, I wanted to briefly discuss what I think is one of his most interesting points, the idea of sketching versus sketchiness. A coworker of mine recently read Buxton’s book on my recommendation and had this interesting comment for me after finishing the book, “his book isn’t about sketching…I thought from the title it would be about sketching…it’s all about user experience design.” What an interesting comment. I think that as soon as people see the word “Sketching” in the title, “Sketching User Experiences,” it’s safe to assume that this book by this well known “designer” is going to be about artistic sketches and how to use them when designing to make cool pictures of design ideas; many of us who don’t feel that we have inherent, or learned artistic skills probably shy away from this, or at least think this isn’t for us, because we can’t draw well.

Well, what Buxton is talking about isn’t sketching in the artistic, or graphic arts sense (he even says he can’t draw well himself!). He’s talking about the concept of “sketchiness.” So how is this different from sketching? A sketch is a quick, not too thought out, doodle of a concept, and we know that when we are done doodling, we’re likely to just throw away the paper, or napkin that it’s drawn on. Sketching is a great way to work through lots of ideas quickly, without putting too much effort into creating high fidelity versions of whatever the idea is.

Sketchiness is all about using this same idea of low fidelity, throwaway representations of ideas more conceptually, regardless of the materials we are working in. Sketchiness is part mindset, part design process. Experience prototypes, clay models, mockups of buildings, UI wireframes, and of course quick paper sketches can all be sketchy. The important idea is that we are getting ideas out quickly and in great numbers. When we’re creating something with sketchiness, it should be easy to tell that it’s not done, i.e. that it invites critique. Usually, the creator of the sketched out idea isn’t even too sure of many aspects of the idea; only through making an external representation of the idea, does the idea become more complete. Buxton talks about the power of ambiguity in sketches; with the proper holes still unfilled in a sketched idea, interpretation is necessary. This interpretation is necessary not only by someone seeing a design idea for the first time, but also by the person who created it. This ambiguity is a by product of taking a rapid, sketchy mindset when quickly putting out ideas, that leads even the creator of a sketch to get new ideas when looking at it over time. A high fidelity UI mockup on the other hand does not invite critique or (re)interpretation; it instead says “I’m full of finished, mature ideas…I’m done.”

I mentioned that one of the keys to sketchiness in design thinking is rapid creation of lots of ideas. Someone once said that the way to have a good idea, is to have lots of ideas. Buxton is really big on the idea that when designing, you should have at least 5 alternative ideas, or solutions for any given problem, even smallish problems; and you need to be equally vested in each of these 5 ideas…i.e. no cheating by creating one idea you like, and then four more quick ones just to have a total of five. One of the reasons is that part of a good design process is having others critique your ideas, and using the results of these critiques to break apart the ideas, keep certain pieces of each, and then finally synthesize them back together to repeat the whole process (this is a brief version of what “design thinking” is).

Therefore sketchiness is key to design thinking. In order to create lots of alternative designs for a given problem, we need to create sketchy solutions. We want them to invite critique from others. If the ideas look too finished, people will be less likely to critique them. Or if you have only one idea, especially if you spent too much time on it, critiques of this single idea become more of a critique of you the designer,and it becomes too personal. Instead, having lots of sketchy ideas invites critique, and says you the designer won’t take it personal.

For more on this, be sure to check out Buxton’s site and book…for a great section on sketchiness, and the power of ambiguity in sketchy designs, see the chapter titled “Clarity is not always the path to enlightenment” (pages 115-119) in his book.

Time Perspectives of User Experience

[Infragistics] Tobias Komischke — Fri, 01 May 2009 19:33:00 GMT

In the March/April 2009 issue of Interactions (http://interactions.acm.org/content/?p=1226) Don Norman cites psychological evidence that events are judged differently before, during and after they happen:

Folks tend to judge events as more positive when they anticipate them compared to when they actually occur (“Rosy projection”).
Folks tend to rate events that they’re currently experiencing as less positive compared to when they anticipate or remember them (“Dampening”).
Folks tend to judge events as more positive looking back compared to when they actually occurred (“Rosy retrospection”).

He adds another finding which is that in our memory positive things normally outweigh negative things.

Norman provides a couple of travel anecdotes to exemplify and substantiate these effects. I did my own verification on a recent trip to Europe. I traveled to Cologne, Germany. Being German, I was looking forward to staying a couple of days in my home country. So yes, the projection was definitely rosy. Because I remembered Norman’s article, I paid somewhat more attention on my experiences that I gained during my stay than I’d usually do.

Turns out that I’d not rate everything as great experiences: a terrible flight, jetlag, long work days (after all, when they call it a day in Europe, it’s just noon in the U.S.), etc. But there were nice experiences, too: being in one of Germany’s most attractive cities, meeting interesting people, drinking the local beer, etc. Looking back now after a couple of days, I consider this an awesome trip.

OK, so what’s the connection to user experience? In his article Norman argues that what counts is the memory of a user experience. He says:

“Design for memory. … We should not be devoting all of our time to providing a perfect experience. … Perfection is seldom worth the effort. So what if people have some problems with an application, a website, a product, or a service? What matters is the total experience. Furthermore, the actual experience is not as important as the way in which it is remembered.”

I think this is an interesting thought, yet I’m wondering if that should really be the message. The anecdotes from Norman and my own experience in Cologne can hardly be compared to a user interacting with, for example, an office application. The frequencies are very different. I fly maybe twice a year to Europe, it’s not really repetitive. I will hardly make the exact same bad experience several times. However, a user of a badly-designed office application may very well experience the same frustration over and over.

Assume (and you probably don’t have to stretch your brain for that) that this software features one glitch, maybe an meaningless pop-up dialog that keeps getting in the way. Since the outcome of the interaction is always the same and therefore can hardly be considered a highlight, I’d think that this user’s memory would more emphasize the frustration with the UX problem.

I have to work with a very weird time entry system that I’ve been using for a year now. I make the same bad experiences every time I use it and I cannot claim that my judgment is more positive in retrospect than while I work with it. In this case, the negative outweighs the positive.

In my opinion the psychological findings above apply for infrequent user experiences rather than for frequent ones. Like visiting a website for the first time in order to buy something. Using a software once a year to prepare your income tax statement. For these scenarios Norman’s argumentation makes sense to me. However, there are also situations that require an extra amount of design investment to boost a rare user experience during certain events. I’m thinking of event-triggered systems like those for controlling industrial production processes. Here, the user experience of rare events has to be designed with a lot of care to limit the risk of maloperation under pressure.

What do you think? Do you have examples of the different time perspectives and how they relate to user experience design?

My Dr. Dobbs article on multi-touch, multi-user, gesture-based design

[Infragistics] Joel Eden — Mon, 27 Apr 2009 15:05:00 GMT

A few weeks ago Dr. Dobbs published a pretty lengthy (and informative) article of mine titled “Designing for Multi-Touch, Multi-User, and Gesture-Based Systems.”

In my opinion, it’s very easy to get caught up in new technologies, new features, etc to the point of forgetting that the systems we design need to first and foremost be about helping people accomplish things; i.e. any visual or interaction “aesthetics” that are added should be done so in a way that helps usefulness and usability rather than being done just because it might be fun for the designer or developer to try it out. Therefore, in this article I really tried to stress how what we already know about designing systems with great UX (i.e. useful, usable, and desirable) can be used as a strong foundation for new types of systems, including these gesture based systems that seem to be a new breed.

One major theme of the article (I don’t want to give the whole thing away though, so do read the article) is all about how the real world is already multi-touch, multi-user, and gesture-based…therefore, designing systems like this have a lot to do with looking around at seemingly mundane everyday activities and trying to understand how we already accomplish them, and then leveraging what we notice in our designs.

You already hear this all the time in UX anyway (e.g., observe users doing real things, rather than relying on user preferences and what they think they need), but it’s really important when moving to these different types of systems, because it becomes just too easy to get caught up in the excitement of the new technology.

I spent a lot of time in grad school researching distributed cognition and the extended mind (which are new views of cognition that basically oppose the idea that cognition, and the mind reside only in the physical brain), and I tried to put some of that info into the article. I included a little bit about how gestures and material artifacts can actually be thought of as first order cognitive resources, a role that older views of cognitive science reserve only for the brain. Here’s a related quote from the article that I think is interesting, not just because I wrote it, but because someone else who read it noticed it and blogged about it:

“If gestures are already so much a part of our cognitive processing then in some ways, the growing excitement around gesture-based systems is a sign that software systems are finally catching up to how we already think and behave, rather than really representing an innovative way of interacting with information.”

Dr. Dobbs tells me that lots of people have already read the article, so please if you haven’t read it yet, do so, and come back here to let myself and others know what you think about it (I don’t think Dr. Dobbs has a comments section on the actual article page).