The ToolSense Mobile App

• Requirements Analysis including internal stakeholder research and user research including customers

• UX & UI of the app

• PO & Scrum Master of the dev team

• Design System set up

What ToolSense does & my role

I joined ToolSense in August 2020, excited about what I was supposed to do: create their mobile app from scratch. The “scratch” was the main source of my joy, along with the friendly, motivated team that welcomed me. They already had an app developed by an app agency but they were not happy with it. So, the plan was to build the mobile app in house. I would define the UX and UI of the new app and manage its development with external developers. There were two more UX designers who worked on the web app with the internal dev team and a product manager who brought together all of us in daily stand ups and other product-related meetings. The whole project is summarized in this Design Case Study.pdf I created.

But before diving any further, let me first briefly introduce ToolSense. ToolSense is an austrian startup that develops software and hardware for managing and monitoring machines. Their clients are companies who have a fleet of machines and operators to manage and are interested in machine performance, runtime, location, maintenance and scheduling.

Discovering the core concepts of the app and aiming at a Lean UX process

I started by creating a full map of the product, its information architecture and user flows and interviewing my colleagues to find out how the customers actually used it. I wanted to pin down the conceptual core: a “glossary” of concepts with which I could work with for the design of the new app. It is interesting to see this map almost a year later and realise how the core concepts have somewhat shifted during the development of the app, for reasons such as slight strategic pivots, introduction of new customers, etc.

Just to give you an example of what I mean by “glossary” of concepts, you can consider the concept of “maintenance”. Maintenance in the ToolSense context, refers to a service performed on a machine on regular intervals, e.g. once a year, to make sure that it works well and there are no safety risks. When I joined, we were always talking about “Maintenance” - it was a concept of its own, separate from the neighbouring concept “Services”, which referred to general services sold by machine manufacturers. Maintenance of machines seemed back then to be the most valuable and strategic service the machine manufacturers could offer through our app. As a designer, you want to give important concepts a lot of visual space. So my initial designs featured a whole icon on the tap bar dedicated to “Maintenance”. As we made progress, acquired new customers and shifted our views on strategy, “Maintenance” got removed from the tap bar and ended up with its own separate icon, featured under “Asset Events”, as one of the types of events in the lifecycle of a machine.

The development process and feedback gathering

After we designed the first set of screens, we did a lot of rounds with the stakeholders, prepared the backlog and got to work. While we were preparing the first screens of the app, we also had zoom calls with customers where we showed them prototypes and asked them questions on their workflow and feedback. I meticulously documented the input and tried to apply it on the app right away. Some requests had to do with the way the assets are presented and they were easy to implement and other had to do with features not yet developed and were left in the backlog.

We followed scrum methodology which I gradually adjusted after careful observation of how our small team (consisting of two React Native developers and supervised by the CTO) was doing. I set the goal to increase the estimation precision (which seemed to be a pain point in our team) and proposed to estimate user stories with hours to remove the abstraction of the point estimation in scrum. This was a measure that worked to a certain extent. Moreover, I put emphasis on ownership in our sprint-planning and retrospective meetings (what did it go wrong and why?); strived to welcome and adapt to feedback; made effort to be close to my team during this socially-distancing time and facilitate the work of the developers (e.g. simplifying design) as much as possible.

Finishing up the first version, Design System & Release

We started thinking and sketching a design system early on, already when the first screens for the app were approved by the stakeholders. As new features were created and new constraints were discovered, the initial UIs had to change, so we didn’t have the stability and the resources required for such an ambitious feat.

Approaching the end of the app development and with developers being busy solving issues, I had the space to think about the Design System as a system that would ideally be self-explanatory and independently used. The system, as I developed it until now includes typography, branding colours, shadows, icons, buttons, overlays, headers, card elements and cards. The idea is that every new component should rely on the existing ones. For example, a card shall be made by card elements only, which in turn include icons, buttons and typography from the library. In the Workshop I gave to my colleagues to explain the system and pass it on to them, I proposed ways to use the existing library, seperate the coded components from the experimental ones and continue the work including also components for the web.

With the delivery of the app to Google Play and to the App Store in July 2021, the first round of work for the ToolSense app is complete. In the following months, there will hopefully be time for the ToolSense designers to establish and expand the design system, perform proper usability studies and respond to customer feedback. I’m looking forward to hear about their progress and the first customer feedback.