February 2017 - Now
What is Kitman Labs?
Kitman Labs is about 90 employees. It is an organisation developed to allow sports staff to monitor and analyse elite teams performances and medical data. It goes one step further than other sports vendors by using machine learning to highlight injury risk and therefore offer actionable insights for the sports practitioner when making decisions about performance optimisation along with who will and won’t train or play. There are a number of products in the portfolio targeted at collecting data from athletes and visualising that data.
As I currently work here it is difficult to showcase some of the work. Instead I have decided to highlight some areas of influence and an overview of my role. One project I can show is theinformation architecture update, you can see that here.
Role - UX Design & Research
My role revolves around collecting as much information about users and customers so we can feed it back into decision making. This is done through customer success team feedback, on-site contextual enquiries and interviews, regular weekly calls, sales team feedback, usability tests and analytics. This is the core aspect, understanding the users, their wants, needs motivations, context and workflows.
Once there is strong understanding we can target pain points, develop new features, refine current features and remove rubbish features. We can answer questions about marketing strategy and update sales information to get the attention and garner the interest of possible and current customers. I work across the portfolio, collecting user research and designing the users experience.
Some Areas of Influence
Determining what to do and where to start
When I joined Kitman Labs there was no mature user research or design approach. It revolved around asking certain members of the internal team and odd trip to a team. My aim was to target the understanding phase of the Design Thinking framework and hope to have a knock on affect on the rest of the process. I wanted to introduce a broader set of techniques to allow for understanding users, like more ethnographic research, regular video call interviews, analytics and some indirect methods, like leveraging our Customer Success team, who have strong relationships with our users, in getting feedback.
1 - Personas and Backroom Staff Hierarchy
To do this I decided on looking for something small first, creating personas and developing a view of the backroom staff hierarchy. In any pro sports team there are a number of roles operating, creating a graphic of this with internal stakeholders would allow us band together and create something, which I would then go on the road to test with actual teams, in parallel developing an understanding of the user roles in the teams.
Once we developed the view of the backroom staff, validated it, changed it and shared it, people wanted more. As a byproduct it involved the Customer Success team, who are experienced Sports Scientists, and allowed user research to plant itself in that part of the company.
2 - Analytics
Google Analytics existed, as in we had collected some data about users, but in no way was it filtered, understood or shared with the wider team. I knew we were stuck with G.A., which has it pitfalls but can be very useful nonetheless, due to the lack interest in analytics and due to tight budgets. I began by filtering the accounts, for each of our products, so the data was clean.
Secondly I began introducing event tracking to feature releases. This was met with scepticism. On one of my early projects, creating a graphing tool to showcase biomechanics data, I worked with a Front End Dev who was the only keen person to add event tracking. A few weeks after implementation we saw no one was actually suing the graphing tool and it became obvious it was not that valuable. The benefit of tracking was generally seen and people began coming to me with questions about usage. We are in a good place now. We have regular reports set up and have some good indicators of how the product is doing.
3 - Usability
Usability testing was something which was being done when I had started. The problem was the ad hoc nature and lack of scenarios, sample size, control, documentation and general structure. This was an easy enough fix, I simply shared best practices around conducting user research and conducting usability tests. Showcasing the benefit of testing something small and quickly, whilst also reducing the length of the tests, they were very long and frustrated participants meant we increased return participants along with the general number of participants, all while introducing more rigour into the testing.
4 - Secondary Research
We work on small and big features, depends on what’s needed. One thing I notice is the lack of design starting points and the poor use of certain interaction patterns, in general, and this was also the case here. Meaning, sometimes designers want to change the world via UI components. Why use a massive Dialogue Modal with over the top animations when a simple dropdown is more fitting for the content? Through using Norman Nielsen, along with other sources, I introduced a base starting point for selecting interaction patterns, beginning with secondary research. I am not against breaking rules, but at least know them before you break them. We have advanced the design process by including reasons we chose certain patterns, not on a whim.