Schemata*, a Database Schema Management Tool
Optimising the workflow & ensuring greater accuracy for database schema designers
*Redacted name; as the nature of this work is confidential, details at times are kept intentionally vague.
Project Overview
Schemata*, a tool for managing database schema, is central to the company’s operation. It serves as a foundation for maintaining a relational database schema that is primarily designed to support network analysis.
*Redacted name; due to reasons of confidentiality, specific details about this project cannot be disclosed.
Timeline
October 2021 – April 2022
Team
Product Manager
Backend Developer
Frontend Developer
Product Designer (Me)
Contribution
Led redesign project as the first and only Product Designer.
1 → N
Tools
Figma
Miro
Google Meet
JIRA
Slack
Problem Discovery
The existing tool experienced several issues: an inconsistent and non-intuitive user interface; use of technical jargon and complex terminology; and a lack of documentation leading to user frustration and increased risk of errors and system misuse.
During the initial stages of the project, I conducted a heuristics review of the existing tool. Some of the key challenges identified included:
Usability concerns: The use of inconsistent components, along with issues related to responsiveness, accessibility, and navigation.
Technical jargon and complex terminology: Some features were challenging to understand due to the use of technical jargon, and the accompanying documentation was inadequately prepared.
Scalability issues: Without a design system in place, the product was not optimised for future scalability, potentially hindering expansion and growth.
The aim was to modernise the system, simplify the user experience, and make it intuitive for both new and existing users, which in turn reduces the need for extensive user training.
Context / Research Methodology
Although users were available for testing, strict confidentiality measures were in place at the company, restricting external access to users beyond the project team.
As a result, user testing was conducted internally, limiting the scope of external validation. Despite this limitation, efforts were made to ensure rigorous testing with internal stakeholders and team members for feedback and validation.
Such limitation necessitated a stronger reliance on secondary research. I first performed a comparative analysis of other database schema management tools. To delve deeper into the tasks and concerns of database schema designers, I sifted through community discussions on Quora, Stack Overflow and Reddit.
All this research provided valuable insights into the challenges and considerations that these designers face, which greatly informed my design iterations and improvements for the product.
Mapping the User Flow and Identifying the Pain Points
Capturing the designers' workflow and their tops-of-mind: accuracy and integrity above efficiency, optimisation, scalability and security
Beyond performance concerns, scalability challenges and security vulnerabilities, there is seemingly the fear of data integrity issues (such as accidental data deletions or modifications due to design errors), as well as anxiety around the permanent and time-consuming nature of making changes to the database schema.
Drawing from the insights gathered through the secondary research, I was able to identify specific areas of concern and opportunity. This led me to hypothesise that these insights could be translated into a key feature, presenting an opportunity for us to differentiate ourselves through this approach.
Translating the Problem into an Opportunity
Validating Assumptions
Given the key constraint of not having direct access to the database schema designers for user testing, the validation of assumptions for this project was approached with a combination of internal testing and secondary research.
To gather initial feedback on the proposed design features, I conducted internal testing with the product team members.
While they are not actual end users (i.e. the database schema designers themselves), their insights and feedback provided a preliminary understanding of the usability and effectiveness of the proposed features. Based on this feedback, the original designs were iterated and refined to better align with the needs and preferences identified during the internal testing phase.
However, it is important to note that their perspectives may not fully represent the needs and preferences of the end users, introducing limitations to the methodology employed. The team acknowledges this potential limitation and took it into careful consideration when interpreting the findings and outcomes.
Iterating Based on Feedback Gathered
Clearer, more confident design choices post-team chat.
Rounds of feedback gathering informed iterations that seek to further enhance the user experience and streamline the workflow, thereby increasing the confidence of the database schema designers in making changes to the schema.
For instance, I learnt that modifications to the database schema are not easily reversible as it impacts thousands of existing records. This insight gave me greater clarity to move towards a design option that introduces a deliberate layer of friction requiring designers to thoroughly review all changes before publishing them to the database.
Impact
Although precise metrics are not available due to me leaving the company prior to any conclusive evaluations, the UX improvements implemented during my time at the company are estimated to have positively improved user engagement and satisfaction.
Intuitive User Experience
with clear, consistent microcopy.
Established design system
allowing for greater conformity and scalability.
Streamlined User Journey
reducing friction and enabling faster task completion.
Takeaways
Collaborating together
Without a deep understanding of database operations, I teamed up with our in-house technical experts. This collaboration was crucial to grasp the nuances of database schema design and craft a solution that met the technical requirements and needs of database schema designers effectively.
Navigating uncertainty
Facing a complete lack of direct user insights, the project demanded a proactive approach to navigate uncertainty. Working closely with the team, I relied on an iterative design process, continually refining and adapting the design as informed by internal feedback and secondary research.
Bringing UX to the tech table
Introducing UX principles to a tech-focused team was a unique opportunity. As the first and only Product Designer on the project, I shared key UX principles and best practices with a team primarily composed of developers and tech staff. This not only enhanced the project's interdisciplinary collaboration but also underscored the importance of integrating user experience insights into technical development.
