It’s ok to not like things, just don’t be a dick about it.

1. The Design Problem
2. Requirements, Scenarios & Task Analysis
3. Prototyping
4. Sketching
5. Design Judgements
6. Visual Design
7. Visual Communication
8. Interfaces
9. Personas

If you’re from a design background, you’re probably looking at this and going… WTF? Task Analysis? Interfaces? Personas? What does that have anything to do with design?

The graphic design course outline from Central St. Martins makes a bit more sense. I wish we had learnt more about sketching as a thinking tool (not as a drawing tool), about exploration in creative problem solving, about the various modes of working (individual vs. collaborative), about the different ways other designers produced their work as well as the various graphic design areas (photography, typography/letterpress, print, animation, etc.).

However, I actually think that the module hasn’t done much damage. I still see a lot of UX designers use patterns, tools, and processes as a starting point – when we should only be considering those when we’ve fully understood the fundamentals. I sometimes wish we could have sessions where we deconstruct the patterns, tools and processes we’re so used to – just to get at the essence of creative problem solving.

While I don’t discount the value I’ve gained from learning about cognition, affect, organizational psychology, ergonomics… it’s good design that really makes all those skills truly worth something.

And while I’m giving my alma mater a hard time here, I’ve also heard criticisms about CSM being too open and exploratory. Maybe we should get UCLIC and Central St. Martins to trade students for half a year.

That would really mess things up nicely.

In addition, there’s been a lot of conversation and interest from the UX community in this area – e.g. Jason Mesut’s rant on UX portfolios (sign-in required), Don Norman’s “Why Design Education Must Change“, Mozilla Labs’ first Design Jam event in London and my own conversations with Ian Fenn, Jeff Van Campen and Lane Halley about engaging in and improving Communities of Practice in the UX industry.

Broadly speaking, there are three main issues that practitioners and the industry is experiencing right now:

• The huge gap between research and practice
• Challenges faced by junior and non-UX practitioners seeking to gain employment in UX
• Difficulty for employers to find UX candidates who can articulate and present good design thinking

These issues are complex and extend beyond the point of this blog post, but I think that apprenticeships would be a good way to resolve some of these issues.

Why Apprenticeships – a Case for Situativity

This paper on “learning approaches for teaching interaction design” by Dr. Corina Sas does a really good job of explaining the challenges and possible improvements to IxD instruction. The four main approaches she suggests are interrelated (apprenticeship, constructivism, experiential learning, and situated learning & community of practice), but the gist of it is that IxD (and related UX disciplines) is more craft than science (though the science bit is still really important), and that what’s lacking is a systemic approach to procedural over declarative learning.

This seems to be a common observation elsewhere as well.

In the past few weeks, I’ve had the chance to experience this working alongside a more experienced IA. I was working on a product browser that would sit on the homepage on a site I was redesigning. Through our discussions, we came up with a better way of displaying the products and it was only because the senior IA had given me additional insights that helped me think more creatively about the solution.

I know it sounds really trivial as that insight could’ve come from anywhere, but I gained new IA skills by being a participant in the ”working out” of the solution together through discussion, observation, pen and paper, and our understanding of IA (see situated cognition).

Destroy Perpetuating UX Myths

In Jared Spool’s presentation on “The Dawning of the Age Of Experience“, he explains that design decisions can’t always be interrogated. He used examples of sushi chefs, midwives and chicken sexers who, through experience, just happen to “know” what they’re doing is right or wrong. As practitioners we can sometimes end up using our UX methods as a ‘design crutch’, and end up perpetuating the myth that it’s the right way to do design.

Jared’s research has shown that design decisions can come in five flavors, and that “activity-focused design” (expert reviews, heuristic analysis) and “user-focused design” (contextual research, ethnography) are only two of those. “Genius design” (like chicken sexing, midwifery) happens to be no. 3, and observes that this genius design is “a solid style that often has positive outcomes“.

He too, suggests apprenticeships as a way to get to good design.

Models of Apprenticeships

How can we get this thing moving? I think that apprenticeships (or shades of it) can come in different forms, and it’s up to the individual to seek out those opportunities and make the best of it. There are a few ways it could start or take form:

