top of page
Matos hero2.png
Logo Black.png

Sports gear 
Maintenance tracking application

unnamed.png

01

About the project

Matos is a sports gear tracking application
It utilizes Strava athlete's data to prompt

them when service or replace is due,
to keep equipment and its components well maintained.
Users can follow the app recommendations or create their own notification rules. Matos also study the users behaviors and adjust its prompting rules accordingly. 

My role

Concept research 

Concept development 

Product definitions

End-to-end requirement writing 
End-to-end development with Lovable Visual design 
Product marketing

Challenges

Defining the user workflow to be intuitive and fit all different scenarios, while writing the requirements.
Passing the Strava compliance to get their dev API keys, and having the app harvest just the essential data from Strava to form a data base that feeds the apps needs.

Objectives

Building a large user base to work with the app from the get go, in order to fine tune the different rules to suit the users and their equipment variety.

Having a sustainable app that maintain its own data and train itself to support the users.  

02

Research

I’ve held 23 interviews with end users- Athletes, bike mechanics and surfboard builders,

to establish the base ground for our users needs,

I held 52 surveys to gather information, and read several professional guides on bike and surfboards maintenance  

Intakes

- As an MVP version, start with bikes (3 genres) and running shoes (2 genres) 

- Image processing tools needed to enhance and highlight different tissues and areas.

- Marking, measuring and drawing tools are a must.

- Radiologists work mostly in dark environments, ‘dark mode’ themed application is preferred.

-AI can make the initial diagnosis, but the user will check and make the actual final calls.

- Patient cases hold multiple angles of the same injury, users need to compare the different angles simultaneously

​

04

03

Defining the project scope

Using the conclusions from the research phase, I framed the main user workflows and began to build the high level project roadmap and the basic application infrastructure. 

Key workflow checkpoints- ​

- The main workflow should be based on gear that fetched from Strava. 

- Gear shall also be allowed to be added manually, detached from Strava. 

- Gear should be broken down to individual components, each with its own rules. 

- Users should be able to manually correct the milage, date and time in use values.

User workflow mapping

Describing the main workflow of the application in high level

Matos WF.png

"Add gear" flow

Describing the high level process of adding new gear to the user account

Add gear flow.png

Bike setup wizard flow

Showing the process of registering a new bike to the system

Setup wizard.png
Sketch.png

04

Lo-Fi wireframes 

One challenge of forming the initial design concept was to create a simple design that calls out for minimum user intervention, while serving all info and required controls. 
Another was to comply with the Strava requests to get their pro developers API keys.

Intakes

- The main screen should be a simple dashboard showing the different gear items and their status.

- An ability to add gear items outside Strava is also needed. 

- Registering the many different components for each gear (mainly bikes) can be tedious, a setup wizard could help           making it much easier.

Log-in screen

Defining the basic structure of the login screen. this was a mandatory phase in order to get the pro developer API keys from Strava, by proving size and location of their logo in it, and showing that there is a valid SSO an user verification process 

Login WF.png
Main gear dashboard

Presenting the user gear in a minimal card display logic. 
Each gear displaying its current milage, number of components and an indicator showing if any action is needed for its maintenance

Main screen WF.png
"Add gear" process

Designing the process of adding new gear to the system or setting up the existing ones,
Using the setup wizard

Wizard 1 WF.png
Gear setup wizard

Designing the step-by-step wizard for setting up the gear in the app that will result in a detailed gear card

including its main components

Main screen WF_edited.jpg
Wizard 2 WF.png
Main screen WF_edited.jpg
Wizard 3 WF.png
unnamed (1).png

Detailed design 

05

After translating the user needs and flows into basic screens layout, it is time to put all the finishing touches into the app

Intakes

- Design for PWA (progressive web app)- a web app that could be installed and act like a standalone mobile app.

- A simple and easy to read design language is needed, including a large set of icons

   to represent all gears and components  

- Covering all aspects of a standalone app is a must- including notifications, help page, costumer support,

   user profile and more.  

Log-in flow

After the user set up their, by creating an account and pairing it with their Strava profile, they can login to Matos and it automatically syncs with their Strava gear.

Login.png

The main log-in screen

Login2.png

Indication that the Strava profile connection was established

Dashboard main screens

The app main screen presenting all the users gear and its maintenance status. 

Dashboard.png

The dashboard screen minimized card display for all the user's gear items.
Each card only essential info

and the maintenance status

Iphone mock.png

When expanded, the individual components constructing the gear is presented, along with its progress bars, prompting rules and different controls 

App notifications

The app was built as a PWA, with the ability to send push notifications as well as being installed on the homescreen 

Lockscreen notifications.png

Lockscreen notifications, reminding the user of gear in need of attention

Iphone mock.png

When expanded, the individual components constructing the gear is presented, along with its progress bars, prompting rules and different controls 

Sibrica hero.png

08

Results

After validating the concept with several users in deferent sites,
we developed a preliminary working concept and deployed it in some of our costumers labs for a field experiment with very good results.  
The company is now developing the algorithms on which the machine learning process will be based on- The first step in building the new product. 

88% positive purchase intent 

Users are keen to try the new product, 
and waiting for it to be launched

33% reduction of diagnosis time

Preliminary concept had proved a massive reduction in end-to-end case diagnosis time 

25% increase in diagnosis accuracy

First deployed working concepts show a great increase in case diagnosis accuracy in comparison to their current diagnosis tools and methods

Where to next?

bottom of page