Data Point History
One data point in the embeded systems goes through various iterations before it goes into final system. Business now wanted to track the history of the data, had already finalized a modal design, but just wanted
Background
This is a small section of large project.
The application is mainly focused on facilitating the autosar exchange with embeded systems for the vehicles manufactured and maintained by the business. It simplifies the data and convert it to the business used formats, add translations for the vehicles used in different countries as well as provides ability create the data points needed.
This is a complete redesign of the existing MVP created earlied. I was assigned to provide guidance and support to the teams mid way while development of redesigned product, which then turned into major project in the kitty.
Whenever a file is uploaded to the exchange, important data labels are verified, translated, reuploaded, replaced, the translation is verified, approved rejected or marked for specific purpose. We need to maintain the proper history of the of every transaction and transformation happening to each data lable/point
The User Story was ready for grooming when i joined the project and was decided to have 3 seperate tables for translation changes, uploads & rewrites and Status change. There were many items still needed to be discovered.
Discovery
The approach already decided was simple and clear with 3 different table in a modal each has details about specifit type of transaction. Still, with the details already created in the user story, we took a back step to understand the user’s need in a way to discover anything else that can help the user better usage of the data
In short interviews with some users and UT with quick mockups of the approach decided,we discoered,
1. The history of the labels is data they might view very rarely
2. The 3 different tables approach give good seperation of data but creates confusion in the chronology
3. Usually the data is uploaded only once or twice, but the status change might happen frequently.Having three tables was reducing the number of rows visible without scroll.
The alternate approach
The approach already decided was simple and clear with 3 different table in a modal each has details about specifit type of transaction. Still, with the details already created in the user story, we took a back step to understand the user’s need in a way to discover anything else that can help the user better usage of the data
we decided to make it one table in a modal and adding some extra columns to add details of what action was happned. The aim of was to
1. increase the number of history transaction to be visible without scrolling
2. get more details about each transaction
3. Maintain clear chronology of history
4. Give ability to filter the table
Validation
We got in touch with other users again in a quick calls to review the new design without showing the old one and A/B testing with few users, we found that the users prefered the new data for better details and simple design.
Conclusion
There are many minor features where we jump to a easiest possible solution. But a little research can help us get far better insights and we can deliver a better experience to the user.