How not to do a Diary Study

I’m employing a diary study for my MSc dissertation on image search, and I realized I was doing it all wrong today when I met with my supervisor and project sponsors. Well, okay I wasn’t entirely clueless but I did make some pretty bad assumptions about diary studies, and these were the lessons I learnt.

1. Don’t assume people remember what they noted in their diaries

I started off telling my participants that all they needed to do was fill in their diaries with descriptions detailed enough so that they would be able to recall the activities. I told them the study would last two weeks, based on some ballpark figures I discussed with my supervisor, and I told them that I might give them a call every now and then to “see how they were doing”. In a recent meeting my project sponsors and supervisor suggested that I should call them daily, because there’s a high chance that the participants would forget a lot of the rich detail that you want to get in a diary study interview.

I had to correct my slip by contacting every one of my participants to ask them permission to call them on a regular basis, and thankfully the ones who have gotten back to me so far have been totally cool with that because they were acquaintances or friends. But it was just bad foresight on my part.

2. Be as specific about your population as possible

When I sent the word out that I needed participants, I had a lot of friends were willing to participate because they had they time and they didn’t mind doing it (plus there was a £40 incentive). I didn’t think too much about the demographics of the population and I let in two participants who were edge-cases – a photographer and a graphic designer. In my study about domestic image search behavior, they’d stand out in a crowd. Thankfully I had other participants who were more “normal”, but I would’ve saved myself the embarrassment had I spent a bit more time thinking about who I should’ve been recruiting.

3. Research requires testing too

I assumed that people would quickly understand how to fill in the diary forms, because they were relatively straightforward. I was promptly advised to call in and check with my participants so that I could get a quick “feel” for the differences in behavior and data, and adjust the study process accordingly. Some participants, for example, may be more active internet users than others, for example – so they would need less “checking up” since they would have a lot more stuff to report after a few days of diary-filling. I initially thought that calling them they day after I had spoken to them was too soon, but there are ways to inform the participant of how often you need to get in touch with them.

4. Don’t believe everything you read in books

I guess it’s not all method-driven and form-filling. There’s a bit of an art to this, so I guess it takes a bit of practice to get a hang of it. My supervisor/project sponsors were forgiving and kind enough to guide me in the right direction, but I could’ve saved myself by asking more questions, talking to the right people, and not just basing my ideas off books.

update: I’m still looking for a few more participants, preferrably male aged 40 to 65. If you’re interested, please email me at boon [dot] chew [at] gmail [dot] com. For more info, click here.

What I like about Yammer and why it’s not like Twitter

I’m working at a small startup company and we’ve just got ourselves onto Yammer and I’m really getting into it. I use Twitter as well for my regular stuff, but Yammer has me posting all sorts of ideas and thoughts and feedback about the work we do.

We basically use it to state what we’re currently working on, respond to each other’s comments and ideas/rants, post up screenshots of stuff we’ve seen (inspirational sites, examples, etc.), ask questions, etc.

It’s like IM, but I think it works better because it’s like a blog as well. Yammer sends you a summary of the day’s posts, so that you can catch up with what’s going on. I find that it works not just for remote-working solutions but even for team-related tasks because you can be working on different things but not actually see each other’s work.

I like the fact that it’s closed – so that no dumb-ass spammer can find my profile and send a request to follow me.

I also like the fact that I can upload stuff directly into my posts. That way my readers can quickly open up a screenshot, etc. Sure twitter has twitpic, but that requires opening up a separate browser window, etc. With Yammer, all I had to do was use Fireshot to grab the screen capture and save it onto my hard drive, and get Yammer to upload the file from there.

I’m not a big fan of the clients they built (PC/Mac, etc). But it’s functional, and I can use it. The interface doesn’t look and feel as nice as Twitter’s, but I guess again, I’m not really complaining.

I don’t know of any other folks using Yammer, but if you are I’d love to hear what you think.

A Framework for Interaction

Because I have been doing a lot of PHP plumbing lately, I’ve been thinking a lot about implementing a web interaction framework that would make my life easier as a web developer cum interaction designer. One of things that got me thinking is the amount of complexity that’s involved in provide the right kind of feedback at the right time to the user.

No plugins allowed

It’s not as easy as hooking up messages to specific URLs, which get displayed when an action is performed. Interaction is complex, some involving multiple conditions and terms. And you can never design for everybody in mind, because there’s always an issue of context that you have to deal with. So, then what you’re actually trying to build is based on an assumption of the kind of context that is most appropriate for the task at hand.

