It will be an even more interesting year next year no doubt – with new challenges ahead. I hope we work more with touch interfaces, include more elements into our ‘UE toolkit’ and even challenge ourselves to work more as an agile team to name just a few. The world’s economy is a big uncertainty as well, and weighs on my mind heading into 2009 – but I know there are many strategies and maybe even a plus side to this!

Anyway, we wish everyone a safe and happy holiday – we’ll see you in the new year!

CanUX – what is it about?

Scott: Well, to be specific it’s about User Experience. But I do think it is about more. It’s about getting  a chance to connect with other like-minded practitioners, a chance to see how other people are approaching their work in this evolving industry and most importantly a chance to get away from the work we do day-to-day and recharge creatively.

What did you think?

Ben: Meeting, collaborating and socializing with others who work in the user-experience realm was great for several reasons.  Firstly, it was a great way to start my professional network.  I got the sense that a lot of people knew each other, either from attending previous CanUX events, through coworkers or projects that people have worked on in the past.  For me, the interactive sessions were most inspiring, as it involved getting everyone to participate in activities rather than listening to the speaker for the entire duration.

Scott: When I first talked about going to CanUX I was told by a couple people that I wouldn’t get much out of it. Many people felt it was the conference that new practitioners, students go to, but not for the more experienced. I have to disagree and I’m glad I went. I thought it was engaging, that there was lots of ideas and topics for everyone and it was a lot of fun.

Who did you see? Any heroes, gurus or UX experts?

Ben: I’m still new to who the heroes, gurus and experts of user experience are, but they were easy to recognize at this event!  Luke Wrobleski, Dave Gray from Xplane and Brandon Shauer from Adaptive Path were all speakers at this year’s event.  Even though I’ve read Luke’s book, I found his session to be a good exercise in form design and interesting to see how he would approach a design problem.

Scott: A ton of people including some folks from the Calgary UX community and some Vancouver folks I hadn’t met previously at VanUE events. Big standouts for me amongst the speakers were Dave Gray, Brandon Schauer and Luke Wroblewski.

Describe a couple of the sessions…

Ben: Visual Thinking in Practice part 1 by Dave Gray - was about communicating your ideas through drawings and sketches, and getting past that “inner critic” inside your head.  Dave first started by asking: “how many people don’t think that they can draw?” Surprisingly (unsurprisingly for him) the majority of hands in the room shot up in the air.  He then focused the remainder of the session on going through the “visual alphabet” and an activity to prove that with this type of alphabet, you can draw anything for the purposes of conveying an idea. 
Drum Circle by Malcolm Lim – was a drumming session that that tapped into the creative side of our mind.  It allowed us to explore our instruments while still being part of the overall sound in the room.  Rather than describing it, you can have a sneak peak of what it was like here!

Scott: Nah…I can’t just talk about two. Has to be more:

• I was glad to finally see Luke Wrobleski speak (I’ve loved his work on forms for a long time and drove one of our designers’ crazy with all his ideas on forms during a big project). I was a bit disappointed not to hear any new material (if you follow Luke’s blog or have his book on form design, it was a bit of repeat).
• Brandon Schauer from Adaptive Path was a surprise. He’s often the AP speaker on the circuit but I really enjoyed hearing him explain the Sketchboards approach. Even though I read about it on their blog and watched the videos it was interesting to actually do a sketchboard and see how this fast iteration process could be a great tool with our clients.
• Dave Gray from XPLANE was a hoot. Spent a half day drawing with him and learning the basics of his “visual alphabet” which was pretty interesting. I’m doodling now more than ever. I swear he did the whole session off the top of his head, with a rough approach worked out the night before at dinner.
• Yvonne Skek’s swimlanes was interesting, but she seemed a bit nervous. I also would have like a bit more time to play with the concept could have been longer.
• Did I mention that we did some creative work with people from the Banff Centre? I did collage – not part of the normal everyday IA/UX toolkit, but an interesting exploration of working with a variety of inputs, finding creative ideas amongst otherwise mundane materials and expressing concepts to others.

