Designing for data modeling
Challenge: Improve functionality and searchability to increase Data Modelers efficiency and the scalability of the tool to other lines of business (LOBs).
My role: As the Service Design Lead, I worked with our product partners to appropriately define the problem and the scope of research. I led the research discovery and facilitated interviews across 10 users with unique jobs to be done. After synthesizing our findings, I worked with tech and product teams to identify and prioritize opportunities to define the MVP and created the prototypes for user testing.
My team: Service Design Lead (me), Product Partners, Tech Partners
Impact: Improved data usability company wide through canonicalization enabled by prototyped and tested work management tooling and leadership tracking.
Summary: Our data modeling team and product partners came to us with the ask to help them rethink the UX flow of their internal data modeling tool with the hopes it would become the one stop shop for data model input and output for all LOBs. Over 4 months we led research with 10 users of varying roles, uncovering critical user pain points around knowledge transfer and storage and inefficient communications that greatly slowed their processes. We identified and assessed solutions that could quickly build foundational research storage capability and worked with our tech teams to phase out commenting and tagging capabilities to bring communication and records into the tool itself for quicker and more reliable communication needs. We designed 2 net new pages and redesigned information hierarchy across the entirety of the experience.
The Research Process
The product team had already done initial research and designs and wanted design to validate the direction and UI as they pushed for new‑user adoption and scaling across lines of business. Beyond a few immediate “no‑regrets” fixes, we needed to understand how the tool should behave at scale and how it fit into the broader ecosystem.
Working with product, we recruited 10 participants across roles and seniority. We ran 45‑minute Zoom interviews with demos, starting with high‑level process and pain‑point questions and then probing integration and flow needs. Every session was recorded and transcribed verbatim; key quotes and observations were placed on a color‑coded digital whiteboard by interview and role to drive synthesis.
Current state blueprint by user mapping out each step of the process with related pain points.
the Findings
We clustered interview data into themes and pulled three critical insights. First, users don’t trust Modelhub’s inconsistent metadata naming, manual updates, and no included decision rationale makes attributes hard to verify and maintain. Second, communication and findability are weak: conversations live in Slack/meetings with no record, search and filters are limited, and users struggle to locate the right attribute. Third, the wider ecosystem creates friction: there’s no visibility into what’s modeled versus pending, comparisons and reporting are difficult at scale, and users routinely fall back to eight external tools (especially for case management and status tracking) because Modelhub lacks those capabilities.
In parallel, we mapped a current‑state blueprint that traces the end‑to‑end flow—from requester intake and research to modeler definition, external approvals (managed in spreadsheets/Slack), and handoff to the Drools team for rule implementation—highlighting pain points and bottleknecks at each step.
the users
After assessing the current state process we took another look at the users we interviewed and the necessary roles we were seeing across the process. We noticed that both product and analysts had the same job to be done though they had different expertise to get the job done. We grouped these two users under “consumers” as that more accurately represents their relationship with the data itself. We then wanted to highlight how we could think about access by user and impact on each page by user to better understand the overall needs and track impact as we looked to build out our roadmap.
the opportunities
We synthesized research into opportunity areas and ran a cross‑functional ideation with product and engineering using a creative matrix and How‑Might‑We prompts focused on cleaner data, better communication, and improved tracking. We then prioritized concepts by impact, effort, risk, and dependencies.
With engineering, we validated assumptions and built an opportunity tree—color‑coded by impacted page—to show sequencing and effort. Items that would significantly improve research or approvals were flagged as high priority.
Two foundations emerged for the MVP: a restructured search (single, extensible query with advanced filters to support API/consumer/producer search later) and an attribute‑level research section (comments, tags, and links to capture provenance and support approvers). Remaining ideas were scheduled as next/then/later work to build on those foundations.
The Flow
To improve both trust and efficiency, the process needs to decrease the amount of manual processes and updates. We optimized the process at large and determined critical triggers for reach stage that could easily be automated. We identified both the frontend and backend needs and actions of each stage. Finally, we renamed the stages to be clear, general, and easily understood by any user especially if new so that clarity, relevance, understanding can be sustained when scaling the product.
The Design
We built out low fidelity wireframes to showcase the overall flow and better test the MVP to make sure we were tackling critical user needs and functionality.
Search: In order to clean up the search page and lessen the amount of information on it to increase intuitive behavior, there should be one search field that accepts either source attribute name or canonical attribute name. For further search refinement, there should be an additional filters button.
Filters: Upon clicking filters for further refinement, a modal would appear on the right-hand side. The filters will be checkboxes to enable multiple filters at once. Each of the filter options will be organized by priority usage with status as the first section.
Search Results: They will surface high level information pertaining to the attribute, its hierarchy, and the overall status and management of the attribute. This information will automatically update upon any change. The user will be able to star results, which will appear in their profile.
Research Tab: Users strongly asked for a research tab that they could store their research in, so they don’t have to go back and find it all each time they need it, and so they have a way to quickly reference it for any questions down the line. By providing a separate space for links and notes, it allows quick access to the links when needed, but also free form sections for any context that may help knowledge transfer.
Metadata Tab: Generally users really appreciated this page and the hierarchy of information. By creating a tab structure, it allows for this page to focus on the metadata and have each other section be reference when and if it is needed.
Drools Tab: Drools team has to scroll through everything each time they update their work. By allowing them quick access to their section with a tab, they can easily pick up where they left off without scrolling. Additionally, at the point where the attribute is with the Drools team the transformation tab can be the default page.
Request Intake: Currently, requesters do initial research and include that in their request, but because of a lack of formal knowledge transfer, the data modeler builds out the research from scratch. In allowing the requester edit access to the research tab, they are able to store their information that can then be modified or built off of by the modeler.
Profile: Users eventually want to be able to track their work in Modelhub. In the meantime, though, they at least want to easily find what they have been working on or collect the attributes that are ready for review in a meeting which can be done by populating starred attributes in a profile view.
