Tag: User Experience

Posted on

User Experience in Waterloo Region

This piece first appeared this week as a blog post on the newly launched Communitech web site.

We’ve kicked off a new season of uxWaterloo events last month with a design workshop. As it turns out, Communitech is launching a new web presence this month as well, which makes this an opportune time to write about designing for user experience (UX).

Many articles and books have been written on the topic of user experience, and there might not be a universally accepted definition of what it is. It’s reasonable to say, though, that designing for user experience in a software product will often address the following:

  • Functionality: what does the product do? Is it useful?
  • Interaction design: how does someone actually use the product?
  • Information architecture: how is the functionality in the product organized and presented?
  • Visual design: what does the product look like? Is it appealing?
  • Usability: how easy or hard is it to get something done with the product?

Getting these pieces in the UX puzzle right isn’t easy, but the results can have a major impact on a product’s success.

Waterloo Region is well-known for its innovative software and hardware companies, many of which devote dedicated resources to designing the user experience of their products. For some of the user experience researchers and practitioners who call the region home, getting together at a uxWaterloo meeting is a monthly activity.

uxWaterloo is, among other things, a Communitech peer-to-peer group devoted to building a community around the practice and understanding of creating a great user experience. While we’re primarily software-focused, we touch other areas on occasion as well. At our monthly meetings we explore a variety of topics through guest speakers, workshops, and even just discussion sessions at local pubs. In the last year we’ve explored table-top interfaces, guerilla usability techniques, personas in product design, and more. The atmosphere is friendly and folks are generous and willing to share their knowledge.

So here’s an invitation to all designers, product managers, developers, technical writers, and other interested folks to join us at a uxWaterloo meeting and help us to continue to grow our vibrant community around a common interest in user experience.

Posted on

A user’s experience shapes user experience

I had a conversation with someone a while back about user experience on mobile devices. In the course of it he asked me how much I use video on my iPhone. I responded that I used video occasionally but not much, which was accurate in that it characterized my behaviour but which also felt incomplete.

I’ve been thinking about it since then and observing my patterns of use. I think that I now better understand why I answered the way I did. That is, I now understand the why of my behaviour. It’s not that I’m uninterested in watching video. It’s that I’ve shaped my behaviour to match my experience of the capabilities of the device. Two big factors colour my experience.

The first is battery life. My iPhone 3G will, in normal use, last the whole day on a single overnight charge of the battery. I found early on, though, that watching even a few videos will cause the iPhone to run out of power before day’s end. For a few reasons normal use for me has changed for me over time. So, too, has my iPhone battery’s ability to hold a charge. As a result, many months ago I started to regularly use my mobile data plan for connectivity rather than WiFi — turning off WiFi extends battery life.

More recently, while reflecting upon the video question from that conversation, I (re)discovered that I’m more likely to watch a video if the day is mostly done and I have a good charge left on the battery. This behaviour was almost unconscious; I had to notice myself doing it a few times before realizing why it was happening.

The second factor is network performance. The value of the video needs to overcome the cost of waiting for it to download, which can vary dramatically on my mobile provider’s network. As well, even if the video starts playing quickly, the download is rarely fast enough to allow me to skip ahead conveniently, which I often like to do. In the end, while using my iPhone if I encounter a video that seems interesting I most often reserve it for later viewing on my laptop.

I’ve discovered many other subtle behaviours that distinguish my own use of an iPhone from my use of a laptop on a fast network, but thinking about mobile video is what got the exploratory ball rolling for me.

Posted on

Like a truck hauling a load of scrap iron

As I wrote back in May, performance is an important part of a good user experience. The perception of performance is something that a designer can manage by providing appropriate feedback, such as a progress indicator or message. Sometimes, though, the actual performance needs to be managed rather than just the user’s perception of it.

I’ve been thinking about this over the last several weeks in the aftermath of updating my Apple iPhone 3G to iOS 4.

What had been a fine mobile device prior to the update became a sluggish annoyance after I installed iOS 4. In addition to noticeable overall slowness, my iPhone became prone to random screen freezes that lasted four or five seconds or more.

Even though Apple had disabled some of the features in the iOS 4 release when installed on an iPhone 3G model, there were still several remaining enhancements that I enjoyed. While appealing, though, none of them were enough, for me, to make up for the severe performance degradation that accompanied the release.