What were your two big take-aways from the conference? What did you learn?

Ben: At successful events like these, I’m usually struck with something I can only describe as a “cool” moment.  I was fortunate enough to have a couple of these at CanUX. One was during Brandon Shauer’s session about sketchboards.  He proposed a design problem where we each individually had to sketch 6 different solutions.  The first 3 sketches came quickly for me, but a mental block quickly followed and I was only able to sketch one more in the time remaining.  We then looked at sketches of others around our table and saw that we all had different solutions sketched on our papers.  The moral of this story for me is that no matter how big the mental block is, there is always another solution that has not been thought of yet.  Keep thinking!

Scott: It’s a small world. I met lots of people who have either read my blog in the past or who know other folks who have met some of the people at Habañero. Connections in this growing community are critical to its ongoing growth.
I need time to be more creative to remain on-top of my game. Some of the most interesting sessions involved putting away the high-tech tools and focusing on capturing ideas; iterating quickly; working with others and playing.

If you were running the show, how would you improve the conference?

Scott:  I have a few suggestions:

• Have a couple free nights with no formal group events. Would have been nice to just go into town with a few people, have a pint and catch-up
• Involve some other local (by local I mean Canadian) practicioners in the conference as speakers. We’re doing tons of cool work in this country and I think it is time to showcase some of that skill, talent and experience. Gene/Jess: you looking for speakers for 2009?
• Start a day earlier, invite up whoever wants to come to improve the signage at the Banff Centre. Easy to get lost on the campus (kidding)

To use the elevator in question as an example of borderline terrible usability, we joked on the ride up to the 5th floor about the flaws in the design of how something we all take for granted — and use regularly — works. Elevators are simple machines, right? They go up, down, and stop at various floors. You push a button and an alarm sounds, or you turn a key and lock it in place. A couple more buttons let you hold the doors open on a specific floor, or shut them if you’re so inclined. Nothing really complex to it, is there?

You’d be surprised at how much can go wrong with something so straightforward. Let’s look at a couple of specific examples of why this elevator makes for an inconvenient and at times incredibly frustrating user experience, and how we can draw parallels to UX design in the process.

I pressed the button, didn’t I?

The elevator in question appears to have a mind of its own.

Take this scenario: I press the button in the lobby to go up; unbeknownst to me, one of the elevator cars, waiting in the lobby, already had its doors closing. They close, not stopping due to my button press, and the button deactivates itself automatically. I back up, not realizing that the call button is no longer selected, and wait impatiently until realizing that I have to press it again. Annoying, isn’t it?

So what’s wrong here, and how does this relate to interaction design?

Well, in this specific case, I’d like to draw your attention to proper error handling. When something doesn’t work properly, most folks expect some kind of messaging coming back their way explaining what went wrong, why, and what they can do to fix it. In the case of the elevator, there’s no feedback mechanism letting the user know that their request failed.

One of the core tenets of UX design in this bold, shiny, message-bubble-happy Web 2.0 world is to provide clear, obvious feedback to the user when they’re interacting with your web application. In the case of the elevator, it may be as simple as chiming a bell and holding the door open if it’s already open when you press the call button, but in your designs it’s something that needs to be taken into account. Have a standardized methodology for providing your users feedback in case of errors, and make it easy for them to correct what went wrong and try the action again. If it’s something they can’t fix, provide user-friendly messaging that explains what’s going on, so as not to cause a revolt amongst your users (assuming it’s not a common error.)

The old switcheroo

This one gets everyone who uses this elevator at one time or another. Regular users of the elevator will get used to buttons being in a certain location. This elevator is special; the buttons for opening and closing the doors are inverted on the other side of the elevator. If you’re accustomed to where they are on one side, you’ll automatically hit the same button on the other side’s panel — in this case, having the opposite of the intended effect. Oops!

There’s a pretty striking parallel here to web site navigation design: switching navigational elements from page to page on a web site will definitely confuse your users. Why would you design an elevator with mirrored navigation controls? It appears that many of our best practices in interactive media would apply just as easily to industrial design.

