June 5th, 2008
Agile UX and eyetracking
![]()
Yesterday I attended the half-day WIPA Usability and Eyetracking Seminar, and found it fairly good use of a few hours of my time. Largely because it helped confirm some things in my own mind.
First up was Challenges for Usability in Agile Development presented by John Eklund of UX Research. There has been much talk about agile development methodologies in recent, and probably as much talk about how user experience practitioners can remain valuable in such an environment.
To paraphrase John, my summary of the discussion is as such:
- Agile is about “bringing design forward” (I like this definition)
- It’s about less documentation and specification up-front
- Acknowledge that requirements will not be fully correct, complete or fixed in stone; learn to live with it rather than boxing requirements gathering into one neat discrete step that must be finished before anything else can begin
- Agile is also iterative or incremental development
- Partial prototypes help elicit requirements and specifications from the client
- Clients rarely read spec documentation and often can’t articulate what they want until they see it (you know it’s true!)
- Creativity is less bounded by specification when the specification is yet set (this is not just in terms of visual creativity but also the overall design directions)
- For UX to fit into this methodology it needs to be embedded, flexible, fast and practiced by an experienced practitioner
- For best results in agile environments, UX expertise should be independent of designer (and client)
- Additionally, UX practitioners must play the “expert advocacy” role (providing ad-hoc advice on simple issues without the need for a costly ‘engagement’ or bulky reports)
- Generally faster turn-around is needed for activities like usability testing
I enjoyed John’s perspective on this topic, and a few of his points in particular are closely aligned with my own views on UX practice. I’ve used mentoring in the same way as John’s “expert advocacy” where UX or IA expertise is bought by the hour, allowing for much greater freedom to add value to the design team without having to get approval for a project each time they want to ask a question.
Next up was Eyetracking – Applications in Digital and Media by Peter Brawn of Eyetracker. I was impressed by Peter’s presentation of eyetracking as part of UX practice, as opposed to how I have seen it pitched in the past (that is as the answer to all your problems). This makes sense, since there is a lot that gaze paths and fixation data can not tell you about the usability of a website, and vice versa there are some things you can’t really get out of traditional usability testing and ethnographic research techniques.
For example, a certain section of a website is not receiving much traffic. Usability testing might tell you that users are interested in the content in that section, but perhaps not why they aren’t getting to it. Eyetracking can tell you that users simply don’t look at the obvious, big, fat link that goes to that section, but not why they don’t look at it. Combined you are getting a more complete picture.
That said, I still believe that, dollar for dollar, other methods are better value than eyetracking. For the cost of the hardware and software (or consultants to do it for you) quite a lot of low-tech testing and research could be done. Ideally, you’d do both, but going back to John’s topic, if you want to ensure UX keeps its foot in the door in agile environments—or any other—the approach needs to be lean, mean and cost effective.
I do understand that many clients want the snazzy visualisations you get from eyetracking, not to mention the snob value, but this is only going to be realistic for big corporate clients. Smaller clients should save the cash and use other methods.

