Tips for ethical and effective user-experience research on internal websites and services
Sometimes as a UX researcher you’ll need to do research on an internal-facing service like an intranet, admin tool, or an app that workers use out in the field. One of the good things about working on an internal service is that it can be easy to identify a pool of users to take part as they’ll usually be a team of people working in the same organisation that employed you or brought you in as a consultant.
However, when your users are your colleagues, consent procedures can feel less natural than when you are interviewing members of the public. In my experience, users seem happy to talk about their use of an internal service but get nervous about the formality of a consent form. Also when somebody else like a team manager is the gatekeeper to access to your participants, it can be harder to access a range of users and the quality of your research can suffer.
This article covers a few tips for conducting and sharing research ethically and effectively on internal services.
Get informed consent
Access to users for research on internal services often comes through talking to the team manager because the user will be taking part in the research on work time. I’ve experienced managers lining people up users for testing but when I’ve met with the users they have no idea why they are there, who I am or what the activities will be.
If you’re planning to collect data, like pictures of workspaces, notes about processes and things people said, or observing how they use services, you need to get informed consent. This means asking users to complete a consent form.
Lots of people will be welcoming and glad that you’re taking the time to understand how they do what they do. Others can feel uncomfortable being observed doing their work contextually or taking part in a usability session on a new system and might feel like it’s a ‘test’. To mitigate this, send an information sheet and consent form in advance of the session. You might need to send this to a team manager to share with their team first. The information sheet should make it clear that you are not testing the person, but that you want to understand more about their processes because you are designing a new system, redesigning a service etc and you want to make sure it meets users’ needs. Bare in mind that there’s no guarantee the user will receive the information as your research may be low down on the priority list of the manager. If you do turn up to meet your participant and they haven’t been informed, take the time to explain the nature of the research and get informed consent from your participants. Let them reschedule or drop out if they don’t want to take part without advance notice because you’re not going to get good data from a participant who is taking part begrudgingly.
Users might also reveal sensitive things about themselves, workarounds they use that don’t meet company policy, or things that upset them about their work. Going through consent procedures and assuring users about how you will use their data may also encourage them to give you more truthful feedback which will help you and your team to design a better service.
Depending on your project, you might not be recruiting through the manager of the team: if you’re recruiting in another way like posting on the intranet and putting posters up around the workplace and allowing people to self select, the same process applies for ensuring people are informed about the research before consenting to take part. You might also need to let the manager of the team know you’re inviting people to self select, particularly if your participants are taking part on work time. You might need to make sure research can happen in a lunchbreak or before/after work depending on your project and the politics of the organisation.
Work with the manager to identify a range of users
It’s useful to get the insight of a team manager or expert system user but don’t rely on a managers opinion of how workers use the system to inform your design, you need to conduct research with people who use the system day in day out.
Be aware that the manager might try to pick their most experienced team members for your research, they have the best intentions and want to show their team in the best light but this might not be an accurate representation of all system users. You want to understand how all users interact with the system, so try to recruit users with different levels of seniority with a range of experience in the role. Work with the team manager beforehand to explain what you’re doing and why you want to talk to a varied sample of users.
Don’t use up the goodwill of your participants if you have a small user base
You might be redesigning a system for a small number of users, or there might only be a few people in the team who can test a particular feature of a system that they use as part of their jobs.
Taking part in research can be mentally taxing. Users might feel that they can’t say no to taking part even if they are busy and end up having to catch up on work tasks in their own time. With this in mind, try to vary your user base whenever possible, it’ll give you a broader range of insights and put less strain on your user.
Practical considerations
When you’re doing contextual research, it can be great to take photos of workspaces to communicate context to the rest of your team later. If you want to take photographs of a shared workspace, make sure you don’t get other people in the photograph unless they also give consent.
If you’re observing internal systems, don’t inadvertently take copies of sensitive data for example customer information on a CRM system or stacks of files with patient names on them in a doctors’ office
If you’re doing contextual research it’s good to take another person along with you to research sessions to help with observations and analysis but limit this to one or two people because unlike lab research you might be all cramped into somebodies workspace. If it’s not your usual place of work, try to find out what the site/setup is before you go along and let them know how many people to expect.
If you’re testing a prototype, you might need to arrange to book a quiet place on the site, ideally a private meeting room where you won’t be interrupted.
You might not be allowed to incentivise your participants financially if they are members of staff at an organisation (they’re already being paid to be there) but you might be able to offer a small token of appreciation, chocolate, or a gift voucher to the on-site canteen.
Anonymising and managing data
After you’ve collected your data, use participant ID codes when storing the data like you would if you were doing research on a consumer-facing service.
Remove names from transcripts and set file permissions on digital files so that they are only accessible to the research or delivery team (or whatever you agreed on your consent form).
Set a date for deletion of data, this date should be on your information sheet and communicated to the participant. I just write ‘Delete by <insert date>’ appended to the file name with the data in it. As a freelance consultant, I am probably not going to be with the organisation by the time this date comes up so I ensure this is communicated as part of my handover when I leave an organisation.
Using quotes
You never know what a participant will say or reveal until you’re in the session. Using the consent form at the beginning will set the rules for how data will be used if they inadvertently say something sensitive. I’ve experienced users saying really insightful, but unflattering things about other teams and individuals in their organisation. The teams and people involved may have had access to my research report so I needed to handle that carefully, still using the insight as a statement of fact about dynamics between areas of the organisation but not using inflammatory quotes.
As mentioned above, users might also reveal unorthodox workarounds they use that don’t meet company policy (knowingly or unknowingly) that might get them in trouble if it’s attributed to them in a report.
If you’re using quotes in your write up and you want to attribute them, use the participant code and role of the person e.g. “There’s features in the system that I don’t even know how to use and I have left it too long to learn now. My boss is too unapproachable to ask.” Participant 10, Senior Manager.
If you only have one person in the role of Senior Manager and it would be obvious who said the quote, don’t use roles in the quote attribution.
In summary, planning recruitment and research carefully will ensure that you get the most useful feedback from internal service users. Get consent, communicate with ‘gatekeepers’ to your participants to ensure you get access to a range of participants and follow General Data Protection Regulation when collecting, using and storing participant data.
