Interaction

I just stumbled across Cennydd’s post about ‘blaming the designer’, which somewhat reflects my work experiences in the past year. I too, found the “design hell” comic to be humorous, and admittedly counted it as gospel truth initially. Then I forgot about it and like all designers/developers, went back and dealt with the hard stuff and worked until our product was finally launched or finished.

Aim for the finish as a team, not for the journey

And so, a few weeks ago on the eve of Christmas last year, we launched our site live. My client, my boss, was happy with the results and our effort to implement tiny changes at the very last minute, and I admit I’m happy with the outcome myself, despite all the ranting and heated arguments about things like how consistency in design isn’t everything and about not adding more ‘unnecessary’ features. It was satisfying to know that my client was happy – that we had produced something that was ready for launch, live. And I think that’s something all designers and developers need to keep in front of their minds, rather than the course at hand.

The opportunities are in our hands

We live in a world that’s increasingly complex, and we appreciate and learn of each other’s strengths in bits and pieces at a time. To this end, I admit my own shortcomings of not being able to bridge the gap between business, marketing, design and engineering more effectively for my client. I now believe that creative freedom comes with caveats, and it is rare that clients will allow designers all the freedom in the world. It is increasingly becoming the designer’s responsibility to seize the opportunity to educate and collaborate with clients to solve problems ‘the design way’, meeting both design and business goals.

I see this as a major opportunity for creative types – designers, content managers, UX consultants, even developers. This is because clients know they are partly ignorant about design and are willing to hear what we have to say. At they same time, they’re not going to back down on what they know best about business, and we need to be sensitive to that.

Putting things to practice

So how would I react this time around?

I think, for a start, my attitude has to be right. I need to stay positive and not try to put down the ideas that come from clients. I should give credit where credit is due, and understand that not every solution is ideal. In fact, some of them are hacks due to various factors like time or lack of knowledge. As iteration is always possible (especially for the web), this isn’t a big problem. Solutions can always be improved, and it’s best to allow some “hacks” to pass, and learn from it through testing and user feedback.

I also feel documentation is key, and putting things down in black and white makes it easy for everyone in the team to see how the design has progressed from day one. Everything that’s documentable is valuable – wireframes, sketches, screenshots, feature requests, reasons for change, points of argument, etc. While I don’t think everything has to be documented, our team did make use extensive use of tools and artifacts to facilitate communication. So, use them wisely.

Finally, the success of the design should be celebrated at the end of a major phase. I somehow feel the best person to do this is the client, but this doesn’t always happen. In some ways, the client’s utmost satisfaction acts as a major milestone in the outcome of a project. In my case, it was my boss’s satisfaction and decision to launch the site live. He brought in a bottle of champagne and we toasted to the launch on Christmas eve, which helped to finalize a major phase in the project and ease fears that we might be carrying on throughout the holidays.

Whatever it is, we all crave to closure to our efforts, some space to regenerate and look forward to our next big task.

boon :: Jan.08.2010 :: design :: No Comments »

If you’ve ever watched Gary Hustwit’s Helveticaor Objectified, and can relate to the uber-geek sensibility of how design affects the way people live, you should also watch Stewart Brand’s series on “How Buildings Learn”, which incidentally is also a a book of the same name. I’ve even embedded all six episodes below for your convenience.

This says so much more than some overly-polished, high-profile, consultant friendly, overpriced user experience books I know.

Here’s a quote from the author, writer, and presenter himself, Stewart Brand. Simply amazing:

This six-part, three-hour, BBC TV series aired in 1997. I presented and co-wrote the series; it was directed by James Muncie, with music by Brian Eno. The series was based on my 1994 book, HOW BUILDINGS LEARN: What Happens After They’re Built. The book is still selling well and is used as a text in some college courses. Most of the 27 reviews on Amazon treat it as a book about system and software design, which tells me that architects are not as alert as computer people. But I knew that; that’s part of why I wrote the book. Anybody is welcome to use anything from this series in any way they like. Please don’t bug me with requests for permission. Hack away. Do credit the BBC, who put considerable time and talent into the project. Historic note: this was one of the first television productions made entirely in digital— shot digital, edited digital. The project wound up with not enough money, so digital was the workaround. The camera was so small that we seldom had to ask permission to shoot; everybody thought we were tourists. No film or sound crew. Everything technical on site was done by editors, writers, directors. That’s why the sound is a little sketchy, but there’s also some direct perception in the filming that is unusual.

Part 1: Flow

Part 2: The Low Road

Part 3: Built for Change