While changing design elements around between templates on a site might work as long as their positioning is clearly defined from page to page, you should really spend the time and justify why you need to build an inconsistent navigation. In our test subject’s case, there’s no clear reasoning behind the mirrorring of the top row of buttons, all the while leaving the bottom two buttons in the same positions. It seems quite random, considering they’re the only set of controls where the positioning has changed, from one side of the elevator to the other.

User testing — even the so-called “Mom test” — goes a long way in cases like this — what may seem visually pleasing or quirky as an interaction designer may cause your users no end of grief and frustration. Take the time to not only ensure that your site’s navigation is consistent and well-structured, but also to test your designs with users who may not be web-savvy and see if it stands up to their usage. Designers and developers have a tendency to become blind to their own work, as time passes; what makes perfect sense to you may have the opposite effect on your users. Enchanting your audience with an attractive, yet highly-usable design and information architecture will help to enlist regular users. These happy regulars, in turn, may lead to more sales, or, with luck, a core group of users who evangelize your site or product and save you time, energy, and money in the long run.

Supporting information of questionable value

I always find the warnings attached to elevators in high-rises highly entertaining, and this one is certainly no exception.

Notice the strangely highlighted words in the fire warning on the left? “Fire Use” and “Not” are what stand out to me at a quick glance. Does that make much sense to you?

Beside it, we have an elaborate schematic of the 5th floor, including our emergency exits, the locations of the nearest fire extinguishers, telephones, and of course, the ever-important bathrooms. If I’m at the office and a fire breaks out on my floor, am I going to sit for five minutes trying to decipher a cryptic blueprint, make a quick trip to powder my nose, or am I going to run down the emergency stairs at full-tilt and pull the nearest fire alarm?

What am I getting at with all of this? Providing clear, concise supporting information on your site is just as important as your visuals and textual copy. As Jakob Nielsen preaches, use consistent and obvious language, placement, and terminology to refer to navigational elements and other areas of your site. Providing a help area for your users to communicate with you — and to refer to in case of the inevitable problems that occur while running a large site — is also an important task that may get neglected in favour of further development of new or more elaborate features. Don’t let those things fall by the wayside and you’ll be doing yourself a favour.

Do you have any interesting experiences with the usability of everyday objects that you’d like to share? If so, we’d love to hear about them.

Course Synopsis

In this course you will explore a number of tools and techniques that you can integrate into any website, intranet, or software development process to create a first-class user experience. You will be able to try many of the approaches illustrated in the seminar through a number of hands-on activities and exercises.

Every participant will leave the course with a wide array of user experience tools and techniques. In addition, we will provide a comprehensive set of course materials and templates — a valuable resource when using the described techniques in your own environment.

UE Done Right

The cost of the course is $799, but you can sign up with the Habañero client rate of $499, if you email me and mention you read about it on the blog.

Hope you can come, it will be a fun two days!

I’ve found the process we’ve been following very effective. We’ve iterated an prototype very quickly and with a very small resource cost. Some points I think are key to this being so successful:

• Quick meetings often. The team meets on a regular basis often to keep the momentum and excitement of the project flowing. This keeps our ideas fresh and interest strong.
• Manageable take-away homework. Each team member takes on a small task to complete prior to the next meeting. That way, no one team member is stuck with huge time consuming tasks. Also, it keeps the project moving foward even though we aren’t together working on it.
• Working meetings. At each meeting, we review the homework and revise it together, so the deliverables changed quickly and organically. Many points of perspective can be integrated at each stage of progress.
• Always a prototype. By keeping the mentality that the deliverable is always in beta, we don’t hang on to one solution. No one is too attached to the outcome, and we are able to let go of ideas quickly. Constant improvement is the mantra, and making mistakes is easier to accept.
• Something tactile as soon as possible. We visualize our ideas as soon as possible to see if they work. That way, impossible ideas are discovered sooner rather than later. Also, we have a constant feeling of accomplishment as we are moving ahead with our tool.

