Jakob Nielsen defined guerrilla HCI as a collection of usability techniques that may be performed along development projects in an informal and fast way, requiring few resources, getting acceptable results and avoiding the intimidation barrier of using that kind of techniques.
One advantage of guerrilla HCI is that it can be performed without great involvement of the development team, and consequently, it is useful in traditional website development.
According to their own nature, websites must be self-explanatory and their interface must follow existing standards in order to make possible that anyone can use it without advanced skills neither previous training.
For example, guerrilla HCI could be perfectly applied in the evaluation of an e-commerce website or one belonging to a university since, in principle, they don’t require special knowledge.
Nevertheless, there are cases where it’s not that simple…
Board the ship
Sometimes, usability experts have to deal with development projects where they know little or nothing about the system being developed; it may be a desktop application, an intranet or a specialized web application. In those cases, it’s difficult to apply straight guerrilla HCI since the expert doesn’t know basic characteristics of the system, like user roles, which are the most important tasks, or the use context.
In those situations, it’s necessary to apply something we can call “ship-boarding usability“: the expert has to “reach” the development team and “board the ship” to get to know the objectives and the project status so to improve the system’s usability, “changing the course” when necessary.
To that end, I suggest selecting a collection of basic and simple techniques between those usually included in User Centered Design methodologies:
- User roles (and personas).
- (Essential) use cases.
- User interface prototyping.
1. User roles (and personas):
who will use the application?
In many development processes, user profiles or roles are implicit in developers’ knowledge, but there isn’t any explicit documentation about them. In such situations, I suggest first to develop documents describing basic characteristics of users who will use the system; in this phase, they will usually uncover that user roles are not as clear as it seemed, or even new roles are discovered.
One of the templates that may be used for that purpose is this one developed by Constantine & Lockwood:
It’s not indispensable to follow strictly that structure; the important point is to identify, at least, user roles and their main characteristics.
Ideally, that documentation (and any other described in this article) should be based on a platform allowing the developers to read and update it quickly and easily.
Once those roles are identified, it’s possible to use “personas” technique to have a more realistic reference of the users; however, I think it’s a technique that requires the developers/designers to have a good attitude to be effective.
2. (Essential) use cases:
how will be the interaction with the system?
System requirements, when defined, are many times written as a list of functionalities (“the application should …”) , but without any instruction of how the interaction between the system and the user should be. That forces designers (who sometimes are also the programmers) to make assumptions when implementing the interface; that leads frequently to usability problems.
Through use cases, it’s possible to describe system functionalities in a more structured way. There are many descriptions of how use cases should be structured; I specifically suggest using what they call “essential use cases“, also defined by Constantine & Lockwood. They propose a high-level semi-structured description (as a dialog) of the user-system interaction. This is the template:
Essential Use Case (PDF, 146 KB)
Identifying and defining the most important and/or problematic use cases first help to get an idea of the purpose of the system and allows to concentrate the efforts where the results will be more effective.
Moreover, this kind of use cases has the following advantages:
- They allow to refine the requirements specification, detecting problems, inconsistencies and lack of definitions in an early stage of development.
- They are a reference for the interface designer; the high-level specifications give freedom to the designer when choosing technologies and concrete solutions.
- They will be the starting point for later usability techniques.
3. User interfaces prototyping:
what will the screens be like?
User interface prototyping is a well-known and very used technique. However, launching into prototyping without a clear definition of the users and the details of the interaction may be really difficult. Using the previously mentioned techniques, prototype creation (of new interfaces or redesigns of existing ones) would be much more effective.
In the ship-boarding usability case, prototypes would be useful to design the most critic interfaces (from the most important use cases), or the modification of existing interfaces (to fix usability problems).
From there…
With the help of the previous techniques, the approach to the application will be less traumatic and the specific usability methods will become more productive and easier to apply: for example, heuristic evaluations will be centered on the most important aspects of the application, taking into account the characteristics of its users; and user testing will have a starting point for user recruitment in user roles, and for scenarios and tasks in use cases.
Anyway, the documents and knowledge generated by those techniques will work out useful through the entire development process, and not just for interface design or usability methods. In general, one of the benefits of applying usability techniques during a development process is that they help to increase the quality of the processes themselves and of their documentation.