Interaction

My very first attempt at incorporating a user-centered design approach in my software development project was, in many ways – an important start for me, career-wise. It’s because of that project that I am where I am now – I would certainly not have been accepted into the MSc, which subsequently opened a lot of doors for me in the UX industry here in London.

But, despite all that, that project was a failure from a UCD and “business” perspective. Firstly, the interface felt too much like Flickr. Then, our team was fairly novice so our interview data wasn’t very promising. This caused the personas to feel sort of half put together. The end result was somewhat lacklustre – in some ways, we could’ve delivered the same thing by getting inspiration from other websites and not having to use Cooper’s Goal-Directed Design.

However, to stop there would be to completely miss the point.

Introducing UCD – the first round might not count

I insisted on using a UCD process not because I wanted to deliver something spectacular, but because I wanted the team members to see the value of a UCD process. Or, perhaps more accurately, it was mainly just me who was keen on seeing the value of a UCD process (and to see if I could do it).

This is where I think a lot of projects tend to reject UCD – when they can’t see any results.

It’s easy to run a company with an “efficiency” mindset – it’s sort of built into the status quo. Everyone is reluctant to change – not just management. So, I didn’t just have problems with my line manager – I had problems with my team members. (thankfully, my interviewees were really helpful). No one except for myself was really looking to see this succeed.

So, of course – how could I expect it to succeed?

The process reveals not so much results, but opportunities

The effort of building applications is often a team effort – not just one UX person calling the shots. But valuable lessons can still be gleaned from UX failures, much more than they can from plain old technical failures – mainly because that additional perspective from the user is so raw and tangible that it almost creates some kind of “why haven’t we done this earlier” response?

When team members get thrown into a UCD process – they don’t realize the potential “failure” of the outcome, they look at the process and the value of that access to users they finally get – something they never used to have in the past. Suddenly, they realize it is possible to build applications based on user research, user feedback, and purposeful design.

Developers and designers all need to realize that there are many ways to build an application, and sometimes it makes sense to learn a new tool so that the right one can be used for the right job. Introducing UCD to a conventional software team can sometimes help them gain ideas to make things better.

I took those lessons I learnt from the failure with me, because you never unlearn an experience like this. You just get better. And now I realize just how much more UCD is like craft than science.

boon :: Jan.27.2010 :: development, user experience :: No Comments »

Everyone’s hyped up about getting a Google Wave invite. I have one and I don’t see what the fuss is about. Yes, I’ve seen the YouTube video, and yes I’ve watched the Developer Preview video too. It looks great and all, but seriously folks – it’s one complicated thing… next to email.

And this is why Google Wave isn’t about email. The same way computers aren’t (just) about calculators.

What it is is real-time collaborative messaging with historical playback. Which, granted, is very good for real-time anything. Except that real-time in human terms is highly contextual.

Because people have better things to do besides sit in front of their computers all day long, they are much better off carrying Blackberries and having push email rather than collaborative messaging. In my opinion, push email works just as well – because you don’t need to be in front of a computer to communicate with your colleagues.

Wave is also a tool. Meaning that the interface itself is not the message. In order for users to synthesize information, they have to make sense of it in a collaborative sort of way, which means paying attention to whatever is happening in that messaging window, which takes up at most 1/2 of the screen. It looks and feels like, a video player – but for messages. Think of IM on steroids, not email.

Email works because it’s mind-dumbingly easy. And because of that, nobody needs to take 3 week lessons on how to use email – and that includes your grandpa. And because it’s so atomic, it can easily be transported as a message to any other atomic messaging forms – SMS, blog post, forum post, IM chat, whatever.

Waves, on the other hand, are almost asynchronous streams – anyone can start writing content at anytime into a wave, and hope that it doesn’t make a mess of the conversation. Last I checked, people still pay attention to body language and subliminal messages, both of which are devoid in Wave but affects the way people communicate collaboratively and socially together – i.e. turn-taking and all that jazz.

Which part of a wave is atomic? You have to spend effort to calculate and decide. Then you have to find a way of “clipping” that message – and how do you make it portable? Can you cut and paste portions of your wave onto your blog? SMS? can you print it out?

Like email, most of what is published gets fixed in time. But a Wave, is a collection of content played out over time. Just like how photographs put together over time become videos. But with the added complexity of multiple sources of photographs, it becomes more and more difficult to separate and organize content in a Wave.

And that’s why Google Wave is not about email.

Sites and Articles Relevant to this Post:

• It’s Just Fancy Talk
• EasierToUnderstandThanWave

boon :: Oct.13.2009 :: interaction design, technology, tools, web :: No Comments »

I love this idea: http://www.somebits.com/weblog/tech/good/webapps-with-json.html

boon :: Sep.21.2009 :: interaction design, web :: No Comments »