For example, take the simple case of a password reminder. Although it’s relatively straightforward to implement a mechanism to send off a password via email, how the user  has arrived at that task is another thing altogether. A password reminder system for an online banking application would look a lot different than a social networking site. Do you send the password along with the email? Do you send a link with that takes the user to a page to reset the password? What should the messages say? How often do these password reminder tasks occur with the existing user base? How did they know how to find help?

With such a basic task, there’s already so much to consider. What more a task that involves collaboration, scheduling, persuasion, trading, payment, and communication.

The bare necessities

This is when I started to take a step back and ask myself – what are the most essential things that I need to build an effective interaction framework?

  1. I mentioned feedback, so I think notification is one of them – a way to inform the user regarding the state of the application or system.
  2. Then, I think there’s the element of context I mentioned earlier – technology can help with helping us understand more about what is appropriate, and also helping us in designing for what is appropriate.
  3. Also, I don’t think we can ignore the interface itself – all the buttons, fields, and little components that are used to interact with the system. I think this is the main part in what we usually consider as interaction design.
  4. Somewhat related to the issue of context, but I feel deserves its own section, is testing – or, evaluation. This is so that we can identify potential areas of improvement by understanding the patterns of existing user behavior.
  5. Finally, because all interaction is both a function of time and space, I feel that there needs to be an element of process – some kind of journey, or set of occurences that take place one after another. Much like how stories are expressed using specific narratives, interaction is also played out between the system and user through various sequences.

There may well be more, but these have been on my mind lately – ways in which I think a framework could help in solving interaction design problems.

Design patterns and human predictability

While I think design patterns like the ones from Tidwell’s ‘Designing Interfaces’ or Welie’s pattern library are extremely useful resources for solving interaction problems, they are also somewhat limited as they don’t propose more high-level strategies for interaction design. This is simply because many of these patterns are extremely tangible, and are essentially a collection of existing interactive solutions that have been known to solve common problems in interfaces (e.g. accordions, tooltips, tag clouds, wizards, breadcrumbs, etc.)

This is where I think an interaction framework can help – by providing the necessary “glue” and language by which these patterns can coexist and integrate in a flexible, scalable, managable way.

My inspiration comes not from the hubris of Steve Jobs, nor the empathic anecdotes of Don Norman. Neither is it from the pragmatism of Cooper’s Goal-Directed Design methodology, to which I owe great thanks in sparking my journey toward interaction design. Instead, I was inspired by J2EE design patterns from my early days as a Java developer.

This is an important distinction is because all of these design patterns come to play in a systematic, structural whole. Whereas, many of the existing interaction design patterns we know of now are sort of separate and somewhat distinct from each other.

System Architecture Interaction Architecture
Transform, Manipulate, Guide, Communicate, Create, Translate, etc. Bits, Bytes, Strings, Numbers, Objects, Packets, Records, Emails, Documents, Interfaces, etc. Emotion, Feeling, Mood, Action, Behavior, Values, Words, Drawings, Opinions, Stories, Decisions, etc.

In a way, I am envisioning an interaction architect structuring an interactive system the way a system architect designs an application’s infrastructure. The system architect defines the language in which data (or manifestations of it) is transformed, manipulated, sent/received, created, etc. The interaction architect defines the language in which human attention, behavior or actions are transformed, manipulated, communicated, guided, persuaded, etc.

Some comparisons

Bill Verplank proposed an interaction framework that looks really interesting. It’s set up mostly to assist teams in designing interaction and interfaces, and has little to do with the actual nuts and bolts of a particular interaction technology. This is all fine, because as an interaction designer you don’t necessarily want to lock yourself down to any particular technology. In the same way, Cooper’s Goal-Directed Design also proposes a methodology that provides a practical framework for understanding who the target users are and designing for them. GDD also takes the approach of being technology agnostic, although Cooper mostly refers to software interfaces like desktop applications, mobile phones and websites.

However, I think there’s a growing need for a technology-focussed framework – one that sits just between the sort of team-focussed, process-driven, project methodology – and the tangible, collective, distinct set of pattern libraries I talked about earlier. I am probably thinking about web applications, but this can apply to any other technology (Air Traffic Control systems, for example).

