Contents
# Community
Every two weeks we hold a user research community meeting. This is open to all URs within digital, including contractors. During these sessions we usually follow an agenda, whereby one or more URs present something back to the rest of the community – for example, something they’ve been working on, or have worked on in the past. Because we all work on different teams, communities are really valuable opportunities to get to know one another and find out what we’re all working on. They aren’t compulsory, so if you have a particularly heavy workload one week then it’s ok not to attend.
If you don’t have the meeting invite, reach out to one of the URs and someone can forward it on.
Sarah Stokes: “The NHSBSA user research community is for anyone involved in user research in the NHSBSA, in any role. The ‘UR community’ is here because we want there to be an open and safe environment for everyone to develop their knowledge and skills. We also want this community to be a support system for the people in it. We have a variety of experience and knowledge and skills in the team, which is great, but everyone is very helpful and non-judgmental with their time.
We also have a Slack channel, where people can share a quick message or question if they need to.”
# UR drop-in surgery
The UR drop-in surgery takes place every week – either Wednesday at 10.30am, then the next week Thursday at 3pm. This is a more informal get together of URs than the community, as we don’t follow a set agenda. The purpose of this meeting is to socialise with other URs, and to get help with any research specific issues you may be having – basically to replace the ‘can I just grab you for a minute?’ chats from the office. If there’s something you’re really keen to talk about you can always mention it in the Slack channel prior to the call, but other than that there’s no set plan.
Even if you don’t have a specific problem or thing you want to talk about, if you’re free please do feel free to come along and just listen. You’re also under no obligation to stay for the full 5 minutes – come and go as you please.
What ‘should’ I be using?
Ultimately, there are no set rules regarding what software or tools we should be using (with the exception of data storage). That said, there tends to be a steady rotation of software, websites and tools that URs use.
Debs Robinson talks through some of the tools she uses as a UR on the Medical Examiners project below:
• “Trello – really useful to use as a way to organise your tasks. I use it as a ‘to do list’ and it works great if multiple URs are on a project as you can both see what tasks need to be done. I have it set up with different columns that I can move tasks between e.g. to do, in process, completed, queries, back burner
• Jira – as UR we never used to use this but were asked to join the board to ensure the whole team were represented. We have our own research and design board (R&D) that UR, UX and CD use and its broken down into: to do, in progress, BA review and each of the disciplines has their own swim lane so it’s clear whose task is who’s. We keep tickets simple and just include a small description about what we are wanting to do along with the aim, assumptions and any hypotheses. We link each ticket to an epic and assign it to ourselves and the R&D board so it appears in our board (also shown in the overall team board). We add tickets for research we are doing e.g. recruit funeral directors, Prototype test X feature (these types of tickets might get added repeatedly as it’s always going to be something as UR that we need to be doing)
• Confluence – we have created a R&D section where we add information about key features that have required lots of design iterations/conversations. This was done to ensure the whole team could see evidence as to why something was being done. UR and UX update these pages. We also have pages where we provide an update about findings from each sprint. We can copy the aim etc from the Jira ticket and then we list the key findings and any recommendations. We tag team members to these recommendations and ask them to update. We also add a link to this page in the Jira tickets at the end of each sprint so the team can see full details
• Miro – we record most things in Miro as its really visual. We create frames for everything we do so its easier to navigate. We put the key findings from each UR session onto a board and theme them on the board. We then hold team meetings where we take people through these findings and come up with recommendations and again record these on the board. We conduct team workshops on Miro, create service blue prints etc. Basically it’s a really useful tool if you like to see things visually and people are able to make comments so it’s a good way to keep a track on things
• Excel – We use an excel spreadsheets for our scripts and to record notes from UR sessions. During prototype testing we used screen shots of the pages being tested and added the questions we would be asking in the cell next to the image and then we recorded feedback in the received in the cell next to this. We asked any observers to record their own notes in the spreadsheet and the we use all this data and upload the key findings into the miro. Having the screenshot and questions all together we found useful for observers and made script writing much quicker. Our aim is to record any action/thought/observation the user does. We also use excel for our UR calendar. We add details of all UR sessions the dates, their participant number, what we are testing, testing method, how many observers are allowed, a space for people to add their name to this to attend and we then add the recording link afterwards so its easily accessible for the whole team
• Google Drive – this is no longer used as it is not seen as a secure place to store information (although I love it and prefer to use it as its great for collaborative working)
• Sharepoint – this is the place where you store all your information e.g. notes, scripts, personas, recordings, consent forms etc. Literally everything you have you store here.
• Teams – we use Teams to conduct most UR sessions. If participants don’t have access to Teams or would rather not use it they usually opt for a phone call but Teams seems to be the preference especially amongst professionals. We use the recording facility within Teams which means your recording is automatically uploaded to Microsoft Teams. You just need to go into this afterwards and update the name of the recording and amend who can access the recording e.g. allow everyone to view and add to UR interview group. You can then download this file and upload into the relevant sharepoint folder”
You should have access to Jira and Confluence through using your @nhs.net accounts. For Teams and SharePoint, you should have access through your Cipher account. For Miro you should use your @nhs.net account, but you will only be on the free version and may want to ask to get a license (see who should I go to for X).
The list above is not exhaustive – there may be other things that you much prefer using. For example, you may ask your notetakers to take notes directly into Miro, or on a Word document. You may also like to print things out and highlight when doing analysis. It’s your call to use whatever you think will help you within your research, though of course there are tools that your team may prefer you use (e.g. in terms of visibility).
Who should I go to for X?
It depends! If you’ve been assigned a buddy, asking them any sort of question you have would be a good first step – if they’re not the right person to answer, they’ll know who to signpost you too. You could also ask your question to a bigger audience, either in the UR slack channel or wait til one of the drop-ins if it’s not urgent.
Training questions should be aimed at your line manager, professional leads or the senior URs. For example, if there’s a bit of training you’re keen to do but it costs, talk to your line manager about the possibility of doing this.
License questions should probably be aimed at your line manager (Jamie Thompson). While BSA staff should have access to licenses for a number of things (e.g. Miro, Confluence, Camtasia), sometimes these things can be missed or just take a little while.
IT questions are best directed at the helpdesk:
Telephone: 0300 330 3330
Email: nhsbsa.ITServiceDesk1@nhs.net
# Working in an Agile team – where do URs fit in? Who should you be working with?
At the BSA, our digital teams follow an Agile methodology in their work. There are tons of resources available online about Agile, and you’ve probably had or will have some training with Jon McNestrie as part of starting at the BSA about Agile. To break it down, working in an Agile way means working in short bursts, or two week sprints. The idea is to do little and often, working collaboratively with others, not planning too far ahead and being adaptable to change.
For a UR, you’ll never really be only be working in a 2-week sprint – for example, you’ll always have to keep a focus on the next sprint, or the one after, in order to save enough time to recruit effectively. You’ll also likely have a loose research plan that will span over a few sprints, though it’s important not to have this set in stone in case there is something that means you need to deviate from this.
That said, there are times when you will be working to this 2-week sprint. For example, within your delivery teams, you’ll be asked to attend a number of ceremonies at the beginning and end of each sprint. These include, but may not be limited to: sprint review, UR review, sprint planning, backlog refinement, sprint retro. You will also have a daily stand up, and may be asked to use a Jira board to track your progress throughout the sprints.
As a UR, you will be asked to present your research back to the team within a UR review (sometimes called a show and tell, or a playback). This may be in a standalone session, or part of the bigger sprint review. You should run through the research you’ve done throughout the last sprint (see here for more information https://bsa2468.atlassian.net/wiki/spaces/UR/pages/483852527/Tip+8+create+end-of-sprint+reports).
# A sprint in the life of a UR
Lauren Milor: “A typical Agile sprint for a UR: On the Pensions Digitisation project, our sprints run Wednesday to Wednesday. On the first Wednesday, we have the bulk of our sprint ceremonies – UR review, sprint review and sprint planning.
On the Thursday, we have a meeting called ‘UR Prioritisation’ between myself, the content desginer, the UXer, the delivery manager and the business analyst. This takes place a day after the UR review, giving us time to think about where we want to focus UR on next – both in the next sprint and in the future.
Shortly after the prioritisation (probably on the Thursday too, but the Friday if people are busy), I hold a script planning session with the CD, BA and UXer. I come to the session with a list of assumptions and research questions to test and explore, and walk through the prototype with them to discuss what we want to ask. It’s really valuable to have others help with script planning – they often want to ask things that may fall outside of your focus due to their specialist knowledges, and it helps others feel more involved in the research. On the Friday, I’ll finish off any bits of the script that need doing, and prepare for research the following week – it’s also a good time to get any research admin-y bits done that have been missed (sending consent forms to the Research Ops team from the previous sprint, recruitment for the sprint after this, and so on. If I get everything done ahead of time, this will also be the day I usually do any personal development I’ve been wanting to do).
I like to hold all the research sessions across Monday-Wednesday. I try to aim for 2 a day, but sometimes there’s a little more or little less. Having anymore than 3 in one day can be exhausting, so I would advise against it. I always invite my team members to come along to the sessions, either as notetakers or observers (User research is a team sport). At the end of the research session, I ask my teammates to stay on the call so we can have a 5 minute debrief chat – what did we find interesting, what surprised us, what do we think and so on. After that, I try and get all the notes onto a Miro board which has screenshots of what we tested (drop me a Slack message if you want to see what that looks like).
On Thursday, I get together with the CD and UX to discuss some of the initial key insights raised from UR. This helps them prepare for the design work they need to do over the next week – effectively a ‘handover’ meeting. Because I haven’t spent loads of time analysing at this point, these are rough and ready bits of insight - I then spend the next couple of days doing more thorough and focused analysis, so I can begin to write my report. For the rest of the sprint (Friday, Monday and Tuesday), I do analysis, write the report up, and find clips of audio or video to evidence my points for the UR review”.