Overview
Context
ssÓtica is a management system focused on opticians. It has standard ERP modules: sales, customers, tax, products, finance, etc. The tax module by itself was responsible for 30% of support tickets, so the challenge was to discover and address user pains in this scenario. Since it was a monolith, the application's main structure could not be changed.
Process
To ensure that all relevant data was collected, interviews were conducted with company staff and accounting experts. User interviews and observation, surveys, data collection via Hotjar, and benchmarking were also used to identify user needs and potential solutions. This process resulted in 3 main personas and a customer journey, used to guide the design of low and high-fidelity prototypes that were tested with users.
Role
I planned the whole process, as well as conducted user research, data analysis, and designed and documented the solution. Product owner and developers were part of the decision process throughout the project.
Outcome
The usability tests were positive and along the research quick wins were found so that small improvements could be applied before the whole redesign. Unfortunately, with the pandemic arriving, the new module implementation did not happen so we don't have data about decreasing support tickets.
Planning
Since it involved redesigning an extensive and complex module, the project was divided into several stages to ensure the objectives were achieved.
The first stage involved understanding the needs and possibilities, as well as determining when the tasks would be executed. The activities were divided into phases:
1. User research
2. Research analysis
3. Wireframes
4. User testing
5. Final visual design
2. Research analysis
3. Wireframes
4. User testing
5. Final visual design
The entire planning process was organized and executed using Notion for better visualization and tracking. The initial estimated duration was 2 months: 1 month for research and 1 month for design.
Partial view of Notion after the project is executed, including dates, data, and descriptions.
1. User research
To ensure data collection from all angles, both internal and external research was conducted, allowing input from both users, experts, and stakeholders.
Expert and stakeholder interviews
Key individuals within the company were interviewed to gain in-depth insights into the issues related to the fiscal module. Each interview had a specific goal:
. CTO: gather requirements and technical limitations of the fiscal module.
. Customer Support Manager: gather quantitative data and key insights on customer inquiries received by the Support team.
. Product Owner: understand the module's relationship with other areas within the product and expectations for the redesign.
. Company's Accountant: clarify the specificities and fiscal terms that were part of the routine for micro and small businesses.
Shadowing
For several days, I worked with the customer support team to understand how user pain points reached the team and how they reacted to those questions.
This immersion made it easier to understand how the fiscal equipment setup process worked, the most labor-intensive step of the entire onboarding process.
Company employees workshop
To consolidate the knowledge that different departments already possessed about customer behavior regarding fiscal routines, a workshop was conducted with 2-3 representatives from each department (customer support, sales, customer success, marketing, and IT). Questions were provided, and each department wrote their answers on sticky notes, which were then placed on the wall under each question. After a designated time, all departments discussed the answers, shared experiences, and emphasized key points.
This activity not only facilitated knowledge sharing among departments but also resulted in over 120 insights in topics such as behavior, difficulties, and user knowledge about fiscal management and the system.
Some of the sticky notes that were wrote, but digitalized
Hotjar data collection
As part of the research strategy, the IT team also installed Hotjar in the system to exclusively track the usage of the fiscal module. With the collected videos, it was possible to clearly see the difficulties faced by some customers, who spent up to 50 minutes trying to fill out and issue an invoice.
Benchmark
Several competitor solutions were analyzed to understand which established standards might already exist in the market. Among them, the main reference for experience and usability was Conta Azul, a leading management software in Brazil.
Survey
To understand the scope of customer profiles using the fiscal module, an online questionnaire was created. The main topics covered in the survey were:
. Where are the customers located?
. How frequently do they issue each type of fiscal receipt?
. How much do they know about fiscal matters?
. Where do they learn about fiscal matters?
. What is their relationship with the accountant like?
. What are the main difficulties?
. Have they used other software before?
. How frequently do they issue each type of fiscal receipt?
. How much do they know about fiscal matters?
. Where do they learn about fiscal matters?
. What is their relationship with the accountant like?
. What are the main difficulties?
. Have they used other software before?
In-depth interviews
It was also necessary to understand the motivations behind each user behavior. Therefore, some people who responded to the online survey were invited to participate in a telephone interview. In this stage, topics explored included:
. How does the sales process work in the store? How does the fiscal part fit in?
. When/how do the mentioned difficulties occur?
. What would they like to see improved in the process?
. How was their experience with other software (if applicable)?
In addition to phone interviews, two people were interviewed in person during store operations. The focus of these interviews was to understand:
. When/how do the mentioned difficulties occur?
. What would they like to see improved in the process?
. How was their experience with other software (if applicable)?
In addition to phone interviews, two people were interviewed in person during store operations. The focus of these interviews was to understand:
. What is the daily routine of the store?
. How does the fiscal module appear in their day-to-day activities?
. What are their behaviors throughout the day?
. What physical factors influence the use of the software?
. How does the fiscal module appear in their day-to-day activities?
. What are their behaviors throughout the day?
. What physical factors influence the use of the software?
2. Research Analysis
With all the collected data, the material was treated and analyzed by cross-referencing the information extracted from the research with other information extracted from the system itself. The main topics that we could clarify at the end were:
. Who are the people using the functionality?
. What perceptions do we have about these people?
. What do these people tell us directly?
. What do these people tell us indirectly?
. What do these people do?
. What is the process these people go through?
. What do we need to do to improve the experience with fiscal documents?
. What perceptions do we have about these people?
. What do these people tell us directly?
. What do these people tell us indirectly?
. What do these people do?
. What is the process these people go through?
. What do we need to do to improve the experience with fiscal documents?
With all that knowledge, two main tools guided the rest of the process:
Personas
Three common profiles were identified based on the behaviors identified in the research materials. They had characteristics such as:
. Frequency and types of issuing fiscal documents
. Most used devices
. Perception of the module's ease of use
. Motivation
. Main pains and difficulties
. Positive aspects of the current module
. Most used devices
. Perception of the module's ease of use
. Motivation
. Main pains and difficulties
. Positive aspects of the current module
This made it possible to define the common points among the profiles that should be addressed first, as well as what was specific to each profile, requiring a more targeted approach at another time.
Visão das 3 personas identificadas durante o processo.
Customer Journey
To understand how all the stages were related and which pains came from the software itself or from other points in the journey, a Customer Journey map was created. The goal was to gather all the phases, reactions, touchpoints, and pains the user could experience in one place.
By mapping out this process, it was possible to identify several actionable items that were not solely related to the interface itself. Things such as adding content about fiscal routines on the ssÓtica blog (for both attraction and retention), partnering with maintenance platforms for fiscal equipment, and expanding the help content (possibly creating a future "University" of the system, as many SaaS companies do) emerged.
Complete customer journey. At the right, lines were: external touch points, Ipê's touch points, ssÓtica's (system) touch points, pains, emotions and improvement opportunities. At the top, the columns are in order: needs awareness, setup, recurring usage and specific usage.
Of course, aspects beyond the tangibility of the interface would be considered at a later stage, but the other identified improvements could be implemented easily, with some not even depending on the redesign. Based on this, "emergency measures" were introduced, which included small improvements to be implemented while the redesign was still being developed.
Final report slide, that was presented to the whole company, showing quick actionables: explain more common errors, so the user can solve them by themselves, and customer support - more touch points and instructions manual throughout the user journey
3. Wireframe
With the entire process and profiles defined, it was time to actually redesign the flow. For this purpose, a low-fidelity prototype was created, proposing solutions to the main identified pains. The main changes were:
. A new restructuring of the home page for invoices, to facilitate reading and data retrieval.
. Splitting the invoice registration process into stages to minimize the user's cognitive load and facilitate the correct filling of information.
. Contextual information to reduce the visual burden on the screens.
. A help area to clarify the main questions without needing to contact support.
. A preview option for data verification and to reduce errors in issuing invoices.
. Friendlier and more instructive language to reduce the users' perception that fiscal matters were too technical.
. Splitting the invoice registration process into stages to minimize the user's cognitive load and facilitate the correct filling of information.
. Contextual information to reduce the visual burden on the screens.
. A help area to clarify the main questions without needing to contact support.
. A preview option for data verification and to reduce errors in issuing invoices.
. Friendlier and more instructive language to reduce the users' perception that fiscal matters were too technical.
Click on the images below to view the screens in detail.
Previous invoice home page
New invoice home page
Previous invoice creation method: everything all at one
New invoice method: divided by steps
Contextual help area
Errors showed shortcuts for knowledge base
Contextual info
4. Usability Testing
With the wireframe ready, usability testing was conducted. A total of 6 remote tests were carried out, with users spread across the country. The test considered the main activities that users perform in their daily routines, including:
. Issuing an invoice from scratch.
. Correcting an incorrectly issued invoice.
. Searching and exporting data in bulk.
. Issuing an invoice based on a sale already registered in another part of the system.
. Correcting an incorrectly issued invoice.
. Searching and exporting data in bulk.
. Issuing an invoice based on a sale already registered in another part of the system.
Although the overall result was positive, there were some points of concern:
. Some of the terms used were not as intuitive as expected.
. Users expected more integration with the system as a whole, which could not be validated during the test but was added to the list of technical requirements for development.
. Not all icons and shortcuts were intuitive for the users, requiring further revision.
. Users expected more integration with the system as a whole, which could not be validated during the test but was added to the list of technical requirements for development.
. Not all icons and shortcuts were intuitive for the users, requiring further revision.
Corrections and insights board, showing users feedback prioritized
5. Final visual design
The improvements from the usability testing were directly incorporated into the visual design, where the final version was built based on the feedback received. The focus here was no longer on structural changes but rather on the evolution of what had been defined, including:
. Applying the Design System standards to the designs.
. Creating the responsive version and defining which features would be incorporated or hidden.
. Providing examples of interaction scenarios and error states, offering more detailed input for the development team.
. Creating the responsive version and defining which features would be incorporated or hidden.
. Providing examples of interaction scenarios and error states, offering more detailed input for the development team.
Next steps
With the design phase completed, the userflows were documented in collaboration with the Product Owner (P.O.), describing the expected rules and behaviors in addition to the visual design. The next steps would involve the implementation and monitoring of usage metrics, particularly in comparison with the previous metrics of the module.
Unfortunately, the project was deprioritized due to the pandemic, and it was not possible to have practical validation of what had been designed.
Key takeaways
I believe my greatest learning experience in this project was executing a research plan from start to finish, that was the first time that I'd ever done it. Having the opportunity to plan and execute each stage provided valuable insights for the final design, as well as a deeper understanding of the context and users of the ERP as a whole.
Furthermore, the integration with the development team was crucial from the beginning, and maintaining close collaboration helped avoid many technical errors in the proposed solutions. Being close to the Product Owner and assisting with technical documentation was also extremely valuable, as the fiscal technical aspect was one of the things that needed to be translated and simplified the most for the users.