The J2EE design pattern specification exists for Java architects to build enterprise Java applications in scalable, managable, flexible ways. In a similar vein, interation designers can establish similar frameworks for their own interactive systems – that sits between the system and the project, that can be expressed in terms that are more closely linked to the systems themselves (like interaction design patterns are), rather than wireframes, storyboards, sitemaps, affinity diagrams – stuff that’s more commonly used for communicating between people rather than communicating between systems.

To-do: Evaluate Google Page Speed

Update: Rey alerted me to Yahoo! YSlow

This looks interesting:

http://code.google.com/speed/page-speed/

Curious to know how effective this is towards usability/interaction design.

Blurb from site:

Page Speed is an open-source Firefox/Firebug Add-on. Webmasters and web developers can use Page Speed to evaluate the performance of their web pages and to get suggestions on how to improve them.

Page Speed performs several tests on a site’s web server configuration and front-end code. These tests are based on a set of best practices known to enhance web page performance. Webmasters who run Page Speed on their pages get a set of scores for each page, as well as helpful suggestions on how to improve its performance.

By using Page Speed, you can:

  • Make your site faster.
  • Keep Internet users engaged with your site.
  • Reduce your bandwidth and hosting costs.
  • Improve the web!

Wanted: Participants for Diary Study for Image Search Activities

Hannover Google Image Search, by MKKnopThis is a plug for a study I am doing for my MSc dissertation.

If you are a healthy London-based person (preferrably male) aged between 40 and 65 who makes use of the Internet regularly, I would like you to participate in a Diary Study which will help me understand more about internet search behaviour involving non-personal images.

This study will involve the following:

  1. an interview at the beginning of the diary study, which explains what the study is about and what you need to do
  2. the diary study period, in which you log when you perform an image-related internet activity (approximately 2 weeks)
  3. an interview at the end of the diary study period to understand more about specific tasks that are of interest

In return, you will be imbursed with a £40 voucher from a vendor of your choice.

If you are interested in participating, just drop a comment in the box below, and I’ll get in touch with you shortly. :)

photo credit: MKKnop

CSS Rite of Passage

Once again, I am getting my hands dirty with CSS. And I’m no expert, but having read through numerous articles from A List Apart, I’ve been fairly sensitive to how “designer-y” people think and react to CSS issues.

For one, I am currently working with rey who’s coding up the front-end for a site we’re building. And bad habit of hacking up layouts with inline styles has driven him up the wall. I’ve recently made the effort to migrate my styles into our stylesheets, but only when I was styling up a panel quite seriously (as opposed to just using HTML markup and existing styles).

Reusable CSS isn’t quite like reusable code

The gap that I had crossed was this idea that it’s okay to create a style that’s never going to get re-used.

For the longest time, I was using inline styles because it was quick and dirty, and for the most part, many styles were bespoke. I felt that only reusable styles  should be put in a stylesheet. It’s one of those coder things where we like to build reusable components and keep them organized and use them in what we call an architecture. But I had to put that coder thinking aside for awhile, when it came to CSS.

The reason is because styling up a div one way doesn’t mean it looks right when it gets placed in another section of the page. The effect of one small change in one component can and will affect the feel of the other components. This is not just true in terms of the visual layout, but also in CSS – because there are cascading styles that will enforce itself upon any child components.

In an object-oriented programming paradigm, extending a class or object is often an act of empowering (decorating) that object based on elements inherited from its parents (a very bottom-up approach). But in CSS, it almost seems like the reverse when you don’t necessarily want to inherit from a parent element, unless you had a very intimate understanding of the way it was styled from the top-down.

Approaching a user model

Rey uses the term “semantic” a lot when he’s talking about CSS, referencing the act of naming a class based on the purpose of the component that was being styled. Again, this is partly contrary to the way system-thinking works, where you often name it based on a process (e.g. Data Access Object, FileFactory). This other gap I had crossed was about having a user model vs. a system model (which Norman talks about).

The issue here isn’t so much about whether I was naming a CSS class inappropriately, but about the way I viewed my styles with respect to the design of the site. In short, I would be thinking of the site the way a viewer would think about it – an about page, a contact list, a article side-quote, and so on.

Interestingly, CSS would ‘encourage’ me to think in terms of how different components looked and ‘felt’, nested in other components or on a different markup tag. For example, an article side-quote within a blog post vs. outside a blog post. Or a quote within a div or a span, or as a link. Or as a link within a span? Or as a list?