The team discussed these strengths of the progess, and we discovered we are adapting an agile method to our project. Pretty cool! Stay tuned, we will be finished our tool soon, and we will post about it here.

One of my favourite parts of the show is when they show elements of the creative design process. Don’t get me wrong, this isn’t the main focus of the show (the stories between characters definitely take precedence), but it’s fun to see the ideas they come up with at work and little snapshots of how they got there.

Here are some observations I had while watching some recent episodes - which I think still ring true in the design work we do today:

1. Ideas can happen anywhere. I loved seeing on a recent episode all the napkins that Don Draper (a creative guy who is the main character of the show) scribbles on to collect his ideas. His wife was rummaging around in a drawer and digs up all these napkins from different bars, restaurants, etc. All of them had sketches or ideas for tag lines - and not phone numbers! It was a fascinating glimpse into how the creative process works for Don and gives me more reason to carry around my little Moleskine everywhere.

2. Don’t be afraid to talk about your own story.I also enjoy how Don ties his own personal experiences into the products he markets. A memorable scene in a show from last season was his pitch for the ‘Carousel’ or the circular slide projector. Don was trying to sell his idea for the Carousel by using his family and personal photos to tell a story. The dramatic tension in the episode had been built up by that point too, but it was an interesting take on the vulnerability of our own stories and how they can often create connections between strangers and of course, clients. There is a fine line in bringing up personal references during a design review for say, a website, but the stories that come from real anecdotes can be quite powerful if used appropriately.

3. The ‘AHA’ moment takes time. On some episodes, the characters are shown going through a series of brainstorming meetings to talk about ideas and review collateral. It’s pretty typical that a team meets regularly and shares ideas, but it’s also fun to see all the evolutions it takes to get to a final product. You regularly see drawings and slogans ripped up, product names change (remember the Relaxicisor > Rejuvenator?), and Don leading his team to the “A-HA” moment at the right time. You also see client meetings where ideas don’t go over so well, which in the end results in a better product as the team is forced to go back to the drawing board. You can’t rush the design process sometimes!

Mad Men is a show that has me addicted - if you haven’t checked it out yet, I highly recommend it.

While the keynotes were considered relatively weak from the perspective of most of the event’s participants that I chatted with — aside from the always impressive Gary Vaynerchuk, who, to use his own words, “killed it“ in his 15 minutes on stage on Thursday — the sessions were a pretty good mix, on the whole.

As a footnote to the event, I thought I’d take a little time and highlight a few sessions I thought really stood out during my time there. I didn’t stick to any particular track (there were several offered), instead mixing things up and sample sessions in each track that struck me as interesting. Not all of the slides are available just yet, but the ones that are available are up here.

Viral Marketing 2.0

Jonah Peretti, BuzzFeed / Huffington Post

This was definitely one of my favourite sessions of the entire conference. Jonah Peretti, best known for his “Nike Sweatshop” email meme, the New York City Rejection Line, and his work on a variety of viral marketing stunts afterwards, was funny, entertaining and enlightening in front of a packed house. He discussed what he called the “Bored at Work Network” (BWN) in some detail, breaking down his thoughts on contagious media, strategic product evangelism, and various forms of viral marketing.

He went into some detail on viral marketing strategy, but summed things up by saying that in order to market virally, one needs to focus on the mechanics of how the idea spreads, not on the idea itself. The lessons I drew from the session were that (a) the BWN trumps influentials, and (b) the BWN creates its own influentials. Give those ”fanatics” the opportunity to thrive and to evangelize for you, and you’re set.

Design for Sign-up

Joshua Porter, chi.mp

Having already read Josh Porter’s book, Designing for the Social Web, from cover to cover, this session was old hat to me. I’m mentioning it here because I think it was still very important to anyone who hasn’t read Porter’s book. To those who already had, most of the material covered in the session was the same as his chapter “Design for Sign-Up: How to Motifcate People To Sign Up For Your Web App”, with a few examples thrown into the mix that you might not have seen in the book, along with Porter’s commentary.