Part 4: Unreal Estate

Part 5: The Romance of Maintenance

Part 6: Shearing Layers

boon :: Nov.15.2009 :: design :: No Comments »

I feel really guilty because I’ve been neglecting this blog about interactions, especially when almost everything I do for a living involves designing for interactions.

Instead, I find myself spending more and more time blogging about careers, which in a way doesn’t have anything to do with interaction. Except for one thing – the human condition.

The real kick behind designing any interaction is the effect you get when a human being interfaces with it. Whether it’s good or bad – it’s one of those things that turns me on like nothing else – seeing someone actually interact with a dumb thing you actually built and expressing an emotional response from it.

But when I go out and read all the blogs that talk about user experience, interaction design, usability, bla bla bla… so much of it is so arcane that my eyes start focusing beyond the screen into emptiness and my mind begins to chant mindless syllables.

UX is losing its Touchy Feely

What ever happened to all that user magic that Norman used to talk about? The stuff where he’d complain about the affordances of door handles being one way and not the other and talking about how people would get confused and how we ought to design to love and make people feel nice and fuzzy inside. What ever happened to that?

Now, the only thing people end up talking about are new things that were invented two hours ago – Experience Themes? Who writes a blog post titled so arcanely these days? I thought we were much better at copy than a lot of other people.

And look at how much time went into creating this user journey diagram. It’s pretty, but I don’t know what in the world it’s saying. I showed this to some colleagues of mine (folks who actually do “get” UX common sense) and they too couldn’t make head or tail of it. And this came up tops on Google. :-/

No One Understands Us Outside of Us

Why can’t we just stick to simple terms and communicate things clearly and simply? Do our customers, bosses, users, readers, colleagues and friends really know what we mean by all these words we use? It’s funny how we spend most of our time building for these people, but talk in a language that doesn’t make sense to them.

Are we as designers supposed to build things that way – where we act as folks who fix things and have our own codes of conduct, and can never have normal conversations with the people we solve problems for?

UX Designers aren’t really Designers if they’re more Geek than Human

We compare ourselves with engineers and say we’re more user friendly, but there’s no doubt that every UX person I know is a geek in their own way. They just don’t do code, that’s all.

I prefer a person who does code, because it’s one level below the abstraction layer (towards the technology, not away from it). You can’t have a web UX designer without a programmer. The programmer gets to call the shots, because he actually builds the stuff that makes it work. UX designers ought to pay some respect to the engineering community who built the thing in the first place.

A UX person only has my approval only if they really do care for other human beings, and tell me about their stories. Don’t talk to me about methods or crazy terms and phrases, because I can toss that out and use something else that works. Just because engineers have fancy names doesn’t mean UX designers need them too.

Speak English?

Engineers need fancy names because computers can’t speak for themselves. UX designers already have a language they can use that’s already widely available, is extremely portable, and is fairly universal – it’s called English. They don’t need to invent new words to describe the things they do, which by the way, was copied and stolen from other disciplines like psychology, sociology, marketing, management, etc.

To be fair, I’ve had my share of that design-speak. But I’ve gain nothing except credit from other fellow designers who’ve done the same.

If designers can focus on explaining and speaking out what really represents people who use technologies, it would be a lot better for everyone… rather than inventing new languages to use between themselves.

boon :: Oct.07.2009 :: design, user experience :: No Comments »

Visual Thinking for Design (Morgan Kaufmann Series in Interactive Technologies)

I was one of the lucky winners of this book from Morgan Kaufmann after I donated some money to the IxDA fundraising initiative. After turning in my MSc Project dissertation, I finally had some time to catch a breath. You’d think that reading a book on Visual Thinking would be the last thing on my mind after losing weeks of sleep to writing… I’m surprised myself.

Anyway, at a glance, this book is about understanding how we as humans interpret and interact with objects and environments visually. It’s written mostly from a psychologist’s perspective, and provides useful references to the theory and science of visual perception, cognition, attention, etc.

Colin starts off talking about how the eye and brain processes and perceives visual stimuli, and each chapter concludes with a set of design recommendations. He gradually works upwards the abstraction layer, dealing with topics like color and shapes, the relationship between visual and verbal processing, the process of “seeing” or “thinking” by sketching, leading up towards how we perceive meaning in a visual world.

I felt that I understood the subject matter a little better because I learned about cognitive science during the HCI course, so readers who are new to psychology may initially find it slightly alienating. I also feel that designers who are looking for design ideas may not find this book as an inspirational resource. I see this as reference material – something you pull out to make sure you’re doing things right, like getting more substantial evidence to support design ideas in problem solving.

