Driving research proposal process with great user experience
During last six month I was working on a user research project in relation to Research Management. We started the project with a Design Thinking Workshop to gather the needs of Universities and Research Institutes for a Research Information System. The results of the DT workshop lead us to the decision to take a closer look at the research proposal process. Hence we planned a user research with Research Proposal Advisers.
Why did we focus on research proposal?
Most research institutions have a smaller or larger number of (valid) data sources for storing the research related data which lead to a Research Information System based on not qualified data. Our objective was to look at that point where the research data is initially created.
We put our focus on user experience
During the user research we followed the user experience approach:
We focused on the user research with persona, use cases and interaction designs as the outcome and left architecture and data model discussion behind for a later point of time. Regarding the data model it was a given fact that a solution should support as a minimum requirement the CERIF (Common European Research Information Format) model.
We took interviews with eight persons from three different German Universities, most of them related to research proposal process by supporting researchers until proposal submission. With the interviews we got a deep insight in the daily tasks, the way of working and especially the needs and pain points of the interviewees.
Based on the interviews we created a persona for the Research Proposal Advisor, put together an activity flow and identified three use cases.
- Review Information for Research Proposal
- Request Signatures for Research Proposal
- Collect Signatures for Research Proposal
It is an absolute necessary exercise to first putting together the persona including all needs and pain points as well as the job responsibilities and goals. The needs and pain points can be found again in the activity flow as we asked for each activity the question what does our persona need to fulfill this task and what is preventing him/her to do so.
Next step was to set up the three use cases to see how the persona does interact with the system, what data does the users retrieves and what does the user do with the data. The use case also explains in detail how the persona needs to iterate in case of different circumstances.
Before our interaction designer started with her work designing mock-ups for managing research proposals we wanted to validate persona and use cases with our interviewed research proposal advisers.
They were quite satisfied with our user research results and found themselves reflected in the persona and in the use cases. They said such a solution would be really helpful and they are very keen to see the results of the interaction design.
Now it was time for our interaction designer. She created mock-up screens for the first use case based on SAP Fiori Principles. The user starts the Research Management Application and is guided to a SAP Fiori Overview Page, where the user gets an overview about all research proposals she/he is responsible for and about statistics such as number of submitted proposals, number of accepted/ declined submissions. The overview page is the starting point for the daily tasks related to research proposals.
User research helped us to understand user’s needs but also uncovered new challenges.
After finalizing user research and interaction design we are at a point
- that we understand research proposal adviser’s needs and pain points.
- that we understand requirements and challenges for a Research Management System
- that we have documents and designs which will help us to convince customers and internal teams in negotiations and in continuing our UX based work
However we also faced the issue that researchers drive their individual, autarkic research proposal without sharing the data with internals. Research project data is often initially recorded in an internal system after the proposal has been submitted and accepted by the funding organization. This means for the institution that they have no statistics about number, type, topic of past research proposals. There is no option to check if this topic is recurring or if a researcher is already applying for a specific call.
Hence the biggest challenge is to convince researchers to enter data for research proposals not only on funding organization platforms and for their own storage but as well on an internal administrative platform. Researcher would need a form/ questionnaire where they enter data once and data is automatically distributed to funding organization platforms and internal administrative platforms. Only then our proposed solution will effectively support research institutes.
Well, this requires a closer look in another user research.
Hi Silke, thanks a lot for sharing these experiences and results. Sounds very interesting. Hope to hear more in the near future...:)