To a programmer, there’s a point where all these elements look like plain-old boxes. But to a designer, they’re like specialised tools that are meant to be used one way and not another. And I believe it’s because designers have a greater empathy for human beings – how we view, organize interact with and consume information.

What the books don’t tell you

I’ve been frustrated by many books on the subject of technical languages like PHP, CSS, and so on. Simply because many of these books completely ignore the fact that there’s an art of programming that can’t be communicated by instruction. It is this art that sets apart good designers and expert designers, good programmers and expert programmers. And this makes the difference between Ruby and Kohana and Django – not that one is particularly better than one another (trying to avoid flame bait here), but that the frameworks have been designed to appeal to a specific type of programming “art”.

Although there’s only “one” CSS (albeit with multiple revisions), there’s still many books on how to write CSS, and different authors will present their formulas based on their own design habits. Some are comfortable using CSS hacks, while some are strong advocates of reusable patterns, but this quote from Alan Cooper keeps coming back to me – that programming is craft and all software is bespoke.

So, there’s never going to be a one-size-fits-all solution. Ultimately, all programmers and designers have to lean on their craftsmanship in order to determine the right solution.

And I still haven’t found a book that helps me do that.

The reason why I feel this is frustrating is because many other crafts like painting or architecture or photography actually have books like that. About the art of the craft. Even some business books are dedicated to just that – the art of business. But almost 99% of the books out there on CSS, HTML, etc. are instructional, not inspirational.

Community as our last hope

Alas, one thing developers and designers do have is the technology itself, not as a solution itself, but as an enabler. I think that if we are going to reach a level of maturity in designing applications the “right” way, it will most likely be facilitated by community interaction, rather than plugins, frameworks or cut-and-paste code snippets.

The reason I say this is because every few months or so, a new browser version is released, a new styling standard has been established, or Microsoft continues to fail in delivering standards-based compliance and even makes it inconsistent with its previous browsers. And the only way we can survive this madness is if we work as a community.

But I am finding it difficult to meet (or fearful of meeting) people who might be willing to mentor me in CSS, of all things. And I assume experts think most web designers out there want cut-and-paste code. In fact, most articles I come across, with a few exceptions, are like that – catering for the cut-throat, deadline driven, plugin-frenzied, shock-effect designers and developers who want all of life’s problems handed on a silver platter.

There’s a lot to be said in the world of CSS, but as long as it’s not catering towards proper craftsmanship, I’ll be doing it the hard way with my bare hands and peering through the grapevines.

UX Barcamp London 2009

UXCampLondon logo

Mark your calendars! UXCampLondon will be held on 22 August 2009, at the eBay/Gumtree offices in Richmond. As with all Barcamps, UXCamp will be highly collaborative, self-organising, and gather people from all sorts of UX-y places (interaction design, usability, user-experience, information architecture, HCI, etc.).

Paraphasing TheRulesOfBarcamp:

  • You do talk about BarCamp.
  • You do blog about BarCamp.
  • No pre-scheduled presentations, no tourists.
  • Presentations will go on as long as they have to or until they run into another presentation slot.
  • If this is your first time at BarCamp, you HAVE to present. (Actually, this applies whether it’s your first or tenth BarCamp. All attendees present. It’s part of the fun.)

Ticket details will be announced soon at http://uxcamplondon.org or http://barcamp.org/UXCampLondon

You can also follow on twitter: http://twitter.com/UXCampLondon

Useful London-based UX Social Network sites

photo: http://www.flickr.com/photos/wordridden/2993726470/

This is for the benefit of those who are interested to know more about the UX community here in the UK, although these resources are mostly London-based, with spillover membership from Brighton folks.

They’ve been extremely valuable for me as a budding UX practitioner.

http://london-ia.ning.com/ or Google “london ia ning”

Many, if not most, UX practitioners use this Ning site as their social network. If there was ever a one-stop community for London/UK-based HCI/UX practitioners, this is it.

Other groups (more job spam, less discussion)

http://tech.groups.yahoo.com/group/london_usability/
http://tech.groups.yahoo.com/group/london-ia/
These two Yahoo groups are also popular for general posts. If you want a constant feed of employment opportunities (internships, job openings, volunteer opportunities, events, training, etc.), sign-up here.

IXDA.org