What I like about A/B Testing using Google Website Optimizer:

• It helps provide real, direct data (as opposed to sheer guesses, or “eye-balling” secondary sources of data)
• It helps you build strong skills in testing
• It’s fairly straightforward to setup
• It’s fairly flexible – allows for HTML markup, etc.

See how 37 Signals puts A/B testing to the works here.

See Carsonified’s blog post about doing A/B Testing with Google Website Optimizer on Wordpress here.

For a quick overview, watch the video from Carsonified below:

How to do A/B Testing with WordPress

boon :: Aug.03.2009 :: evaluation, resource, tools, web, websites :: No Comments »

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!

boon :: Jun.12.2009 :: tools, web :: No Comments »

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.

boon :: Jun.07.2009 :: design, development, user experience, web :: No Comments »

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.

boon :: Mar.26.2009 :: development, events, technology :: No Comments »

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.

boon :: Mar.24.2009 :: books, design, interaction design, mobile, user experience :: No Comments »

I started my first web log on Blogger years ago, probably in my little corner of the office as a software developer. At the time, it was just a way to post up random stuff about life, but over the years I slowly realized the potential it had to touch other people’s lives (as well as mine). But by the time I had realized that, I had put up so much junk on my blog that no one would ever read apart from myself, I feared no one would ever take me seriously.

So, I launched a separate blog to discuss about more serious things I cared about, like jobs and careers. And then, when I got into the masters program, I launched this blog, to talk about UX. Now, I manage three blogs, plus a food aggregator that caters for two countries I currently don’t reside in, and that can be a lot of work, sometimes. That’s when I start to relate to some people about what blogs are about, and what they should be, and what they’re not.

So sometimes I think it’s a way to post random junk. Then I think no, it’s a way to inspire others. Then, I think… no, I should make it sell – sell my ideas and make me rich (right).

And the plain fact is – it’s just a tool, dammit. Use it however you want.

*bonk*

Recently, a classmate of mine who is a total news junkie (his own words) introduced me to Dave Winer’s blog, Scripting News. Any self-respecting internet pundit would know about Winer’s claim to fame (the invention of RSS). He is someone who the NY Times calls, “The protoblogger”. Thus, skimming through his articles, I caught glipses of his “proto-posts”.

Dave’s posts are brief, but packed with insight. They are personal, but not revealing. They are vocal, but not contentious. And I think there is a lot of variation as you move out into the blogosphere, but Dave’s blog is like smack in the middle.

And if I ever really needed to give a good definition of a blog, Dave’s would be it.

So, there.

boon :: Mar.15.2009 :: social web, web :: No Comments »

I’ve just spent the last 10 or so hours mucking over Kohana, Doctrine ORM and jQuery – all of which I really enjoy and think are great, but I’m starting to doubt my own ability to code. Do Javascript programmers spend more time building functionality and interaction, or mangling the libraries and fussing over browser compatibility? While I think jQuery is a brilliant API, I’m always wary of the quality of plugins that people write. Same goes for Wordpress plugins. I guess free does come with a price (like the price of not using Java).

Which leads me to think – can there be a lone UX expert who also does web development? I’m sure there are folks out there who make a living doing this, but the literature treats the fields so separately it’s hard to see how these experts manage the line between the two.

Even with a team of two people – a UX designer and a web developer. How do they interact? Does the UX designer have a head start to come up with all the wireframes and storyboards, who then hands it over the programmer to make it functional? Do they work together in an agile fashion?

I think that as most technical work goes – there’s less and less breathing space for UX designers and web developers to work in very small, efficient teams, unless they are very, very good. I’m not saying that everyone else just sucks, but building websites can take a lot more time than you think it does, and unless you’re designing mom and pop websites all the time, it’s going to be hard to guarantee how much time is required to build good sites.

While plugins and APIs can be useful in increasing speed, they also can lock down the interaction and degrade the user experience if not planned well. Maybe established sites understand this all too well, and take a phased approach. Maybe this is why Flickr only launches a new (but exciting) feature only once every few months.

I used to think that as technology improved, so would our ability to build products. But I find that this isn’t always that simple. In fact, despite all the effort being put in to build so many plugins, APIs, platforms, patterns, components, etc – it still takes a lot of effort to put things together properly.

Thus, all software is bespoke, and are not exactly a lego-like mashup of neatly interfacing components that we tend to think it does.

My only question is, if we are to get better, how? Apart from being willing to devote ourselves to our tools and simply, get our hands dirty.

update: I found this presentation from Leah Buley from Adaptive Path, which she gave at SXSW’09. It comes quite close to what I was talking about. I’m not quite sure it always works out so simply, but I like the idea.

boon :: Mar.14.2009 :: development, interaction design, user experience, web :: No Comments »