Kevin Cheng  

A Day in the Life of HCI

July 23rd, 2004 by Kevin Cheng :: see related comic

When I speak to some smaller firms about HCI, I often get a response on the lines of, “that sounds great, but we only have one or two projects so there isn’t really enough work for a full-time HCI.” On some days, I have a lapse and actually nod in agreement. On other days, I think back to some projects I’ve worked on and recall how I spent all of my time on a single project from requirements to release and not only had enough work - I had too much work. Certainly, underestimating the amount of work a job takes is nothing new. Programmers have had to live with managers under allocating time for development and testing for years. In HCI, however, the difference isn’t by days, it’s by months. How is such a massive disconnect possible? To answer this question, I decided to look at what a typical project cycle was like for me, and what tasks I did.Let’s assume the project is one for a product rather than consulting and further, since we’re talking HCI, we can safely assume we’re talking about software. What I’m about to describe is a scenario loosely based on my experiences and your mileage may (and most likely will) vary but it’s an indication towards how integral HCI is to the entire process.

It’s not really a day in the life but more like a project in the life of an HCI but that just doesn’t sound right, does it?

1. Definition

In the early stages of the project, I would look at what already exists. What is the objective of the project? What, if any, collateral (logos, branding, guidelines, etc) do I need to be aware of? With a high level understanding, I would begin to formulate an HCI plan that fits in with the development process. This plan is created in conjunction with development and project management and covers the tasks I will be doing in the next few months, as well as relevant milestones. Similar to development, HCI might also define some benchmarks or goals to target towards.

2. Discovery

HCIers old and new learn almost immediately that we need to be introduced as early as possible in the process to maximize our impact. Those unfamiliar with HCI will often miss this critical stage. Here, I am contributing or verifying requirements and getting an understanding of the target users. Marketing can tell me that there’s a business opportunity here and a certain profile of people are expected to buy the product. I try and understand that user base so that our design matches both the user mental models and the company’s business model. Depending on budget and time, this ranges from watching users to phone interviews or simply e-mail questionnaires. A great deal is put into understanding the relevant tasks, context and profiles. What I’ve often found useful is to create a document, preferably a single page, that summarizes the users, their core use case and demographic information. Of course, additional documents like personas are helpful but the more concise the document, the more likely others actually refer to them.

Quite often, I’m also attending requirements meetings and partially responsible for reviewing, if not creating, use cases. Requirements are cycled through and I spend as much time verifying them with the business stakeholders as I do with the users to ensure balance.

3. Design

Taking the requirements and turning them into something more concrete. Wireframes and storyboards are my friends. All the buzzwords start to come out: brainstorming, wireframes, prototypes, hi-fi, low-fi, etc. In many ways, wireframes become an essential companion to the requirements. So much so that they, too, should be validated with business and users because ultimately, we’re hoping the developers build something that looks Just Like That.

Working with the developers is an essential step here in order to ensure these wireframes are actually feasible. If done right, they’ll have no qualms telling you because they’re basing their own project estimates on the same wireframes. With a visual tool, the team can reach a compromise between the ideal interface and the ideal timeline.

4. Development

During development, many believe the HCI’s job done and since some projects take a few months, it’s easy to see why they don’t feel they need a full-time HCI person. However, anyone who has worked on an end-to-end project will know that things Change. Requirements, in particular, can change quite radically and in usual practices, the general process is forgotten and the developers simply apply the changes as they see fit. Technical concerns also change as programmers realise certain features may be more difficult, or even impossible, to implement. Adding to this mix is the barrier of communication. A picture (or wireframe) may say a thousand words but which thousand words are YOU getting out of it? They may or may not be the same thousand words I intended to convey.

Thus, I typically do several things during this phase. First, I begin the discovery or design phase for the next development cycle if appropriate. Second, I handle any requirements changes that relate to the interface and evaluate how they should affect the design. Finally, I do what I call a “UI Code Read”. A standard practice for programmers is to have their code evaluated by a peer. I perform the same function for their interface to ensure they are in line with the wireframes.

5. Delivery

The end game where everyone’s view of usability lies. After releasing a product to the masses, I run usability tests as the “true test” of whether we did the right thing. These tests might be in conjunction with some benchmarking to ensure that we actually met our goals. Did the product improve over its last incarnation? If it’s a new product, did it get accepted in the manner we’d hoped? Finally, are the users using the software in the way we designed? Fancy usability reports optional.

