|
experience working with HCI folk
Hi everyone,
I'd be interested to hear if any of you have experience working with usability or 'interaction design' professionals, and whether you felt their input was valuable or not and any difficulties you had working with them. I'm not interested in uninformed opinion or starting a religious war. I'd just like to hear from people who have actually worked with usability folk on significant projects.
At the company where I work programmers are relatively open to usability input, especially as it often reduces the amount of implementation they have to do (especially trivial implementation).
I'm all ears (literally),
Sherlock
sherlock_yoda
Friday, July 26, 2002
I find that usability folks often have excellant insights and critiques BUT they do NOT know the "right thing to do" instead. So listen to their criticism but do not follow their advise. This might be good advise for many situations.
Those wha had the misfortune to try to use Donald Norman's multimedia Voyager CD will understand what I'm getting at here.
X. J. Scott
Friday, July 26, 2002
I agree with the previous poster, X.J. I just finished a product that used an HCI team to do detailed end-to-end engineering of the "user experience." While they did provide lots of good input, I was less than enamored of the design work that they did. The design was very complex, klunky, and difficult to implement. When we finally did get it to work the way they wanted, many test users found the result hard to learn and hard to use. We put this into production, but we're looking at rewriting the GUI to simplify things a lot.
Also, the domain seemed to lend itself naturally to an object-centric decomposition, but the task analysis seemed to break everything down into a function-centric structure. This structure comes through in the GUI and is the main reason for a lot of confusion and frustration, I think.
I think our two big mistakes were to give the HCI team full control over the GUI and to not insist on testing a working model of the GUI in the field frequently through the process. They tested storyboards and mock-ups, but those results do not reflect what we're seeing with the real thing.
HCI victim
Friday, July 26, 2002
Some HCI consulting companies seem to have deliberate techniques to undermine the software development staff and role in organisations they consult to. This is all part of selling their own importance. Programmers can't do design etc.
I think HCI is a great discipline and task, and there are lots of good HCI designers. But there are also some HCI consulting firms that are dangerous.
Hugh Wells
Friday, July 26, 2002
In my experience, the critique and research portion of HCI can be very useful -- telling you what parts of your UI work, and what parts don't.
On the other hand, projects I've worked on/seen worked on where the design was managed by the HCI group rarely went well. Because of the focus on user interface exclusively, design constraints (like the limitations of HTML) are generally ignored, resulting in clunky and complex applications that users hate, or are at least indifferent to.
Matt Christensen
Saturday, July 27, 2002
Designing using HCI can tend to produce an interface that only works for those naive to interfaces and naive to that application. In practice though, few people stay novices for long and need to learn the best way for them to navigate an application.
So, we need to write interfaces that are simple and straightforward and yet allow the user to determine for themselves as much as possible their own way to use it. Whether that's combinations of keystrokes and mouse use, or the setting up of profiles, preferences and so on.
Simon Lucy
Monday, July 29, 2002
Many of the responses to my initial post note that HCI professionals can be good at spotting problems but they do not always provide good fixes or create good initial designs.
There is some recognition of this in the HCI community. In fact, a new label of 'interaction designer' has emerged to differentiate HCI professionals with excellent design skills from usability testers or engineers (Alan Cooper was at the front of this movement). It is becoming apparent that there are many different facets to human-centred design, and these require different training and dispositions:
1) Usability tester, engineer (mainly observation and empirical skills)
2) Interaction engineer (design skills with good technical knowledge and long experience of interface design across many 'genres'
3) Ethnographic researchers (gather initial user data, do contextual analysis, etc)
However, some HCI professionals pretend to have expertise in all these areas, and then go on to make dumb design decisions that make themselves and the community look bad. Cooper says that a HCI professional should be able to give 2 good reasons for each design decisions, otherwise they are no more credible than a lay person. Ideally, they could back up their decisions with either known research or heuristics. I also agree with the earlier comment that a HCI professional must take account of the way the system is being implemented - design is always about trade-offs.
Thanks for your replies.
Sherlock
sherlock_yoda
Monday, July 29, 2002
There is no HCI community nor HCI professionals, at least none in any meaningful way. Yes, there are groups that would like you to believe otherwise, they have no criteria for membership, no common experience, no common education.
So, my experience with "HCI folk"? I have absolutely no idea what to expect, unless they have been hired by the same people, work in the same company, etc.
Ron Zeno
Tuesday, August 6, 2002
I would consider myself an HCI person, and I can't help but reply to some of the comments above.
Many recognised that an 'HCI person' can mean different things, which helps to explain some of these criticisms:
"often have excellent insights and critiques BUT they do NOT know the 'right thing to do' instead."
"I was less than enamored of the design work that they did... we finally did get it to work the way they wanted, many test users found the result hard to learn and hard to use. "
"focus on user interface exclusively, design constraints (like the limitations of HTML) are generally ignored"
It is unusual for someone who has trained and is experienced with usability testing to have significant programming or design experience, and unless they do, they probably shouldn't be defining the design exactly.
In the second reply (by HCI victim), it sounds like the HCI team made a design without testing it before production. That goes against accepted best practice of testing with low-fidelity prototypes, so I would have to question their approach in this case.
To add to Sherlocks second post, I would suggest that people hiring HCI consultants/personnel look for what type of skills the person has. If they don't have design experience in this domain, take their ideas as suggestions, and look for ways to work around the problems found.
If they don't have programming experience, then it is probably necessary for the programmers to work closely with the HCI people/designers to explain the constraints of the technology, and come to the 'best' solution.
I tend to work in-between designers and programmers, effectively translating between the two! In the case of a intranet application we are working on, I did the user-research & requirements analysis, and delivered the requirements and suggested features to the programmers.
We then sat down and hammered out the structure of the application in terms of task flows and functionality.
Then the designers mocked up a quick prototype from our results which we tested. Made a few changes, and tested again.
Then we could solidify the structure and functionality and deliver that to the programmers. They prefer this way because they have a better defined brief, and I am careful not to interfere too much with *how* they do it.
In short, use HCI people for what they are good at, which is often the research and testing (problem finding), but it can vary from person to person.
AlastairC
Tuesday, August 20, 2002
Okay, I'll state up front that I'm a "usability" person -- albeit an ex-developer, ex-business analyst and ex-project manager who came out of the development ranks.
Turn this question around - how would you answer the following?
"I'd be interested to hear if any of you have experience working with developers or 'project management' professionals, and whether you felt their input was valuable or not and any difficulties you had working with them. I'm not interested in uninformed opinion or starting a religious war. I'd just like to hear from people who have actually worked with development folk on significant projects."
Can you imagine the responses you might get? I've seen competence and incompetence in great abounds in just about any role related to design, development and testing on I/T projects. Would I ever dare generalize about the "value" of developers? No. Would I feel comfortable defining what their role should be on a project, how to assess their skills and best ways to manage them? Sure -- if I had time to write a book I could take a pretty good stab at it. :-)
Here's the short version:
1) If you don't know what value an HCI or interaction design role brings to your project, you don't really know what you're buying. And you won't know where they fit into your project. Caveat emptor. Consultants will happily sell you their services, but make sure your expectations are clear and reasonable. Keep in mind you probably have no idea what's reasonable. :)
2) Follow up on references.
3) Know if you're looking for evaluation skills (e.g. usability testing), design skills (e.g. prototyping), requirements gathering (e.g. how are your users unique and what tasks do they need to accomplish?) or all three. Few people are REALLY good at all three.
4) Look for someone with past projects involving challenges similar to what your project will likely involve. Doing a wireless app targeting a cell phone platform -- look for someone with experience designing and/or testing on such a constrained UI platform. Got a political quagmire to deal with in getting the design approved...get someone savvy about dealing with the political animal.
5) Usability is iterative. Greenfield design is much harder than improving an existing application. You can iterate from release to release, but also within a release cycle (e.g. multiple iterations of paper prototypes). Also, give the person and the processes time. You don't hire a new development lead to implement a new methodology and then judge them solely on their first assignment, do you?
6) Think about building HCI/usability and interaction design skills into your internal team -- hired guns bring outside expertise, but have cultural barriers to deal with and take time to get up to speed. See Joel's comments on doing your own usability testing: http://www.joelonsoftware.com/news/fog0000000118.html
Personally, I've heard feedback from customers that my work has provided them value. I've had difficulty with some customers (feeling was probably mutual), and I have customers who think I not only walk on water, but that I do it with style. I've hired usability consultants and heard back from the development team they worked with that the project went far better than the usual project (sans usability expert) -- they indicated that design was better and easier/faster to implement.
Lyle
http://crocolyle.blogspot.com/
Lyle Kantrovich
Wednesday, August 21, 2002
Interesting topic!
I'd like to add that some of the issues raised here regarding pitfalls with 'HCI Professionals' (by the way, that's soo 90s :o) ) could be a result of two things :
- usability charlatans - those people without a strong background or experience in cognitive psychology, HCI or usability whom jump on the usability train and tout skills they don't actually have, quoting freely from Mr Neilsen and laying down usability rules here there and everywhere.
- Poor integration between good usability/interaction designers and designers or programmers - this one is the usual reason for things going wrong in my experience. Once a clear boundary exists between these different roles, things will not gel very well at all. Usability people will recommend changes which will be resented by others and this can lead to all manner of problems.
They way in which it does work in my experience is to put the usability people in the design team working with them on the solution collectively. It may also help to refer to this person as a 'user advocate' rather than a usability engineer, expert or guru - it helps a lot in being accepted by other team members.
And yes, if you haven't guessed already I'm a member of the 'usability folk'
Damian Rees
Wednesday, August 21, 2002
Usability is criticism (not my statement but a very powerful one by Christina Wodtke - http://www.boxesandarrows.com/archives/002669.php ). It there for requires a design to critique. The skills and experience necessary to review and analyze a design are very different than the skills necessary to create the design. By determining your needs or the stage of your project, you can probably better determine if you need a interaction designer (someone that creates) or a usability specialist (someone that observes and comments).
Usability lacks integration into the software design process. Usability professionals are taught how to do usability engineering. They are not taught how to do usability in the software engineering lifecycle. Much of my experience with development team friction has been learning when and where to apply usability techniques in the software engineering lifecycle. Scanlon and Percival have documented different User-Centered Design (UCD) methodologies for different projects - http://www-106.ibm.com/developerworks/usability/library/us-ucd/ . All of these activities need to occur inside the software development lifecycle, it is up to the HCI professionals and Project Managers to integrate user-centered approaches in to the process to improve the final product.
Working with a usability and interaction design professional is very different and causes tension for software developers and project managers. I have found that the friction is often because HCI professionals have a different agenda from software developers and project managers. HCIers want to build the right thing, whereas software developers and PMs want to build the best thing within a given timeframe and budget.
Organizations that focus on gathering customer feedback, involving customers and users in the design process, often have very little need for formal usability, i.e., most gaming companies don't have a usability group but do do extensive usability testing. User-centered design is a philosophy and not necessarily a process or set of deliverables.
David
http://davidcrow.ca/
David Crow
Thursday, August 22, 2002
 Recent Topics
Fog Creek Home
|
