Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Research Synthesis Step 1: Sorting through data #13213
Note: this is to discuss and reference methodology for extracting data from the results of our sitebuilding study. This isn't 100% set in stone just yet and will be tweaked as we finalise details.
Want to get involved? No prior research experience is necessary, and we'd
We have 17 total sessions to parse, 16 of which have notes. All notes and recordings of the sessions will be provided. The 17 sessions will be split across researchers, but you can also share a session if you'd like to halve the work, or discuss with a partner.
It should take approximately 1-2 hours to skim the results and enter data into the table. Examples of parsed sessions will be available to reference and I'm always available in Slack to answer questions as they come up.
Familiarise yourself with the data
This means reading over the notes for the session, and maybe looking through the video recording yourself and taking additional notes. You'll start seeing some patterns emerging.
If you watch the video, I'd highly recommend looking through at least the screen-sharing portion—this was generally where we got lots of helpful data, much of which was visual. This can be hard to fully capture for a note-taker. Take screenshots if you see something interesting!
Every piece of data is an observation—this could be an insight, a task, a quote, or something else. If you're looking through notes, generally each individual note or bullet point could be an individual observation. Keep these as short as possible, and if multiple concepts are being addressed in a single note, consider splitting that note into two observations.
Whenever possible and sensible, write in the voice of the user. So rather than writing as "the user installs plugins", write as "I install plugins". This increases empathy and helps us establish the voice of our users.
Observations should be classed in one of the following categories:
Tasks, philosophies, emotions (doing, thinking, feeling)
We'll be using this to build our mental models and customer journeys, so these are really helpful for us to understand the context of the user's whole experience of sitebuilding. Basically, any time the user talks about doing, thinking, or feeling something, we want to capture that.
Task: Doing. An action or step taken to accomplish something. Either completed on one's own or a task that someone else completes. This can be directly stated (I walk the dogs every afternoon) or implied (the dogs need to go for a walk every afternoon).
Philosophy: Thinking. A belief or reason for doing something in a particular way.
Emotion: Feeling. An emotional state that is derived from the experience. "I feel frustrated when the theme doesn't look right on mobile." (Feeling, emotion)
A higher-level motivator or drive. What is the user aiming to accomplish? What is the end goal? If they're building an e-commerce shop, for instance, their goal isn't to build a website; it's to make money to support their children.
Generalised insights. If you're reading some notes, and you think to yourself "hey, that interesting", it's probably an insight. Write it down!
Pain points are any part of a users' journey that cause friction. This can be something that causes frustration directly, or they can be something a user has devised a non-optimal solution to, or they could be a flow you observed that isn't as smooth as it could be.
These are opportunities for us to solve.
Did you hear a user refer to a theme as a "template"? Make a note of the terminology they use to refer to different parts of a site and of WordPress, whether it's "right" or not.
Quotes are a good way to increase empathy with users, and a great way to illustrate points. Pull any quotes from the notes and the chat transcript, as well as anything you may come across yourself that you find particularly interesting/illuminating.
Pull a story out of (at least some of) the sessions—this can be a great way to humanise the results and encourage us to think more about end-users as individuals. Obviously we’d need to anonymise these stories for privacy concerns.
We won't pull stories from every session, but if you see a good story, go ahead and make a note of it.
Once you've extracted all the observations from a session, you'll want to code the data. Coding data is a way of navigating large datasets and identifying patterns. Consider codes to be tags, but for data.
Each individual insight, task, motivation, quote, or vocabulary term should be assigned a code.
So for instance, for this quote:
I'd code it as technology, art, communication.
To make this easier, I've pre-seeded the database with codes I think may be relevant, but please add anything you may come across that you think is important!
You can code observations as you enter them, or after you've entered them all—whatever works best for you.
Where’s the data?
I’ve started on an Airtable base to collect all this data and tie it back to individual sessions, so we can see it all in one place and swap the views around. This does contain some user-identifiable information, so the data will only be made available to members of the research team working on data synthesis.
I'll be recording a video walkthrough of myself entering data in Airtable for reference, as well as providing written instructions.