The same material is available as a free chapter from his book, in case you’re interested. If you’re building a web application that requires registration of any kind, I’d suggest you take a look; his tips are invaluable.

Lessons Learned in Scaling and Building Social Systems

Joshua Schachter, formerly of Yahoo!, creator of del.icio.us

While Joshua Schachter’s name might not have been familiar to many of the folks attending his session, the application that he created was: del.icio.us. Fresh from his recent departure from Yahoo!, Schachter gave us a somewhat disturbing look into the scaling of what could be considered a very simple web application by most accounts. When I say disturbing, I mean in the sense that even a simple site like del.icio.us seems to have encoutered some major issues while scaling up to support amazingly heavy volume, which I’m sure gave the many developers in the crowd fits and sleepless nights following his talk.

Much of his session covered how to scale an application gradually by offering up slightly different feature sets to users as you progress up the traffic ladder, and his three ways of scaling applications: technological, personal, and social.  Schachter’s insight into handling specific situations such as dealing with trolls and griefers, creating viral loops, managing the identity and reputation of your users, and variations of application language and terminology was invaluable, and was supported by examples that hearkened back to Josh Porter’s earlier talk.

Schachter’s talk — dry wit and monotone delivery inclusive — was excellent, but I think he may have scared off a lot of attendees as he got into some pretty elaborate technical detail. I’m not complaning, though. I took reams of notes.

Scaling Digg and Other Web Applications

Joe Stump, Digg.com

I hadn’t heard of Joe Stump before walking into this session, but I was suitably impressed with his credentials as both Lead Architect at Digg, and as the President of the Cal Henderson fan club (for those not in the know, Cal is the architect of Flickr, and author of O’Reilly’s Building Scalable Web Sites.)

Stump’s talk about scaling Digg had a lot in common with Joshua Schachter’s talk from the day before, and I’m sure they’ve discussed their overlapping issues in the past. I do think, however, that Stump was the more entertaining of the two; he had the crowd laughing pretty regularly throughout his session. Just as technical as Schacter’s presentation (or moreso), but specific to Digg (whereas Schachter’s was more general in terms of social applications), the crowd was obviously expecting a much more detailed technical talk in this case.

I think Stump’s comparison of the Web 1.0 sites (flat, static sites where you can just throw more powerful hardware at them to handle additional load) to Web 2.0 applications (heavily interactive, database-driven sites that need to be partitioned to scale both horizontally and vertically) was pretty much dead on the money. To quote Joe, “Web 2.0 sucks (for scaling.)”

Using Real Time Game Concepts to Increase Engagement

Charles Forman, ImInLikeWithYou.com

Although Charles Forman’s presentation came across pretty rough (if you find a copy of the slides, you’ll see what I mean in the first half-dozen slides), I think this was the highlight of the conference. Although many people didn’t make it as Forman’s talk was at the end of the day (after 5pm!), he presented the development of Web 2.0 sites in a totally different light, drawing parallels with his previous experience in the video games industry and with his development of I’minlikewithyou, a thinly-veiled dating site disguised as a collection of mini-games.

I took a good three pages of notes in this session, surprised at the depth and breadth of the topics he covered. Forman’s main point, distilling a 45-minute session into a single sentence, was that many things that we take for granted in video games can easily be abstracted and applied to web applications for the benefit of both the sites’ operators and users. A good example of this is LinkedIn’s “XX% to complete your profile” widget, which is a very game-like concept (compare this to having to gain a certain amount of experience to level up in an MMORPG) that really encourages members to keep chipping away and coming back to complete their profiles.

The main take-away was that one can encourage interaction by applying the same lessons that make video games so successful, addictive, and viral: implementing realtime feedback, providing objectives via quest-like constructs, providing rewards for interaction, and encouraging interpersonal communication will go a long way to making your site more successful, whether it be a community, social network, or anything else.

Lately I’ve been working on projects that require significant thought and planning for content. I thought I would share some tips for planning for content (some I learned the hard way!):

1. Start Early

