Practice Seminars at UCLIC

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.

The value of practice in design methodology

I’ve been exposing myself to more literature surrounding the way design works. In some ways I could call them design literature, but that’s much too broad. Or, I could say it’s about how designers work, but again – not all designers work the same way.

In a way, I’m searching for something about the way design works that’s more tacit – implicit, yet indispensable.

The reason is because working from a methodology or a process vs. coming up with a really good idea isn’t quite the same thing. Speaking to a classmate recently about the way design works, he found it hard to articulate why he designs the way he does. But we both agreed that there are bad designs, and bad designers, and things designers shouldn’t do. And it seems you could put that into a list of things to tick off, but it’s not quite like that.

I stumbled across an article by Michael Beirut on the Design Observer site about his design experience. The honesty in which he admits that design is not too far from a ‘magic spark’ is indeed revealing about the sort of work that goes behind the scenes.

He borrowed the analogy presented by Rob Austin and Lee Devin regarding theatre innovations – how the collaboration of stage crew and artists both handle minute by minute executions within a tightly controlled environment and time span in order to deliver an impact to the audience. The synergy, well-executed, is hardly a random exercise, but isn’t easy to put down in books or spreadsheets.

It’s easy for me to say a piece of software has to be built this way because it requires so-and-so features, but it’s another thing to create something from scratch, and say ‘this is going to work best for the user experience’.

This analogy is clearly based on my own background as a software engineer, and it’s causing me to be more sensitive to how designers learn and apply their “tricks of the trade”. In this sense, Buxton’s Sketching User Experiences book has been extremely insightful – but only if you truly appreciate that what the book is really offering is a peek into the mind of a designer, and not just another tool to whack together a pretty interface.

I’m not discounting the fact that building software relies on tacit and practical knowledge as well, but in the realm of design – this seems more magic than method – hence the question put forth in the ixda discussion board. While good software can most certainly be replicable, can good design be replicable too?

The more I read into it, the more I’m realizing that the answer lies in practice, and the understanding of it.