• An Apprenticeship Program where an experienced designer meets with a mentee/apprentice/protege and scopes a project in order to build an end-to-end case study of the individual’s work, which can then be communicated through a portfolio of some sort (as described to me by Lane Halley)
• A self-initiated scope of work/issue/topic by the practitioner alongside a mentor, in order to work towards some career goal (works well for mid-level practitioners who already know the basics and need to address gaps)
• An internship (though I feel internships can be abused, too) for an intense, short project (see Leisa Reichelt’s blog post)
• Internal apprenticeship programs (here’s an example)
• Working alongside senior practitioners in-house (my product browser example)
• Design Jams, but I think this will require some coordination and involvement of expert designers co-designing (rather than advising) with less-experienced designers for it to work well

As the field becomes increasingly multidisciplinary and complex, I don’t see how it works just to work alone and improve as a designer. At the same time, I don’t think we have the luxury of reinventing the wheel all the time, or perpetuating outdated methods and concepts. Maybe one way to formalize this is to improve on the mentorship programs available through the UPA, IxDA and IAI, and encourage more participation and involvment from the community. I just hope it won’t be a case for us of getting to a point and being comfortable that design should be done a ‘certain way’.

I was fortunate enough to get a ticket at the very first Design Jam today. It was put together as part of Mozilla Labs’ work to encourage ‘open design’, and runs in the spirit of developer ‘hack days‘, but mainly aimed at UX designers (the first of its kind?). I’m happy to say the event was successful in generating a lot of conversations, getting involvment from the local UX community and beyond, and getting people excited about UX.

I was looking forward to seeing how other designers approached UX, looking to gain insight and value from other practitioners’ work. Although I expected many more UX people to be involved, there weren’t many experienced UX practitioners who participated. Still, I learnt a lot from my teammates who came from varied backgrounds (dev, research assistant, comms, anthropology, veteran generalist).

Here are some of the positive points from my experience with Design Jam:

1. It’s a whole level of experience doing design itself, as opposed to learning about it from books and events. Design Jam succeeded very well here.
2. There was good diversity of skills - many people I’ve never met before, and certainly had the pleasure to work with. We all learnt how good design could take place with the right conditions and environment.
3. Mentors - having them around provided a real yardstick and that extra polish and validation to our work. I was happy that Leisa Reichelt and Ivanka Majic came along to assist.
4. The space - kudos to City University and the organizers for setting up and providing the space needed to do the work. It was perfect.
5. Equipment, tools, etc. – apart from some minor glitches with the projector, I felt there were enough stickies, post-its, etc. although I did bring along my own design kit (instead of a laptop, like everyone else did).
6. The organizers (@johannakoll, @joelanman, @cyberdees, @bobbywatson, Kate from City Uni) were really helpful, went out of their way to get us coffee, and worked their asses off to make this happen.

I think some improvements can be made in future runs of Design Jam:

1. Incentivize more experienced UX practitioners to participate. I certainly saw many people hungry to learn about UX, and it’s not just about having the ability to create personas, using a UX process or doing user research. An experienced practitioner can make a real difference in how all that gets synthesized.
2. It would’ve been better if we had more time for reflection and learning. I felt there were many people, some of which were new to UX, who could’ve given their thoughts and opinions about their experience. It would’ve been much more valuable to gain those insights during the event.
3. The presentation phase could’ve benefitted from more structure. Having some sort of structure and time limit would encourage teams to focus and deliver a more compelling presentation, rather than a looser format of this-is-is-our-prototype-and-heres-how-we-got-there – keeping in mind that energy levels usually drop fast toward the end of these kinds of events.
4. It became a bit intrusive to edit the wiki while doing groupwork - it meant that occasionally one member of the team had to be disengaged from groupwork to focus on the wiki. While I appreciate the value of real-time conversation and updates, it could’ve been given a bit more thought – maybe allocate time for groups to do that rather than steal away precious group time.
5. For some reason, I feel it’s important to have good wall space do to UX design. There were teams that had to make do without ample space, but I guess no one seemed to complain.
6. It felt a bit harder to work without easy access to coffee (ok this is a bit out of place, but…). Thanks again to the wonderful organizers who went out of their way to get us takeaway coffee from a nearby cafe.

Some interesting highlights:

• Our levels of do – part of our conceptual map of the user’s re-finding activity.
• Our user research, done on twitter – complete with incentive for willing participants.
• Stephen Anderson’s Mental Notes cards came in handy.
• iPads as prototyping tool and makeshift powerpoint slides.
• Family friendly.
• Makeshift wall.
• Location-based piles.
• Design Jam wiki – thanks to @jeffvancampen.
• Our team, SevenHeaven.

I’m looking forward to the next one! Big applause to the organizers and sponsors (Mozilla, City University, Johnny Holland).

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.

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

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.

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.

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?

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.