Tag Archives: books

I just finished reading Giles Colborne’s “Simple and Usable” – a delightfully compact, practical and highly readable book about interaction design. I’m glad the book isn’t one of those books that tries to solve everything about interaction design. Instead, it’s a book from a designer telling stories about his experiences solving design problems to someone who is interested in, but may not be an expert in the subject.

I did find the initial part of the book about design approaches a bit straightforward, mainly because it contained a lot of good design principles I had been hearing a lot elsewhere as well. However, I think it was a necessary in order to provide appropriate context for the four strategies for simplicity, which was the main focus of the book.

However, the main strengths of this book is the way it unfolds. Each page is provides a little story or lesson with a nice big photo next to it, and you’re not forced to dig too deep into theory or complex abstractions. The stories, when added up, provide a sort of perspective about design that’s actually quite holistic. And because each story was neatly fit into one page, it felt as though I was having a conversation of sorts, with the author narrating his experiences around this subject.

This is a really great way to explain design, because it’s not a hard science, but neither is it completely subjective. When I was fairly new to design, one of the hardest things to understand was how designers think and work. There are a ton of design books out there, many of them are either too technical, too sublime, too visionary, or a combination of the three. I still find that as a practicing designer now, we don’t talk enough about our experiences in doing design and fetishize outputs and ideas all too much.

It’s hard not to recommend this book to anyone. I really think it’s a very usable book, and it’ll be a staple on my bookshelf to remind myself of the little things that I need to consider when I think about my work.

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.

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.

I am drowning in a sea of stuff! Is it me, or is there just too much information out there about UxD, IxD, IA, human factors, etc. I haven’t even done my first proper wireframe sketch. Maybe I just need to back off for awhile and give myself some tiny projects to focus on, until I get the hang of the tricks of the trade – aka. sketching, prototyping, powerpoint presenting, design, etc.

The more stuff I learn, the more I realize how much I don’t know, the more paralyzed I feel about doing design. It’s worse than having writer’s block. It’s like claiming to know something I absolutely have no clue about, or having all that information in the head and not being able to make sense of it.

I’m learning though. Like, I found post-it notes to be really useful in coming up with rich pictures (something we learnt in Organizational Informatics) and other relational diagrams. I recently used them to produce a diagram describing the various roles, artefacts and relationships at the London Underground. This was produced from textual descriptions of the relationships, but it’s easier to see it visually.

I’m also in the process of downloading tons of podcasts, some of which I can never recall later, but it gives me comfort knowing that it’s there and and I know what Gerry Gaffney sounds like, and what he does, and the same goes for Jared Spool.

I’ve also been twitter-ing a lot, and following the messages posted by some relatively active UX folks. the amount of traffic and information that I get from that is also, overwhelming. I tell myself that being in the conversation pays off, because it somehow comes back to you. Even though I have little understanding of whether ‘leading’ and ‘line-height’ can be used interchangeably, I’m sure it’ll come useful in the future. Note to self: finish the “Stop stealing sheep” book.

And talk about BOOKS! There are so many books to read. I’m now halfway through Buxton’s Sketching book (design), Becker’s Tricks book (sociology/anthropology), and Fogg’s Persuasive Tech book. Not to mention Cooper’s Inmates book which I take on the tube whenever I go to Ikea.

I hope this is just a phase, and that it’ll pass. For now, I may be a subject for sensemaking.

A year ago, I stumbled upon a large green book by Alan Cooper and some of his friends. I was browsing for some material on Interaction Design, and this book provided a very sound basis for implementing software unlike any of the software development books I have read.

The book was called About Face.

It was first published in 1995, and the book I had in my hands was in its third revision.

This was the book that ultimately changed my life. A textbook no doubt, but it was so practical yet poignant that I could no longer implement software the way I had been doing in the past.

There have been many, many other books written on the subject. Why this one?

Well, I believe it was because Alan himself had once been a software person himself. After many years of pioneering software systems, he came to realize the paradox that software doesn’t always make users more productive. In his seminal book, The Inmates are Running the Asylum, he described how software is often written for software people, not normal people, and this ultimately causes a lot of problems.

… I ceased all programming to devote one hundred percent of my time to helping other development firms make their products easier to use. – Alan Cooper, The Inmates are Running the Asylum

In a way, his perspective of interaction design often considers the possibility that his audience may include software people. This isn’t obvious to non-software people, who read this book just like any other text, but it is written in the style of common software textbooks (e.g. Java Network Programming published by O’Reilly).

Unlike Sharp, Rogers, and Preece’s more common academic text, “Interaction Design“, Alan’s book cuts to heart about effectively resolving software’s most dangerous problem so far.

This wasn’t just useful to me as a software developer. It is a fundamental shift in the way software is being developed. It begins with users, rather than schematics and requirements. It tests on user goals, rather than functional specifications. It makes users the center of everything, and how software should be designed for users, and not the other way around.

It offers a pragmatic framework for building software towards the one thing that makes it truly successful – that it brings the most good to the largest amount of users who use it. It’s so prescriptive that it was quite hard to ignore.

If you are committed to improving the world by improving the behavior of digital
products and services, then I welcome you to the world of About Face. – Alan Cooper, About Face 3

That was a year ago.

Now, I am writing this article in my rented room in North London, waiting for the weekend to arrive. I’ve got a stack of books on Cognitive Psychology, Ergonomics, and Research Methods on HCI on the table. My green tea is getting cold, but I’m excited about the possibilities ahead of me.

I’m about a month into UCLIC’s HCI MSc, and really getting to grips that this field which dawned upon me in the past year isn’t just plain common sense.

I was talking to a CEO of a fairly new startup. He was interested in recruiting me as part of his mobile software development team, and I was reasoning to him why this MSc was more important than a shot at software success.

It went something like this:

“Of course our objective is to make software usable”

“Users are very important to us”

“We wouldn’t sell it if users found it hard to use”

But the more I investigated, the more I realized that their setup was as common as any other software development firms. Their whiteboards were filled with class diagrams, possible feature lists, a development team roster. The cubicles were very open-plan, very developer friendly. I wouldn’t doubt that this team could pull off a very decent software package in a very short time.

Still, I still hadn’t the slightest clue who the intended user was.

“Mobile users”, I was told, “who have friends,… and family”.

I would have bought it two years ago, but I’ve already gone through the Matrix experience. I was having to choose between the red pill or the blue pill.

Swallowing the red pill wasn’t easy, but I still believe I’m doing the software industry a big favor. I love software, and I want to see it succeed. But it can’t be at the expense of users. So, in a way, I’m starting again from scratch.

So, thanks to Alan Cooper, I’m now officially part of the world of About Face.