Helping define those problems that exist for your business by exploring the problem space using hypotheses-driven approaches, learning through causal experimentation and asking those ever necessary questions.
I was approached by Haver with the offer of working with this startup conducting a range of ux and development activities. I have had the opportunity to work alongside some of Scotland's best talent in the UX sector, learning and developing my research and ux design skills.
I like to learn as much as I can, but i am often aware that if discipline is missing, analysis paralysis can reduce efficiency. as a team we decided to research as much as possible and I offered to store learnings for the team on miro and g-drive.
We faced many challenges, however the main obstacle was a skills/knowledge gap that existed for all the team members embarking on the ML project. We started to learn together.
I always look for ways to equally reduce the time it takes for analysis to be conducted and reduce researcher bias. I suggested using loop panel to meet both these needs by conducting coding, transcription analysis, recursive abstraction and text interpretation.
As a group we decided to run an experiement as follows to benchmark and test tools. Miro v loop panel
A team of behavioural scientists had a shared vision to build a pro-bono platform for a global audience.
I like to quickly establish an environment where many cogs can work effectively. I set up multiple platforms to meet 3 goals: promote feedback, iterate with transparency and measure success.
It all began back in March 2021 when Haver were looking to take on a project to help refine their internal processes, store learnings and bring in revenue. As the User Researcher I had made contact with an interesting start-up business in the behavioural science sector, who were looking to create a product that was user-centred and allowed them to visualise their dream - to increase a shared community knowledge around their science within India. The problem team BSD (behavioural science dialogue) faced was they had no knowledge of how to build a product or what to do once they had one.
Team BSD wanted to learn more about how their users worked and what tasks they wanted to complete. Alongside this, they wanted Haver to test some assumptions made about their users.
Haver offered to help and myself as Project Manager, and design lead, we scoped the project and started planning out how we could build a suitable product for team BSD. The research conducted throughout the project was entirely qualitative as this was a proof of concept with limited data to measure user behaviours.
The whole process was iterative and I wanted to create a safe space for everyone to learn fast and fail quickly. The Haver heroes had 4 weeks to deliver several prototypes, conduct appropriate research activities and make sure users were at the centre of the story throughout.
Our timeline consisted of the following:
The challenge here for the team was to create a data-driven responsive website within 30 days whilst arranging meetings across 2 different time zones for a client with a low budget. *Challenge accepted!
In order of severity (most challenging to not that challenging) here are a list of hurdles we faced together as a team:
I like to set out expectations early, build rapport and make sure everyone is very clear on what their role is and what success looks like at the end.
I arranged with the BSD team and all Haver team members to meet and greet each other, but not before sending out an agenda 2 days before. The plan was to do a problem framing workshop, however due to technical issues, I had to be creative and it turned into a 5 Why's collaboration exercise. We had to know if we were solving the right problem (to be tested down the line).
we started off with listing sections of the homepage to build a style guide and get early feedback. at this point, it was a blank canvas.
At this point we needed a visual that could keep the team focused on the users and through several discussions with stakeholders, we started to create 2 personas: Behavioural Science practitioner & Behavioural science student/graduate. The issue at hand was the lack of access to users at this point with a tight deadline, which meant these proto-personas were risky and based on assumptions. To mitigate the risk, we gathered secondary information on these 2 user types and interviewed the stakeholders to get their take.
Discussions at this point were feature-focused and I recognised we had to shift this to a user-outcome one. One way of doing this quickly was conducting a jobs-to-be-done activity with the stakeholders.
I suggested that becuase of certain constraints and language barriers, due to our limited Hindi in the team, we should consider and design a short diary study that met the technical needs of the users who would be using the service. Through a brainstorming ideation workshop, it was decided to use Whatsapp as the medium from which to run the study. as a team I organised a checklist and got colleagues to create the study including consent and incentives.
Engagement levels were low to begin with, however through an increase in prompts, responses increased gradually. We ran this study over a two-week period. The research questions we created looked at finding out more about the users habits around looking for specific information on the behavioural sciences - in relation to their academic background or employment role. The study looked to capture emotional responses a well.
The results from the two participants who took part in the study, gave us some valuable insights around pain points on other community platforms which we used to map out ahead and inform the wireframes.
Generative research - our intention early on was to gather as much information as early on as possible and transfer this on to sketches to help match the clients mental model. I like to keep a record of stakeholders mental models by using bill Verplanks Interaction Design framework as a way to guide the design process.
The Research team produced early sketches and shared after each session.
Discussions at this point were feature-focused and I recognised we had to shift this to a user-outcome one. One way of doing this quickly was conducting a jobs-to-be-done activity with the stakeholders.