As with most processes, the above is more iterative than it implies. Sometimes, Design reflects back to Discovery and follow-up tests yield results which feed the next cycle. I’ve worked on projects that have release schedules ranging from one month to half a year and the high level tasks don’t really change. I may perform early research less frequently to save on doing it every month. Activities may be staggered to accommodate development time (just as development doesn’t stop when the QA cycle begins). In the end, all the bases from 1-5 are covered.

Many of the tasks described above are distributed differently in other organizations. Some of what I’m used to doing may fall under a business analyst, or a graphic designer, or interaction designer, or usability specialist. However, my intent is not to debate over role titles and who should do what. If a company is large enough to have specialists, it’s probably large enough to have multiple projects to keep each role busy as well.

The next time somebody tells me their project doesn’t have enough work for a full time HCI person, I’ll have an answer that’s hopefully more satisfying - and more thought out - than a nod of agreement.

[Edited: 23 Jul 04 18:46GMT Added missing sentences in Discovery. Thanks to the reader who pointed out the error.]

7 Responses to “A Day in the Life of HCI”
Jon Loyens wrote:

I’m very glad you included Development as part of the activities an HCIer must partake in. I’ve seen time and time again that it’s very important that the designer remain engaged with the developers during the actual coding phase of the development cycle. Requirements shift and technical feasibility is often overestimated. A throw it over the fence mentality doesn’t work here and HCIers are as likely to commit this sin as developers are likely to say “get out of my way”. Staying engaged also helps to educate developers on what makes a good UI.

Craig wrote:

From a person who had no concept of HCI from the outset, I feel better-informed, except for one thing…

What does ‘HCI’ actually stand for? If you want to educate the ignorant, then you need to supply them with all of the details. :)

Bruno wrote:

Human-Computer Interaction. I first searched in About, but finally found it in the ressource section.

Josh Johnson wrote:

Acronyms are huge pain in the rear, especially if you work for large corporations or the government who LOVE to use them. One thing that helps a lot though is when publishing things to the web, use the <Acronym> tag, and attach a title to it. Yeah, it takes a little extra effort on the author’s part, but makes life easier for everyone else.

Jesse wrote:

It is often difficult to justify allocating money for HCI development on a project with a 6 month event horizon. Even at larger companies I have seen a design team push all but the bare bones to the side to meet its schedule and budget. Is HCI design included in the absolute minimum requirements your product can have that a customer would accept? I argue that it all depends upon one’s event horizon. A longer horizon would justify more money up-front for HCI and other design enhancements that eventually pay for themselves, but a shorter horizon would see many design steps thrown overboard.

It’s a daunting assignment to educate and convince a project manager of the value of usability and HCI. Products have shipped without decent HCI design in the past and have made money. The trick is to convince someone that good HCI design makes more money and pays for the added development costs of the added headcount. But often justifying headcount is more complicated than just the ROI (Return on Investment).

Bob Salmon wrote:

Sorry if you read this twice - I posted it before but it’s disappeared!

What do OK/Cancel readers do to estimate how much time HCI work will take? If a PHB (Pointy-Haired Boss) comes up with a plan that is HCI-free, you might say “But what about the HCI tasks?” The PHB may reply “How much time will they take?” When you add in things, the PHB may say “How much?!” What’s your response? Is it to show some scribblings on the back of an envelope? Say that’s what my favourite guru says?

What criteria do you use to indicate how large the work is?

(I know that HCI work should be integral rather than a veneer tacked on at the end, but PHBs need rules of thumb when planning projects - X weeks for coding, Y weeks for testing etc. To fight our corner, we need to include HCI in this stage too.)

Tom / KC: could you change the site to allow acronym tags in posts?

KC wrote:

Due to a spammer using a url that wasn’t a url, i accidentally nuked a lot of commetns whilst despamming. As a result, some of the comments in this and the Search Engine thread have been deleted by accident. I recovered most of them and manually reposted them but I apologize for the ones that didn’t make it (e.g., Bob and my comments on this thread).

To repeat: Thanks to the reader’s comments, I will be adding support for the acronym tag and I’ve updated the About page.

For those new to the field or interested in learning more, I encourage you to go to our resources page or to the HCI Bibliography. The ACM SIGCHI definition of HCI they link to is also very good:

Human-computer interaction is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them.


Leave a Reply


OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?