Data collection app for equine charity
Mobile web application to collect equine training data
The Project
Data can be a powerhouse of information which could help grow and potentially predict trends in a business. Bransby Horses wanted an application that would allow their users to simple input data which could then aid in the visualisation of this information to help spot trends.
The Problem
The charity was collecting data on the time a trainer would spend with an equine but they had no way of understanding, translating or making any use of this information. The data was gathered manually on a piece of paper which was then transferred onto a spreadsheet.
As a charity the main expense was human resources and the had this mass lump of data which they collected which was ultimately un useful and was seen as a burden to their staff.
The Goal
To create a new product where users of all technical literacy can input data of the training sessions with their equines. To understand what tiggers would allow and equine to move through the various training programmes to help the information be meaning full. To be able to translate and export this data gather in order to see trends and support staff on different areas of training. For the data to be input using a mobile web application and a web application to manage, visualise and analyse the data.
The Process
For the development of this project i worked in a multidisciplinary team made up of developers, designers and product managers whilst working in an agile method.
Define
Map needs and challenges
-
In depth stakeholder interviews
-
Create AS-IS journey
-
Create Proto-personas
Prototype
Conceptualise
-
Low fidelity sketching
-
Mid fidelity prototyping
Understand
Current state
-
Desk research
-
Review the current solutions.
-
Hold workshops with stakeholders
Ideate
Create future journey
-
Crazy 8's
-
User flows
Iterate
Testing
-
Prepare test case
-
Validate design decisions internally and with end users
Understand
Desk research
To get a better understanding of the competitor landscape, i studied if there were any other organisations which were similar to Bransby and if they have solutions to similar problems.
Current solutions
Once i understood the market space i went on to find out why other solutions which they had in place. They were currently using a HUGE spreadsheet which collected the time that a trainer spent with the Equine and was colour coded and interpreted in many different ways by the different stakeholders that i spoke to.
Stakeholder Interviews
In order to understand the real problem We conducted 3 stake holder interviews to really understand the Users needs. We had a better understanding of the origination of the spreadsheet and exactly what they was trying to solve with this.
Early insights
Through the interviews I was able to gather some early insights from the users and the features that would help.
Record training
Having a record of the training an equine undertook and how long they typically spent in the different yards.
Simple and clear UI
Stake holders mentioned that around 10% of their trainers had access needs
Analyse data
Users wanted the ability to make sense of the data that was collected in order to share with board and help inform training across the yards amongst trainers.
Define
Problem statement
I held some Problem statement workshops in order to help define the problem statement based on the early stages interviews we had.
AS-IS User Journey map
I mapped out the users’ steps to see how users currently use their current system and how I could design a product that would help simplify their journey to help them reach their most important goals.
I also tracked the users emotions through the journey map, giving me ideas for areas to improve based on their emotions so that I could create a more intuitive user experience. I was also able to also gather possible opportunities that could be explored.
Proto-personas
As we was still in the discovery phase of a new product I went with creating some proto-personas which was based on the different user groups we had so far identified and the different needs they had. These were to change as we uncovered more information about the users.
MoSCoW & Core features
With a better idea of my users and their needs, I used a MoSCoW framework to help me prioritise the features that i would be adding to the app at this stage.
I then identified the three core features that I wanted to focus on for the app.
1. Input data - Able to input data of equine and create staff profiles through the desktop version
2. Grouped yards - The yards to be grouped and all the equines in each yard to be recorded.
3. Simple and clear - The ability to easily input data through drop downs and record disruptions which is accessible for all users
User flows
The proposed user flows were for the trainer and the admin user and focused on:
- Add a disruption/training session
- Manage Equine (Add an equine)
- Manage trainer (Add a trainers)
- Manage a yard
Sketches
With the user flow mapped out i did some crazy 8 sketches and then decided on one which was i was going to build the wireframes on.
Wireframes
Mid-through the project the stake holders decided that they would want to first pilot the app first and to see if this was a concept that would be well recieved by the users. For this reason i focused on the Trainer side of the user flow.
Ideate
Prototype
User Testing
The users were asked complete a few scenario-based tasks that would test the main features of the app, and were asked how they felt about the app in general. The results of the usability tests were recorded and analysed in order to gather key insights which helped formulate recommendations.
Key Insights
-
All 5 users Enjoyed using the application.
-
2/5 users were looking for a date on the pages.
-
2/5 users struggled to find the back arrow to return.
-
4/5 users were able carry out the task straight away.
-
3/5 users did not recognise their user name on the pages
Recommendations
Highest
-
An arrow or button signifying how they can get to the next step of the method.
-
Explore the search function flow.
-
Should there be a constant username on the pages if it is not adding value.
-
Users knew the name of the equine and would prefer to search via the search field.
-
Some training sessions are the same for some equine and would want to be able to enter data for multiple equine at once.
-
Once submitting an input the date to be visible on the page
-
The ability to change the data entry date if they forgot to input previously
-
A timer function
Lowest
These recommendations are going to be used to create changes to the app based on the user feedback.
Iterate
Accessibility
Stakeholders were very clear in stating that some of their workforce have access needs. Whilst the designs were centred around meeting all needs of all users, i was unable to recruit any users with access needs. For the next round of testing I would prioritise having access need users in the sessions.
Skills guide
Through the stake holder interviews i raised a skills standard which would help the data gathered to be useful. Red, orange and green are very broad and can mean different things for different people. I suggested to further break this down with a guide so that it is uniform and can easily see trends. The charity mentioned that this is something that they have been putting off for the past 2 years and understood the importance of working on that challenge to further help the quality of the data.
Requirements changing
The requirements changed mid project. Finance is always a pain point for any charity and designing something that they couldn't 100% guarantee would be easily received by the users and the charity, they decided to hold back and just test the designs of the trainer.
Ideally i would have designed the admin dashboard for the organisation as i felt it would have easily been able to steer their decision in continuing with the project and help the charity in their long term goals.