Office of Research Information services user research
PROJECT TYPE: User Experience Research
PROJECT LENGTH: Ongoing over 12 months
COLLABORATORS: Kaitlyn Schirmer, Dustin Hodge
The Office of Research Information Services (ORIS) builds enterprise software for the Research branch of the University of Washington. In an effort to reduce the amount of time that researchers spend on administrative tasks, ORIS set out to create a one stop portal for principal investigators and research staff to manage their projects.
An internal study at the University of Washington revealed that 40% of researcher time is spent on administrative tasks, rather than conducting the research. Administrative tasks include applying for funding, managing personnel trainings, reporting, and much more. In an effort to create a usable portal that reduced this burden rather that increasing it, ORIS conducted a qualitative research study to understand the needs of principle investigators and their administrative staff.
WHAT I DID
As the only User Researcher for ORIS, I was solely responsible for designing, conducting, analyzing and sharing the findings of a 3 qualitative research studies that sought to uncover the the differing user types, roles, and needs of the universities vast and diverse research enterprise.
I started by analyzing data from previous user research studies, as well as data collected by the University's online research tools about research staff, their projects, award amounts, and research fields to have a comprehensive understanding of the research population and landscape. Using this data I drafted a comprehensive research plan, that was submitted and approved by the organizations leadership, and then moved forward with study design.
The data showed that there were several different user groups to investigate (Principal Investigators, their lab staff, and their research administrators), so I designed 3 separate studies, each tailored for a specific group. I recruited and scheduled 8-10 participants for each of the separate studies and then moderated each study with a dedicated note taker. Studies included surveys, contextual inquiries, semi-structured interviews, and lab tours.
After conducting the studies, I then analyzed the data using several methods for analyzing qualitative data, including behavioral variable mapping, and affinity diagraming. I used this data to create in depth personas, each with their own experience map, and a comprehensive set of design principles to guide our development process. At the conclusion of each study, I created a summary of the findings, complete with user sound bites and photos, which I shared with our development and leadership teams. These tools and findings were then used by the leadership team at ORIS to guide our product roadmaps, and by our development team to create user requirements and stories.
WHAT I LEARNED
I learned so much from working on this product, and in this environment. As the sole User Researcher I successfully helped establish best practices around collecting and sharing user feedback and translating data into actionable goals, principles, user stories and designs, which came out of a lot of learnings and failures.
My biggest learning came out of a failure to get my development team to internalize the findings of one of my studies. A few weeks after presenting the findings, the research was quickly forgotten by my team, rendering that work useless. After all, what use is uncovering user needs, if you don't remember to use them in your process. After much trial and error prototyping and experimenting with my presentations, storytelling style, and artifacts, I learned that the best way to share these findings, so that they stuck, was to include my team early on in research and analysis phases, and to design and create compelling artifacts that they could revisit again and again.