Ask someone to describe their week from memory and you get the highlights, not the texture of it. Diary studies exist to catch what memory conveniently smooths over, and running them well takes more coordination than people expect going in.
Say a team wants to understand why users abandon a budgeting app mid-month. A single interview gets polished, after-the-fact answers. A two-week diary study catches the actual moment someone opens the app, feels a flicker of guilt about a purchase, and closes it instead of logging anything. Designing a study that captures that kind of detail, and then making sense of dozens of participants doing it differently, is the real craft here.
This is a fully remote, full-time role open to candidates anywhere in the world. There is no office involved, and participants for your studies could be based in any time zone, which shapes how a study needs to be designed from the start, down to when reminders go out.
Teams that invest in diary studies specifically, rather than relying only on interviews or surveys, tend to be ones that have already been burned once by a decision made on thin qualitative evidence. That context is worth knowing walking in.
You will plan and conduct diary study research, working with participants over days or weeks rather than a single session, then synthesize what comes back into findings the rest of the team can actually use. Across a typical study, responsibilities include:
Participant drop-off is a constant, quiet problem in this kind of research. Part of the job is designing check-ins gentle enough that people keep logging honestly through week two, instead of backfilling entries the night before a session officially ends.
Synthesis is where a lot of the actual thinking happens, more than people expect from the outside. Dozens of loosely structured entries do not organize themselves, and turning that raw material into two or three recommendations an engineering team can act on is its own distinct skill from running the study itself in the first place.
This is a senior role, so we are looking for someone who has run studies independently before, not someone who needs a research plan handed to them. A bachelor's degree in human-computer interaction, design, business, or a related field is the baseline, along with 42 months of experience in user research or something closely adjacent to it. Strong analytical skills matter, but so does the ability to explain a finding to a product manager who has five minutes and no patience for jargon.
42 months is generally enough time to have run studies across more than one product area, and to have developed a real sense for which findings are worth pushing hard on and which ones are interesting but not worth slowing an entire roadmap down for.
You should be comfortable with all four of these, since they come up regularly:
A plus, particularly for studies that run past a couple of weeks:
Figma comes up less for designing prompts and more for reviewing whatever the team is currently building, so a study can be scoped around the actual product surface rather than an outdated screenshot someone found in an old deck. Data analysis here is less about heavy statistics and more about pattern recognition across qualitative entries, though some comfort with basic statistical reasoning helps when a study includes quantitative logging alongside the written entries.
This role pays 105,000 dollars a year. Remoteroles works with UX and product research teams on senior roles like this one fairly often, and the package here reflects that seniority.
Pay at the senior level generally reflects the ability to run a study end to end without close supervision, not just years of experience listed on a resume. Teams hiring for this role are trusting someone to make real methodology calls entirely on their own, often with limited oversight along the way and a real budget riding on the outcome.
Since your participants could be anywhere, you will need to be flexible about when check-ins happen, sometimes outside a standard workday. Internal collaboration with product, design, and engineering is more predictable, with a handful of scheduled syncs each week and the rest handled asynchronously through shared docs and research repositories. A recorded readout at the end of each study usually replaces a live all-hands presentation, so stakeholders in other time zones can watch on their own schedule.
Expect to hold a small pool of participant relationships at any given time, which means the workload comes in waves tied to active study periods rather than a flat, identical week every week.
A launch week for a study looks very different from a synthesis week that follows it. The first is full of short check-ins and troubleshooting; the second is quieter and more heads-down, spent mostly with a pile of raw entries and a stubbornly blank findings document.
Send your resume along with an example of a diary study or longitudinal research project you have led, including what came out of it. From there, expect a conversation about how you have handled a study that did not go the way you planned. A study with messy or disappointing results is often a better conversation starter than one that went smoothly, since it usually says more about how you actually work through a problem.