This past weekend I finally took the plunge and downgraded my iPhone to version 3.1.3 of the OS. As this is something that Apple appears not to want users to do, I used directions that I found in this article at Lifehacker, and they turned out to be clear enough for me to get the job done. The improvement in performance has been dramatic. Under iOS 4 my iPhone felt about as responsive as a flat-bed truck hauling a load of scrap iron. It’s now back to feeling like a small sports car, fleet and nimble and fun to use. I’m happy to sacrifice the iOS 4 features that I now no longer have for the snappy user experience that again defines my iPhone. And that says a lot about the importance of performance to user experience.

Posted on

Perils of a gestural UI, part 2

Back in March I wrote a post about how I had discovered the source my discomfort with two-fingered scrolling on my MacBook. Basically, two-fingered scrolling goes in the opposite direction to what I experience when scrolling on my iPhone. In the end, I figured I could get used to it and make it work for me. I finished that post, though, by asking “how many more of these collisions will appear as Apple continues to build on its gestural UI?”

A new collision appeared this week, as Apple released a software update that adds three-finger dragging to the trackpad. That is, moving three fingers across the track pad will drag whatever is under the cursor (assuming that it’s draggable). The behaviour feels great when moving windows around, though moving icons around on the desktop feels slightly odd to me still. The collision, though, relates to my previous post.

With two-fingered scrolling, moving my fingers towards me on the trackpad moves the scrolling page upwards within the screen — my fingers are, in effect, interacting with the scrolling control rather than the page content itself.

With three-fingered scrolling, moving my fingers towards me on the trackpad moves the window (if it’s a window I’m dragging) downwards within the screen — the opposite direction to what happens with two-fingered scrolling. My fingers are interacting directly with the object that I’m moving.

I haven’t yet spent enough time with the change to know how this behaviour will feel for me in the longer term. My guess though is that I’ll find it more disconcerting than the contrast between trackpad and iPhone that I previously wrote about. And I do suspect that there are more collisions to come.

Posted on

You did WHAT with our product?!?

A Zoom Boom loader

I wrote recently about the risks in listening to what users say they do rather than observing what they actually do. The bottom line is that people are not necessarily reliable reporters of their own actions or preferences.

Another reason to observe users is to discover the innovative uses to which they put a product, uses that may never have occurred to the product’s creators. The implications of such uses can be a great source of product or feature ideas.

I was vividly reminded of this during a bicycle ride this past weekend. I’m guessing that the designers of the Zoom Boom shown in the accompanying photo hadn’t conceived of it as a security device for construction sites. Here it is, though, providing protection for a trailer-based concrete mixer on a Sunday morning. It would be pretty tough for thieves to steal the mixer out from under the Zoom Boom.

While I design for user experience in software products, this kind of ingenuity obviously isn’t confined to that realm. Seeing examples out in the world is always fun.

Posted on

Mental models matter in product design

At the June meeting of the UX Group of Waterloo Region June Meeting last week we had a fine presentation from Amy Gill on her research into think aloud usability assessments, in which users are asked to verbalize their thoughts while using a product and performing one or more tasks. There was a lot of great discussion on the topic and on related issues, as many folks who were in the room have experience running test sessions with users.

I’ve had experience on both sides of a test, though not everyone thinks that UX professionals make for good test subjects. When the discussion touched on mental models, I was reminded of an experience that I had as a test subject for a software product.

On one of the first screens that I saw, there was a reference to David Allen’s Getting Things Done and how the product being tested related to it. As I have used GTD for many years, that immediately set my expectations and a particular model snapped into place in my mind. That model was the lens through which I looked at the product for the rest of the session, during which I struggled somewhat with fully grasping the product and how to use it. After the session ended, there was some discussion, and it turned out that the GTD reference was not intended to have been there, and that the product is not meant to be a GTD implementation. Such was the power of the wrong mental model, though, that I simply could not see the product in any other way, despite many other cues in the user interface that contradicted my model.

While the details of interaction design, visual design, and information architecture all matter, if the resulting product is conceptually unclear or leads to an inappropriate mental model for users, the product will be challenging to use. It’s critical to get the mental model right.

Posted on

Learning from a giant chicken at the side of the road

One of the things that I understand as a user experience designer is that it is often better to observe how users behave than it is to listen to them tell you how they behave. This was driven home for me quite vividly on a visit to a customer site several years ago.

A colleague and I were meeting with truck drivers to better understand how they thought about getting directions for routes they needed to take. The drivers that we met were all thoughtful and understood their work well, even if they had different ideas about what worked and why.

