User Engagement

Learning Outcomes

By the end of this section, you should be able to:

• Understand the rationale behind user engagement processes
• Describe the process of gathering user requirements
• Contextualise your own project’s user requirements in relation to the processes used by others

---

Why undertake user engagement?

There is a somewhat famous cartoon from the 1970s depicting the results of a series of communication failures in a product development process.

Though the cartoon predates the digital age, it still resonates with many digital research infrastructure project teams.  Budgets, availability of technologies, comfort zones or previous experience of development teams, lack on clarity of project goals, “mission creep,” external pressures to do to much…any number of factors can lead to the development of end products that don’t quite match a user’s initial simple requirements.    While a project or research infrastructure might, from the proposal stage, have a clear idea what it wants to achieve on a broad level, at the more detailed level it’s therefore still important not just to test how well technology works for a user, but to work with your users at every stage to ensure the tools r technologies being developed do indeed meet their needs (which they may or may not have the metacognitive or cross-disciplinary abilities to express to you clearly).

Modes of user engagement

The idea that user needs should be a central part of any design process is not necessarily a new one, but also by no means something that has been a self-evident part of design processes.  Even in the late 1980, Don Norman’s seminal work “The Design of Everyday Things” documented how poorly user needs were often addressed in product development.

Since them the paradigm has shifted perhaps further, with ideas about ‘user-centred design’ now becoming supplemented by concepts of ‘participatory design.’  Regardless of what philosophy you choose, the fact is that good technical design will almost certainly incorporate your users’ perspective, and good project management will seek to create dialogue between developers and users across the project phases and in multiple ways.

Some of the mechanisms you might use for this will include:

Surveys

If the user group is particularly broad, a sense of basic requirements or priorities can often be captured via a survey.

Workshops: In this format, ‘focus group’ like discussions can be combined with presentations of examples of similar work, brainstorming sessions, guided or rapid ‘ideation’ sessions, creation of video prototypes, or other form of exercise to get beyond what the user thinks they need (which may be shaped by either existing technologies or by unrealistic expectations) and what they actually want to achieve.

User Scenarios and Stories

These tools (which form a part of the Cockburn approach to user-centred design) start from textual descriptions of a set of tasks and requirements in the user’s own words.  They can then be broken town into separate tasks, each of which may be paired with a technical description (eg. “I need to look in several bibliographies for references” may be translated as “(federated) search across multiple sources”).

Prototypes

This approach often will pair domain and technical experts of co-develop an element of the proposed environment together, using a single user (or a small group of users’) needs to act as representative of the full user group’s requirements.  This can be a good way to get well-attuned technical development moving forward rapidly, though one must be sure that the requirement chosen to underpin the prototypes is truly representative.

User Testing

A key part of any process will be making sure that beta versions and higher really do meet user expectations and requirements.  User testing is often tiered: a first cycle may involve researchers with domain expertise who know the technologies well; a second tier may be based on regular rapid cycles of input and refinement between a larger group of less technically minded users who would none-the-less have been aware of the development team’s work over time; a third tier could involve recruitment of a ‘Trusted User Group’ from outside of the project, but who were willing to test specific aspects within a semi-controlled environment (ie warned of certain bugs, provided with training and contextual information, etc.); finally, a first release will likely be in an uncontrolled environment, but will allow users to report bugs and feedback on their experience.

The following lecture describes how some of these tools were deployed to assist in the development of a major research infrastructure project, CENDARI.

You can download the slides from this presentation from our SlideShare profile, or from our Training Resources section

 

---