A platform for analyzing the quality of service provided by dealers
And we made it! With a seamless user experience when handling large amounts of data.
Goal
To create an internal system that dealer employees and AO Mercedes-Benz RUS will use to conduct dealer quality surveys and analyze the results. The goal of the project was to reduce the number of internal and external IT systems, as well as of independent Excel/Access databases used in Mercedes to work with dealers’ KPIs.
Design
Our chosen Flat style with respect to the Mercedes-Benz corporate style, and also used design elements of the react-ag-grid, FusionCharts and FusionMaps libraries to unify charts and tables. This simplified the task of frontend development and accelerated the project creation.
Table of results by category
Histogram of the results by dealer
Comparison with previous results
Viewing questionnaire results
Mobile Version
The design adhered to the guidelines to the letter so that the product blends in with the overall aesthetic. Due to the reuse of parts and styles, the design is simple to understand. The motto of the project is ’The absence of unnecessary entities simplifies visual perception.’
Reviewing questionnaires in studies
Authorization
Analytics. Uniform documentation format
It became necessary to divide the creation of the documentation for the project between us and the client. We developed a useful document format over the course of several collaborative meetings, thanks to which the customer’s statements more accurately describe the business issue and the system analysts’ elaboration of the ToR should proceed more quickly. Since several of the system’s modules are slated for implementation, a change management and documentation maintenance plan has also been created for the entire system.
Prototyping and research
We conducted a number of interviews to identify an action group of dealer representatives in order to maximize the outcome and take into account all the wishes. We then gave this group access to project prototypes and displayed the various interface states while taking their comments into consideration. We built prototypes with the service’s expansion and growth in mind.
Technology
Because there may be more user interfaces and backend consumers than anticipated, we chose to use graphQL since it allows each of them to choose the APIs they require. This gave the solution flexibility and convenience.
That choice required more work for us, but it was worthwhile. The system’s additional challenges (a Windows environment on IIS with MS SQL as the database) were not the system’s most dependable conditions.