It’s ideal to start working with a writer during the IA (information architecture) phase. Labels and structure have to work with content, and vice versa. It’s critical to get your Project Manager on board to help kickstart the content development process whether it’s within a client organization or your own. I try to work with a client to figure out a plan for content - whether it will be incorporated into wireframes/mockups (I highly recommend this), who is tracking it, how migration will work, etc.

2. Store content in a central location

Ideally, it’s best to have one central place where people can refer to wireframes/mockups and the content at the same time. Storing content in your email inbox is not recommended! We are still figuring out the best way to do this, but I’ve been looking at services such as Jumpchart which helps multiple people view page content as it gets developed, and collaborate on it.
Whatever method you choose make sure text, keywords, links and assets such as images are stored in a location where all members of the website team can access the latest version.

3. Plan for revisions, and more revisions

It’s important that as the website design is getting fleshed out, writers are involved and know about content areas they need to work with.  There is usually a lot of back and forth between writer(s), translator(s), and the website development team to get everything in place and looking right - and if a process is planned out from the beginning the revision cycle will go as smooth as possible. Some ways we planned for this: set early deadlines for the high priority content in all languages and set 2 days a week as ‘translation’ days where a set of content gets sent to translation in bulk.

4. Don’t forget about other language(s)

Translation adds another level of complexity to the content development process. If possible, start translating as soon as the main content and labels are being developed. We find that some languages such as French can add up to 25% more characters, which could impact global navigation design, page width, etc.

5. QA your content

It’s important to have someone test your content. Sometimes content is developed in isolation from the design and areas could get missed, be too short, too long, etc. It’s also important to look at content on a site with an editor’s eye and ask yourself if all sections have a consistent tone, are connected and flow together.

Some of these tips may seem obvious, or common sense - but I hope it’s a good reminder to get your plan together when starting a content-heavy project. If you have any other tips to share, please leave a comment.

I’m going to be flying down to the Big Apple for the Web 2.0 Expo from September 16th - 19th at the Javits Center on the west side of Manhattan. The Web 2.0 Expo is one of the premier web development and user experience-oriented events every year, and this will be the inaugural year for it in New York. Judging from the lineup of speakers and sessions/workshops they’ve put together, it looks like it’s going to be quite a spectacular event. You can follow the event on both Twitter and Facebook as well, if you’re interested.

I’m posting this here in case anyone who reads this blog would be interested in meeting up while I’m in town and talking shop — err, user experience, that is. :)

For what it’s worth, I’ll also be in Helsinki for a Nokia’s Open Lab 2008, sponsored by Nokia / WOMWorld sponsored workshop next week, from September 10th to 14th, discussing social media and community-building, and their involvement in the future of mobile devices. Interested? You can read more about the event over at my personal blog.

This article also relates to a project that I am currently working on. We are trying to be as ‘agile’ as possible by building the shell of a website from the wireframes before design mockups haven started. We are also doing usability testing during development, and conducting walkthroughs every 2 weeks with the client so that we can test our progress. I have worked on other projects where we have tried to be agile, but this one (I am happy to find out) follows many of the suggestions in the article.

A couple points stood out for me as things we do not explicitly do though. We do not tend to conduct interviews with stakeholders and end-users during the development phase. We usually formally wrap up interviews during a discovery phase, but we do continue on with usability testing and ‘walkthroughs’ later on to make sure that development is matching what the stakeholders/end-users envision. It would be interesting to work on a project where ‘interviews’ continue throughout the project, and where research & validation happen at the same time as the article suggests.

Another interesting point is ‘prototype as a specification.’ At Habañero we may use a combination of wireframes, mockups and a document as a specification. However, I am experimenting more with building simple clickable prototypes in FireWorks, and this seems like an area we could exploit more on Agile projects. Documents tend to get stale pretty quickly and are hard to keep up to date - a prototype + discussion definitely seems like something that could be used to build concepts, and then the concept is kept ‘documented’ through the actual code.

This is an interesting area - I would love to hear about any other methods people are using during Agile projects!