Not quite London-based, but has a lot of useful and practical discussions every single day. Members are mostly States-side, but is becoming increasingly international (UK esp.). Experts like Dan Saffer and Jared Spool regularly post content, which helps regulate a lot of discussions informally. Extremely useful and highly recommended.

UPA UK Chapter, http://www.ukupa.org.uk/

I think it’s worth becoming a member. Monthly events, free to members (free booze and snacks, good speaker content).

UX Book Club, http://uxbookclub.org/doku.php?id=london

You get to trash-talk your usability textbooks and classics here. Last month, we shot holes through Buxton’s Sketching book. This month, we’re doing Scott McCloud’s Understanding Comics. A good way to meet people because it’s more intimate and you talk about something in common.

Pretty much the same people end up going to these events because the UX community here is quite small. Plus, there are lots of current and ex-UCLIC students, so it doesn’t feel overwhelming.

Any that I may have missed out?

Will be attending Barcamp London 6

I just got my ticket at the very last moment yesterday, and I was psyched. And then I realized the event is taking place much sooner than I realized – this weekend. Anyway, I’m prepared to go. I sort of have an idea about what I’d like to talk about, although I’m not quite sure I will be talking. If I do, it’ll probably be about getting feedback from people who have used the Kohana PHP framework and what they think about it.

I’m not entirely sure there’ll be UX people there. Probably more developers. But I’m thinking there might be interesting things that will surface related to UX, like gestural interfaces and stuff. Who knows. This is my first Barcamp. I know nothing!

I remember that there was a Barcamp that took place about a year ago in Kuala Lumpur that I chose not to attend. I didn’t think it was going to be as exciting as the Barcamps that were taking place elsewhere. I guess I have this poor impression of the scene back home, but that’s not very healthy.

Need to make a list of stuff to bring.

The Experience of Design?

I’m currently through my second and final week of the Design Experience module – where we get into groups and use all the HCI skills we’ve learnt to good use. Our job this year is to come up with a navigational device for tourists. Our group has decided to focus on museums, and we’ve gone through user observation, interviews, personas, paper prototyping, etc. – and even though we’ve  we still have debates over whether we’re doing the right thing, sometimes.

Is this the experience of design?

I sometimes think about what’s essential past the logical reasoning for the way we design interfaces. One thing we don’t get very much in a HCI course like UCLIC’s is studio work. Unlike many design schools that function like apprenticeship workshops, we only get hands-on work during project days – hardly a chance to overcome our shyness of doing fieldwork and working with real users.

Last weekend, when I was interviewing some tourists at the British Museum, I found it really hard to come up with the right questions and help people feel at ease. I got better with each try, but it wasn’t easy. I learnt a bit of how fieldwork is done from books like “Tricks of the Trade” by Howard S. Becker, and from papers on design ethnography – hardly a core part of conventional HCI courses.

I also observed that our groups tended to talk more than sketch, prototype, wireframe, or interview. We have lengthy discussions about definitions, the usefulness and appropriateness of methods, whether certain methods were applied properly, or whether they should be used at all. Our modules constantly focus on the value of ‘reflection’, and I’m now wondering if there’s such a thing as ‘over-reflection’ vs. just-get-the-damn-thing-done… just my way of saying talk after doing rather than before.

It’s hard to learn everything in a year, but I’m getting the feeling that all this learning is preparation for even more learning – of the hands-on kind.

Already, I’m applying this as a programmer with a small startup company I’m doing some part-time work for. We hold one-day sessions where we sit around a kitchen table and get stuff done. If we need to draw references from books or methods, we do it. Otherwise, whatever works gets applied. It doesn’t have to be perfect, but it needs to function first. We’re applying design as we produce our work, not before.

Side-rant:

Recently, there’s been some debate over what interaction design is (or isn’t). Does it really matter? Is this a concern because we’re trying to establish an industry, and that we need to formalize our reputation with our clients? Maybe we still call ourselves programmers, or graphic artists, or project managers – but we do a good job of it,  because we understand more about the way things work the way others can’t. The terms, ‘usability’, ‘user experience’, ‘information architect’ and the like seem to be transitional. Who knows what businesses might call UX practitioners in 5 years time?

I do hope that in due time, more people are aware of practitioners who apply user-centered solutions for interactive systems. But it involves us going out, interacting with industry and users, and solving their problems – rather than poring over books and figures.