Strix is a family of solutions that manages, administers and monitors "things" or entities, such as vehicles or mobile devices (GPS, phones, key-ring localisers), in real time, generating alerts on preset events and allowing the analysis of the information obtained to improve different types of processes or subsequent actions.
The first task was to find out what strategy our client wanted to follow:
What is their target?
What needs do they have?
What product or service do they have to offer and where?
What are the characteristics of their product/service? Who is their competition?
What is their differential value? Strix's solutions are based on the same internet of things (IoT) platform, internally known as Magenta. Each solution applies to a vertical market and is composed of one or more products. In turn, each product is made up of one or more features and each feature can also include or depend on other features (the latter are also known as capabilities or enablers).
The team behind the process involved marketing, sales, product and IT personnel from Lo/Jack's team and designers, architects and engineers on the Leapsight's team. This 'cell' developed this new solution together using our agile processes and methodologies.
Behind every successful product, there is a clear strategic vision that takes into account the market and the customer's needs. Essentially, strategy is the set of choices a company makes to achieve its objectives'. These options include which products to develop, which market segments to focus on, how to differentiate yourself from the competition, how to calculate the price, how to position yourself and much more.
The only information we had related to the product was the product itself. So that became our starting point: to get to know it and other, similar products from the competition. Our first step was, then, to try to define the issues and targets from our client's point of view. That made it essential to understand the platform's users, mainly those who interact with it for up to eight hours at a time in front of a screen: the monitoring operators.
We planned our steps using what we call our design thinking model:
We interviewed users with different profiles, to better understand their perspective on the topics presented. This helped us to resolve specific problems related to the UX and UI of the current platform. We discovered that many people were not using 100% of the tool's functionalities because I don't know how to use it', or because they considered some of the features irrelevant.
All these points were taken into account and documented on a spreadsheet and shared with the client in Notion, a tool for writing, planning and organising digital projects, used by both the Leapsight and client teams. Using this research, we began the ideation process, where we reviewed and analysed the product's problems (detected by us, our client or its users through the interviews).
Among the problems that we detected in the application, we highlighted that:
Some of the possibilities for improvements that we analysed were:
Notion's spreadsheets helped us record, order and visualise all the issues that we had to take into account in order to categorise them according to ideas, proposals, priorities, effort, relevance, estimated development time and people involved, to use in stories, which were put into Craft, another of the project management tools used with the client.
Although its main use is to expose functional issues to our client, we actively participated in the process of developing the what and how to make them visible.
This process was constant and changing, since the definitions and their adjustments directly affected the visualisation structure that arose from the design and the user experience, e.g. what the user registration processes would look like, where to manage them from, conditions, labelled entities, entity information display modes and traces.
These are some examples of functionalities that were adjusted based on new ideas, customer feedback, opinions or suggestions from the user tests carried out.
The fundamental purpose of this design system is to facilitate the work of our team. Once our target is defined and we have an initial idea of what is already in place in the company, it will be easier to know where to start. The first thing to keep in mind: design principles are so much more than just the visual aspect of a product.
Design principles are the guidelines that help our team to achieve a product's purpose. They will help us to make meaningful design decisions. Aside from producing documentation directly related to the system, our team will also seek ways to ensure best practice. We will explore general best practices and extract the most relevant to the product and our team, which will help us form and develop our technical skills. A design system is a full product that will help project stakeholders build other products.
As with every good product, it will have its own backlog and will have to build itself in an iterative way, keeping its users (designers, developers, PO, etc) at the heart of its approach. The more integrated a system is into designers and developers' workflows, the more effective it will be.
Once the initial desired functionalities for the MVP (minimum viable product) were validated by the client through user stories, we began to work on the visualisation and usability of the tool. The first thing we considered was navigation, since Strix has produced a solution that includes different embedded products, which the client contracts according to its needs.
This means that a user, when logging in, can select which product to use and is able to switch between the products, if necessary.
strix flotas initial wireframes
Our first visualisation concepts: Products Launcher
Spacing, layout grid, text styles and colours
Once the final adjustments in the wireframes were made according to the required user stories, we began to test the user workflows on a higher quality screen. It is not only a black-and-white interface, but also based on the components designed according to our system.
These screens also serve to make interactive prototypes for tests with users.
The mock-ups include not just the main workflow screens, but also those that the client sees only very occasionally (eg change of profile photo, account reset, etc). Differences in device resolution are also taken into account, from desktop to mobile (responsiveness).
Example of responsiveness applied to a web page
User Settings pages
Fleet Management pages
Live Tracking pages
Marker design evolution
Designing for our final users.
We ensure our product has a real purpose. Does it solve the user\s problem? Does it help to fulfil a need? At that point we realised the target product could offer more value than the incumbent system used every day.
In today's world, products cannot just be functional. They must be intuitive, user-friendly. Typically, you test the Value and Usability at the same time.
We made sure our team could build the product. This is where the role of the cell was fundamental, since it was up to the client to understand how the user wanted to use the product. The role of the development team was also important, as it defined the technical development.
Through testing, we found out what our users wanted to obtain from our product or app. The best results came from listening carefully to customers and seeing how our users tried to use our product prototypes. We asked them to use the product to achieve something specific. We analysed where they got stuck and what seemed unclear to them; we listened to their comments, what they were waiting for, what other functions they would like to see, what they found frustrating and why.
We used this feedback to create new versions of the prototype and retested with users. This cycle of rapidly building new prototypes and testing them with users was the key to effective product discovery and helping the team find the right product to build
Our final step was to develop all graphic and code assets needed by the development team: graphic assets in different formats (vector/svg, bitmaps, html code, css); and reference documents on platforms such as InVision (for interactive mock-up and presentations) and Zeplin (for more detailed specifications of each asset-size, distance between components, colours, transparency, state, etc).
Example of web page mockup published in InVision App
Example of web page mockup published in InVision App
Example of web page mockup published in Zeplin.io