It’s also a fairly easy book to read. Despite references to psychology terms like V1, V2 and top-down/bottom-up, the author succeeds in explaining things in simple language, and provides good examples of how the science of visual perception is linked to visual design.

The best parts of the book lie towards the end, and I think that the early chapters act as building blocks that support the overall perspective summarized in the last few chapters. The gist of it is that our mind, eye and body works together to look for patterns in the world, and that understanding how this takes place can aid designers in helping users to make sense of things more clearly and easily.

The implications on p. 172 are a key takeaway:

1. to support the pattern-finding capability of the brain; that is, to turn information structures into patterns
2. to optimize the cognitive process as a nested set of activities
3. to take the economics of cognition into account, considering the cost of learning new tools and ways of seeing
4. to think about attention at many levels and design for the cognitive thread.

(The word ‘cognition’ refers to the “process of thought”, i.e. thinking.)

In summary, this book is worth an investment. It’s one of those resources I will occasionally refer to for clear, evidence-based recommendations for visual design.

boon :: Sep.04.2009 :: books, cognition, design :: No Comments »

I was having a reflective conversation with Darren on our way home from Cambridge the other day, after our meeting with Microsoft about our MSc projects. The both of us had very similar experiences stumbling upon UX.

In fact, i had come across it from understanding usability, or more specifically, web usability. And I think I was most familiar with the work of Nielsen’s first book, Designing Web Usability, that led me there. I had no idea (at the time) that it was related to HCI in that sense, which I acquainted mostly with robots and artificial intelligence.

But between that time when I first started learning about HCI and User Experience, to the point I really understood what it was – took about 6 months. That’s 6 months of constant, thought-provoking, soul-searching months – and not something I kind of stumbled upon and appeared to me in a flash of light.

That got us (Darren and I) thinking – if it took us that long to “figure out” User Experience, how long does it actually take regular people to understand it? And some of these regular people can end up being our clients, our bosses, our customers, our co-workers. Do we need to take this into account when we’re trying to communicate the stuff to people, and just be patient about it?

Or, could it be that people do get it once they actually see it work – as in, good design blends into the background – you don’t even notice it’s there.

But some of this matters, right? When you’re trying to communicate design in a project, or when you’re trying to sell a concept to a client, or when you’re trying to push forward a piece of work that no one else seems to understand except you.

My question is – does it matter? And if it does, how can we communicate user experience in the most effective way?

boon :: Jun.30.2009 :: design, user experience :: 1 Comment »

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’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 have a feeling that my group is suffering from a type of paralysis that makes it hard to produce sketches. But sketching is exactly what we need to do. We’re almost halfway through our two-week intensive Design Experience module, where we have to come up with a navigational device for tourists and present our work in the form of a poster. And the only way we’re going to arrive at a design is by sketching it out.

But I have a feeling that some of us feel that sketching should be a “finalized” output. That one or two should be fine. And we spend time instead discussing what the sketch should look like rather than actually doing it.

Then, I stumbled across this post on metacool, and it gave me a sense of comfort that design isn’t about being as good as someone else or something else. In fact, there are probably a ton of stuff that expert designers have produced before stumbling upon “the right one”. Sometimes, we just need to get over ourselves and get stuff done.

That being said, sketching is an art, not a science. I’ve used it in at least these following ways:

• to understand high level requirements
• to visualize types of designs
• to visualize ways of presenting information
• to illustrate flow and sequence
• to illustrate interaction
• to provide contextual  background
• to highlight portions of a design
• to consolidate designs together
• to tell a story

There are probably a million other things you could do with sketching, and that’s the point. It’s a visual language. Think about the million and one ways you could say “hello”, and try to put that as a sketch on paper.

I guess I consider myself lucky that I got into comics at a very young age, not just reading them, but drawing my own comics. Sketching was just part of the whole process. It does takes practice, and after the millionth time you’ve drawn a wireframe with pencil and paper, you’re not going to ask the person next to you – “so, how do I do this?”.

So, I guess I should get on with it.

boon :: Mar.20.2009 :: design :: No Comments »

A List Apart recently published several articles about Web Education, spelling out the inherent difficulties for students to come out prepared for jobs in the web industry. While I can surely sympathize with that, myself being a practitioner for several years, I can also see how academic institutions struggle to reconcile pressure from the perspectives of research, teaching, and learning.

