Article Management & Data Architecture
Confidential Client — Enterprise RegTech, Life Sciences Sector
Role: Sole Product Designer | Type: 0-to-1 Feature Design
Due to a strict NDA, proprietary UI designs cannot be shared publicly. This case study focuses on the design decisions, interaction logic, and strategic vision behind the feature. Interface designs and a prototype walkthrough are available during a live interview session.
A single product record isn't a single thing. It's a base article, a set of variants, a version history, and a component of multiple product groups. Each with its own regulatory implications, each capable of affecting the others.
When I designed the submission flow, I realized selecting individual articles one by one was the wrong answer. Regulatory teams work with product families. I raised this with the PO, who confirmed groups were needed, then added that articles might have variants. I asked whether groups could also have variants. She said yes.
That single exchange turned a list design problem into a relational data architecture problem.
01
The Four Entity Types
I had four interconnected entity types to design for simultaneously.
Articles: base product records with technical attributes, reference numbers, and regulatory metadata. The root of everything else.
Variants: product variations within an article, inheriting core identity but carrying distinct attributes. A variant name must be unique across all variants and the root article; an error fires if it isn't. In a system where naming consistency carries compliance significance, silent duplication is not acceptable.
Revisions: version history of an article. A revision is like version 1.2 to the article's 1.1. It doesn't replace the original; both exist simultaneously as independent records, each traceable back to the root.
Groups: named collections of articles with specific variants selected per group. The primary unit for submission selection. A group references articles; it does not own them. This distinction determined every downstream design decision.
.png)
02
The Constraint That Determined Everything
The most important decision in this system was the one most invisible to users.
A group references its component articles; it does not own them. An article can belong to multiple groups simultaneously and be part of active submissions. If a user could edit an article from within a group, that change would silently affect every other group referencing the same article and potentially every active submission using it. In a regulated environment, that is not a usability problem; it is a compliance risk.
The principle behind this decision is simple: you cannot change a component without knowing what it affects. Designing inline editing would have made the interface feel convenient while creating invisible downstream consequences that users would have no way of anticipating.
The design makes the editing path explicit. From within a group, components are viewable but not directly editable. The options are: remove from group or navigate to the original article. When a user navigates there, they see the full context: which other groups reference this article, which submissions use it, its variants, and its revisions. They make an informed decision. The change propagates correctly because it is made at the source, not at the edge.
If the component being viewed is a specific variant, navigating to the article lands directly on the variant tab. The system preserves context rather than dropping the user at the root and making them find their way back.
This constraint protects users from a category of compliance error they would not know they were making.
03
The Record Lifecycle
The archive and delete logic in article management follows a system-wide principle established during submission design: anything that has entered a real workflow becomes part of the audit trail and can only be retired, never erased.
For articles, this means "delete" is only available when an article has never been used in a submission. Once an article is part of any active submission, delete is disabled, a tooltip explains why, and a dropdown shows which submissions are currently using it and their status. This gives the user the information needed to decide whether to archive now or wait, rather than hitting a dead end with no context.
Archiving is always reversible. An archived article can be unarchived if needed. Delete is permanent and therefore only available when nothing real depends on the record yet
04
The Grouping System
Groups needed to be created from multiple starting points without creating inconsistent experiences.
I designed three entry points to the same action, each handling the same edge cases differently.
From the article list: Checkboxes on each row enable bulk selection. Selecting one item surfaces a toolbar: edit, archive, export, group, revision, and add variant. Group is disabled for a single selection. Selecting a second item disables edit, revision, and add variant and enables group. The system communicates through availability: one article is not a group; two articles are where grouping begins.
From the three-dot menu on a single article: Add to Group opens a pop-up to select one or more existing groups. If no groups exist yet, the option is not disabled; instead, the popup shows "no group found" with guidance: to create your first group, select at least one other article. A list of articles appears, the user selects another, and the standard group creation flow begins. The empty state becomes an onboarding path rather than a dead end. Three options existed: remove the option entirely, and users would never discover that grouping is possible. Disable it: tooltip dead end, no clear path forward. Let them click and guide them from there; users discover the feature and immediately understand how to use it. The third option was the only one that served the user.
From the article details: The same flows: select from existing groups, or initiate creation if none exist.
In all three flows, group creation uses the same form: group name, reference number, legal manufacturer, and attributes. If a group with the same reference number, legal manufacturer, attributes, and article selection already exists, a conflict hint appears before saving, with options to view the existing group, create anyway, or cancel. The same defensive pattern used in submission conflict detection is applied consistently across the product.
05
Navigation Across Entities
Every navigation path in this system is bi-directional and context-preserving. A user moving between related entities never loses their place or has to reconstruct a relationship manually.
The most important example: when a user viewing a specific variant within a group navigates to its root article, the system lands them directly on that variant's detail view, not at the article root or at the variant list. The context they were working in travels with them.
In a system where articles can have multiple variants across multiple groups and active submissions, dropping a user at the root every time would mean constantly re-finding their place inside complex hierarchical data. The navigation preserves exactly where they came from.
The same principle applies across every entity relationship: articles to revisions, groups to components, and submissions to articles. Wherever a user navigates, the system remembers where they were.
06
What This Work Required
Article management is an information architecture problem before it is a UI problem. The hierarchy, what is a root record, what is a child, what is a reference, determined every screen structure and every navigation decision. A flat list with filtering would have been the path of least resistance.
What the product needed was a system that could represent four levels of product identity simultaneously, make their relationships explicit, enforce the right constraints invisibly, and protect users from compliance errors they would not know they were making consistently across every entry point into the same data.
None of these decisions were handed to me in a specification. The reference constraint came from asking what happens when something changes. The archive logic came from applying a system-wide principle consistently rather than designing each feature in isolation. The onboarding path in the empty state came from seeing a dead end as a design problem to solve.
07
Reflection
One decision I'd revisit: popup versus a page for article and group detail views.
I chose popups deliberately; users browsing a list of articles or groups could open a record, see its full context, and return to exactly where they were without losing their place. For a feature used frequently in the middle of other workflows, that felt right.
But as the feature moves toward implementation, new considerations emerge. A page gives more space for variants, revisions, group components, and submission history, without the constraints of a container that has to coexist with whatever is behind it. The submission detail is a page. There's an argument for consistency.
I'm designing a page version of the same logic to compare. The decision will come down to whether the context preservation a popup provides outweighs the space and detail advantages a page offers.
08
Tools
Figma, direct collaboration with product and development teams, and regulatory affairs domain research.