7 Essential Roles in Digital Arts and Humanities Projects

Collaborative by default

Since each of us was several, there was already quite a crowd.

Deleuze & Guattari, Anti-Oedipus.

Every effective use of digital technologies involves a set of specialists, each with different concerns, knowledge, and skills. In everyday use, when doing a routine operation using familiar and well functioning tools, we don’t even notice these people. Sometimes, when things don’t go smoothely, we call upon their help (or curse them unfairly). When we are doing something new, as is more often the case in research projects, the roles and the resources through which they are fulfilled become more significant. The extent of our reliance on them depends on the newness of the outcomes we are aiming for. We might not always, for example, require the services of a programmer, although as I will demonstrate, the programmer’s mindset and skills are always helpful, even when using ready-built systems. In Digital Arts and Humanities, every researcher can benefit from being a programmer to some extent, seeing things through the programmer’s perspective. The same is true of the project manager. You’re unlikely to employ a professional project manager, even in a well-funded project (they are expensive), but you can still benefit from the PM perspective, even in your everyday work. You might not need to employ a trainer, or attend formal training courses, but it helps to manage your own skills development and those of your colleagues using the IT Trainer perspective. In fact we are all doing these roles all the time. I have observed that practitioners who are able to flexibly move into a different one of these perspectives as they need to are more successful. This applies in their everyday operations, in their development projects, and when they have to work with specialists (for example, when calling on the support of the IT Helpdesk).

Let’s have a look at each of the seven roles to get an idea of what they care about and how they see the world. In subsequent theory articles we will explore each in more depth. In our workshops we will always reflect of tools and technologies from each of these perspectives.

• The Researcher
  In this article we explore what researchers want, how they work, and how they think, so as to understand how they can work well with the other 6 roles in the Digital Humanities team.
• The Programmer
  In this article we explore the world of the programmer, what they care about, how they think. Whenever we structure data, or create processes to apply to it, we are programming. If we use the programmer perspective we can do this better.
• The UX Designer
  Working in raw code and data is no fun. We need interfaces! Views that help us to access just what we need when we need it, and then do clever stuff with data. The UX Designer’s job is to make these interfaces so that they work well for us.
• The IT Trainer
  Formal IT training seems to have become unfashionable. We either expect software to be so well designed we can just use it, or we learn just-in-time from Youtube. But the IT trainer’s perspective is still valuable, with its focus on knowing how people make sense of and habitiuate often complex and hard to remember systems.
• The IT Manager
  The people in charge of running IT systems in universities combine two hard to reconcile attitudes: on the one hand they are advocates for tech, they want people to be able to do amazing things; but at the same time they are deeply risk averse. They do have ways to come to balanced decisions, and ...
• The Project Manager
  This is the role that coordinates the rest of the team and the tasks they need to complete. But it is often misunderstood, and seen to be more complicated than it is. This article considers a simple and effective PM method.
• The IT Helpdesk
  Digital Humanities tools, techniques and services add to the already complex mass of potential problems that help desks deal with. By understanding this challenge we can make life easier for everyone.