Contrast this to simply “learning on the job”, there’s a huge amount of tacit knowledge that you can acquire in a relatively short period of time, but only if the conditions are right. Surely, in industry, you do it every single day. But in class, it’s quite hard to teach that to students who haven’t quite grasped what it’s like to work on websites or other interactive systems on a daily basis.

The Interaction between Academia and Industry

The HCI program at UCL tries very hard to give students a good flavor of not just the academic and theoretical side of things, but the practical side as well. And because of its strong background in psychology and computer science, there may be a tendency to think they lack the kind of practicalities designers live by on a daily  basis – but the people who run the program understand this and design does have its place in the program.

Certainly, in the academic community for HCI, design is seen as a black box – as though some kind of magic takes place whenever you design a website. But there’s a whole lot that goes on in the design process. And I’m glad to be given the opportunity to not just learn the skills that are required, but to see the history of both industry and academic trends evolving over the years, which tells you a lot about the different perspectives of the industry, which is probably why we have so many terms for practitioners (e.g. information architect, usability engineer, interface designer, etc.).

However, there has been significant contributions and conversations from both sides. Norman and Nielsen have a long history in the HCI community, whose works are often cited. On the other hand, you have folks like Alan Cooper and Steve Krug who are more known in industry.

Straight from the Horse’s Mouth

One of the things that UCLIC has done from the very beginning (back when it was more strongly associated with Human Factors and Ergonomics), was to have people from industry come in and give their perspectives of what the ‘real world’ is like. It’s an optional session and we don’t get slapped for not coming in, but it’s such a good way to hear so many different perspectives from people in industry.

We’ve had ergonomists who’ve done work on air traffic control centers, information architects who have done work on massive knowledge systems and even simple sites for financial institutions, interaction designers and user experience researchers from Microsoft and Google, all-rounders from small design companies like Clearleft, usability practitioners who do work on game testing…

It’s just amazing to see the spectrum and application of HCI in industry.

They come in different shapes and sizes

Although this sounds like a plug for the program that I’m attending, I really don’t know what other programs are like. I certainly considered a more design-focussed program like the ones offered at the University of the Arts, London or Savannah College of Art and Design. Even my alma matter, the University of Kansas, has begun offering modules in interaction design. But since my background is deeply technical, I went for something more HCI-based, and hoped that it would give me some exposure regarding design (it has).

I appreciated that the different terms (IA, UxD, UX researcher, etc.) meant something specific, even if one person seemed to be doing all of them. An information architect may be doing usability work, but not the other way around sometimes. Also, if you’re a designer, you’re not always equipped to do good qualitative research about user behavior, even though it may be extremely helpful to your work – while anthropologists do this every day. Engineers have insight to how technolgy works, but psychologists are needed to show how the mind works.

It’s during the practice seminars that I got the sense that I don’t have to box myself in a particular category, but that it’s just learning to use my skills and presenting them appropriately to whoever is consuming my services – and to embrace the constantly changing nature of the field.

boon :: Mar.05.2009 :: design, education, uclic, user experience :: 2 Comments »

The duration of the flickers (not flickrs) that are used to demonstrate Change Blindness in the video posted in the link below only last a few miliseconds, but it’s a powerful visual tool to demonstrate just how easily it is to lose a reader or viewer’s attention.

This means that visual clutter can have a major effect on interface design, if not used in a purposeful way. More so  because of the interactivity of sites – how is the site designed for the user’s goals? And issues like whether distraction is appropriate, and even branding and immersion can affect the overall experience for users.

link

Okay, so maybe pages aren’t designed with milisecond lapses of flashing gray blobs, but what if a sidebar that presents new information keeps getting missed? What about ad placements? A good place to start might be theory, so some Gestalt psychology might help:

Closure

Proximity

Continuity

Similarity

Pragnanz

Basically, these funny shapes just mean that people tend to group things together to form some kind of meaningful unit (the closure pattern looks like a circle, the proximity pattern makes the four blocks look like one unit, the continuity pattern makes the user want to fill in the blanks, and there’s some kind of vertical order in similarity vs. a vertical one). There are more laws, but the basic gist is – things need to make sense, and here we have visual representations that are more likely to be in one order than another.

In summary of these laws, the law of Pragnanz is sort of an overriding principle – one to rule them all.

Couple this with Change Blindness, and you might wonder how these patterns may help to either diffuse or illuminate particular elements. Visual clutter can be easily achieved by dumping a random collection of these patterns into one thick slush.

Add to that the tendency for users to leave your site within seconds of not finding what they want.

Caveat emptor. Design isn’t just a pretty thing.

boon :: Mar.02.2009 :: cognition, design, user experience :: No Comments »