One driver was especially articulate in explaining how he worked and what issues were important to them. He provided a lot of insights, and was generally engaging and fun to talk to. One question that I was particularly interested in was whether he found landmarks useful in directions. He was quick to say that he didn’t like them, and provided some quite rational reasons as to why. For example, landmarks aren’t always visible at night, or they may have disappeared. Great points, and we were happy to hear his insights.

As it turned out, this driver was our last meeting of the day. While packing up, I asked him for directions back to our hotel. He was happy to help, and started to sketch a simple map on a piece of paper while providing verbal directions. His directions included the memorable instruction to “then take the next right after the giant chicken at the side of the road”. I waited for him to complete his directions, and then asked him why he had included a landmark (the chicken) in his directions when he had previously indicated that he didn’t like landmarks. He was a little surprised himself, and we discussed it a little. What it came down to was that he liked landmarks when he knew that they were accurate and visible, and could thus be relied upon.

How he behaved when providing directions was different from what he had reported to us in an interview. Users aren’t always the most reliable reporters, even of their own actions or preferences. Observation is a great tool for getting around that.

Posted on

I’m tired of waking up tired

The Diodes performing onstage

I’m not really tired of waking up tired. I was, though, a little tired on Thursday morning after two worlds collided for me on Wednesday night at the Starlight in Waterloo.

When I worked at Platform Computing I had a fine manager, Ian MacKay, who was a great supporter of our user experience team. We got along well, and he was a generous collaborator in addition to being an inspiring leader. Ian was, and is, also a man of many other talents, including visual artist and musician. Around the time that I left Platform to join Primal Fusion, he left Platform as well. One of the things that he’s taken on since leaving that company was to return to his roots as a Canadian punk rock pioneer, playing bass and singing in The Diodes. Some of you may remember their catchy hit “Tired of Waking Up Tired”.

Happily, the band played here in Waterloo Wednesday night, as part of a mini-tour that they have underway. I was glad to have a chance to catch up with Ian, along with another friend and former Platform UX colleague who joined me at the show. Hearing The Diodes was fun too. I wasn’t sure what to expect musically from a band that has played very little together in the couple of decades, but they were tight and sounded great.

So which two worlds collided? As with my Ignite talk on metaphor in product design, the Diodes show saw my working life as a user experience professional intersect with my leisure life as a music enthusiast with too many albums in too many formats!

Posted on

Sometimes faster is indeed better

One of the important factors in a good user experience in a software product is performance (or, more accurately, the user’s perception of performance). That is, how responsive to user input does the product appear to be?

I’ve been thinking about performance since my switch from using Firefox to using Google Chrome as my primary web browser. Safari remains my secondary browser. I still use Firefox on occasion for a few specific tasks.

The first time that I used Chrome, I was struck by how much snappier it seemed to be compared with Firefox. There are probably more than a few technical factors that feed into that perception, along with important goals that the Chrome team set out to meet. As an aside, it’s well worth talking the time to read the comic book created by Scott McLeod in 2008 to explain Chrome.

Interestingly, once I had grown accustomed to my newly peppy browsing experience, I started to notice specific points of slowness. A big culprit was when the browser consulted a name server (part of the domain name system, or DNS) to find the location of a given web resource. I had always known that this was a bottleneck, but it really stood out now. DNS is typically handled by your internet service provider, but there are alternative DNS sources available. Hoping to address DNS slowness, I decided to try Google Public DNS, which launched late last year.

Lookups became far quicker to resolve — in all my browsers, not just Chrome — though slower sites are now more obvious than before, as resolving the domain name is dealt with right away (Twitter comes to mind in that regard).

I’m a big fan of Google. What strikes me here is the lengths to which they have gone to improve the user experience for their products by attacking performance in a big way. In addition to the work that they have done directly on their existing products (such as Search, Gmail, and Reader), they went far further and created a new browser and a new DNS product to speed up the performance of the web for all their users. In this case, where the performance gains are real and measurable, reality is also perception.

Posted on

Yet another demonstration that beer and user experience go well together

We had a great discussion (or, rather, series of discussions) at this month’s UX Group event at the Huether Hotel in Waterloo last night. We started off talking about iPad, which was certainly in the spirit of our announced NUI discussion, but soon wandered off down various interesting conversational side roads. From business models, to retail user experience, to music and movies in the digital age, and more, it was a terrific night. Thanks to everyone who came out and made the event so special. And here’s to a speedy recovery for co-organizer Bob Barlow-Busch, who was too ill to make it out. You missed a good night, Bob!

The current plan is to try to assemble a group post that represents our collective take on the evening. Check back at the UX Group blog for more on that.