Warehouse and lake in one platform, under one set of rules

What this deck shows, and what it withholds

1. 01

   Withheld

   The product name, its internal module names, and any customer or sample data. No production screenshot appears here.

2. 02

   Shown

   The structure I designed, the decisions I made and why, how I led the work, and what changed as a result.

3. 03

   Redrawn

   Where a screen carries the argument, it is reconstructed: the structure, layout and behaviour kept, the identifying content removed and every value replaced with a placeholder.

1. 01

   Retention as a product primitive

   One common approach to management, security and governance runs across everything. Retention, hold and disposition apply at application, table, record and job level, so compliance state is legible on almost every screen.

2. 02

   Cost and infrastructure choice

   The platform reduces operational cost and business risk while keeping infrastructure choice open. Storage tier is selected per application and changeable per table, so cost is a user-facing decision rather than an invoice.

3. 03

   Provable integrity

   Chain-of-custody and source-to-target validation reports let customers prove data integrity to a regulator. Audit tracking captures user actions across a four-level hierarchy.

1. 01

   Administrator: high

   System setup, users, groups, permissions, storage, licensing and jobs.

2. 02

   Developer: highest

   Configures applications and metadata, and authors the search screens everyone else consumes.

3. 03

   Retention Manager: domain-deep

   Owns retention, hold and disposition policy. Approves disposal lists.

4. 04

   Auditor: read-oriented

   Reviews system activity for organisational audit and legal purposes.

5. 05

   End User: low

   Runs pre-built searches to retrieve records. Often business, legal or support staff.

1. 01

   Requirement gathering

   Worked with Project Managers, Business Analysts, Product Owners and stakeholders to understand the goal behind each module and what users were actually trying to finish.

2. 02

   Requirement translation

   Took feature-list requirements from product owners back to the task and the role behind them, and checked each against the archiving, live-copy and analytics use cases the platform has to serve.

3. 03

   Information architecture

   Separated global destinations from application-scoped modules, and defined when a task belongs on a page, in a side panel, or in a dialog.

4. 04

   Wireframes and UI

   I owned the wireframes and final designs for archival, ingestion, rehydration, search, approvals, alerts and administration, and signed off each design before build.

5. 05

   Design system

   Built one library so dashboards, workflows and governance modules stopped inventing their own patterns, and so light and dark stayed in step.

6. 06

   Handoff and QA

   Reviewed builds against approved designs with engineering, wrote the developer spec, and raised what design walkthroughs surfaced as requirements.

7. 07

   Leadership

   Led a small UX team of one to two designers: direction, prioritisation, assigning work, reviews and critiques, mentoring, and performance discussions. Established the design-review process the team worked to.

1. 01

   What we heard

   A client needed some user groups to view search results without being able to export them. Export could only be restricted by column.

2. 02

   What I identified

   Run, background run and export shared one split button. Once export had its own permission, one control could not show what each user may do.

3. 03

   Design response

   Split the control in two: a Run menu for search and background search, and a separate Export menu that is enabled or disabled by permission.

4. 04

   UX value

   Shipped: Run and Export are separate menus, each following its own permission. Engineering extended the permission model to support it.

1. 01

   Stakeholder reviews

   Cross-functional requirement reviews with product, architecture, engineering and QA. I validated the direction and turned agreed outcomes into design.

2. 02

   Wireframes first

   I built each flow in low fidelity to settle structure, states and edge cases before any visual design.

3. 03

   Final design

   I produced the high-fidelity screens for every state a flow could reach, from empty and loading to conflict and failure.

4. 04

   A written gate

   Each requirement document named me to verify and confirm the final design before UI implementation began.

1. 01

   One hierarchy, one expression

   Application, schema, table, column are expressed the same way everywhere, so the level you are acting on is never in doubt.

2. 02

   Configuration and consumption are separated

   Search has an author surface and an audience surface. They are different interfaces with different densities.

3. 03

   Commitment is progressive

   Creation is a four-step wizard in which only the first step is mandatory. Later steps are deferrable.

4. 04

   Consequences are stated, not implied

   Destructive operations name what will be destroyed, and what survives in the audit trail.

5. 05

   Asynchronous work shares one spine

   Migration, disposal, exports, reports and restore all schedule, report and deliver through background jobs.

6. 06

   Patterns precede screens

   Review states in one module mirror another. Scheduling reuses the same shell wherever it appears.

1. 01

   Metadata columns: stated at the point of decision

   Columns can be added to a table’s metadata but never removed. The constraint is surfaced where the column is added, not discovered afterwards.

2. 02

   Protected storage: closed by sequence

   Protected-storage configuration can no longer be added or removed once a table holds ingested records. The door closes before it can be regretted.

3. 03

   Application deletion: blocked before confirm

   Blocked up front while the application holds data, with the reason shown, instead of confirming and then failing. This needed a new data flag from engineering.

4. 04

   Session rollback: a way back

   The exit that does exist. A rollback removes everything ingested in a session, for duplicate, invalid or test data.

1. 01

   Irreversibility is stated twice

   The title says it cannot be undone, and the acknowledgement repeats it at the point of commitment.

2. 02

   Destroyed and retained are separated

   A red block lists what is permanently deleted. Neutral lines below state what survives in metadata, logs and audit trails.

3. 03

   What is deleted is named

   Scheduled background jobs owned by the user, and their output, are named as permanently deleted, so the loss is known rather than discovered.

4. 04

   Search ownership must move first

   Cross-app searches owned by the user must be transferred to another user. My early wireframe allowed skipping this; the final design makes it mandatory.

5. 05

   The destructive control stays disabled

   Delete user is unavailable until the transfer is resolved and the acknowledgement is ticked.

1. 01

   Staging before production

   Data lands in staging first. Pushing it to production is a separate step that needs approval.

2. 02

   Validate before scheduling

   A field-by-field check shows whether each source field exists in the target. Missing metadata is flagged, with an action to create it.

3. 03

   Dependencies are offered

   When related tables exist, the user is asked to include them. Leaving them out needs an explicit acknowledgement that records may be orphaned.

4. 04

   Approval states the impact

   Before a production push, the approver reviews an impact summary and confirms it. A rejection requires remarks.

1. 01

   People and groups

   A stage builder mixes users and groups, with a running count of who is included in each stage.

2. 02

   Two inboxes, not one

   Requests received and requests raised are separated, so approvers and requesters each see their own queue.

3. 03

   Whose turn it is

   The review screen shows the stage path, marks the current stage as your turn, and keeps the full history in view.

4. 04

   Decisions can move back

   Besides approve and reject, a request can be sent back to an earlier stage when it needs another look.

1. 01

   Basic

   Query auto-generated from selections.

2. 02

   Advanced

   Hand-written SQL.

3. 03

   Report

   Report-oriented, formatted output.

4. 04

   Group

   A virtual folder, no query.

1. 01

   Cards: explored

   Each result as a card with its own labels and padding. Reads well with a handful of results. At two hundred rows the padding and repeated field labels turn scanning into browsing.

2. 02

   Dense grid: explored

   A tighter grid, less padding, more results per screen. Better density than cards, but still repeats every label per item and gives nowhere to put an action that applies to a selection.

3. 03

   Data table with row selection: shipped

   Columns, header labels stated once, checkbox per row. Labels appear once in the header. Values align in columns so a user scans down rather than reading across. Row selection gives export and restore somewhere to live.

1. 01

   The existing field model

   File upload joined the existing field types, and validation used the existing message feature rather than a separate one.

2. 02

   Every state is visible

   Uploading, validating, validated and failed each have their own state, shown on the field itself.

3. 03

   Conflicts are a choice

   When uploaded columns match existing ones, the user chooses to add new fields only or replace the existing ones.

4. 04

   Structure before execution

   Payload fields map to CSV columns, so a missing mandatory column stops the search before it runs.

1. 01

   Application workspace: level 2, the rail swaps on entry

   Searches · Metadata · Compliance · App config · Activity tracker. Audience: developers, end users, retention managers.

2. 02

   System management: level 1, always on the rail

   Settings · Permissions · Groups · Users · Storage · Jobs · Licensing. Audience: administrators.

3. 03

   Governance: level 1, cuts across every application

   Dashboard · Catalog · Classification · Lineage · Encryption · Protected storage · Audit. Audience: retention managers, auditors, admins.

1. 01

   Progress before detail

   A completion figure and a segmented bar carry succeeded, failed, in-progress and pending counts, so the state of every table in the session reads at a glance.

2. 02

   Failure is visible, not buried

   Table-level status sits in a persistent list, so a failed table is findable without opening every row.

3. 03

   Drill-down keeps the session in view

   Selecting a table opens set-level detail, files, records, elapsed time and status timeline, inside the session.

4. 04

   Evidence is reachable from here

   File lists, counts and validation reporting hang off the same screen, so proving the load and running it are one journey.

1. 01

   One marker, everywhere

   A single icon identifies tokenised fields in every table, result and lookup.

2. 02

   Requesting the original

   Where tokenised data appears, a fixed column provides the route to request the original values.

3. 03

   Types, explained

   Each tokenisation type is explained with what it does, when to use it, and an example.

4. 04

   Access is guarded

   Security keys have their own flow, with attempts remaining, a lockout, and a stated purpose of use.

1. 01

   Wizard with early exit

   Application creation · Search creation · Job creation · Restore

2. 02

   Job scheduling shell

   Migration · Disposal generation · Exports · Reports · Data deletion

3. 03

   One picker for people

   Approvers · Alert recipients · Grant access

4. 04

   Level-scoped action

   Ingestion · Data export · Validation reports · Retention

5. 05

   Hierarchical drill-down

   Metadata · Catalog scoring · Permissions · Governance

6. 06

   Review-state bulk workflow

   Protected-storage recommendations · Disposal lists

7. 07

   Exploration becomes a search

   Query console · Ad-hoc search

8. 08

   Empty states that teach

   Search listing suggests how to begin when nothing exists

1. 01

   Initial hypothesis

   Configure the restore in a side panel, triggered from the job card, so the user stays in context.

2. 02

   Technical discussion

   I worked the direction through with the technical team.

3. 03

   Constraint identified

   The query filter area could become lengthy, and table names and references could need significant space.

4. 04

   UX reassessment

   That volume would not fit comfortably in a side panel; constrained space would affect readability and usability.

5. 05

   Final decision

   Changed direction to a dedicated page, which scales with the information the workflow carries.

1. 01

   A score at every level

   Scores roll up from column to application, and appear across catalog views and the application dashboard.

2. 02

   A grade and a next step

   Each score carries a grade and a recommendation, such as adding tags or descriptions, so users know how to raise it.

3. 03

   The search gap

   QA found that search showed a matching application or schema, but hid everything inside it.

4. 04

   What I did

   I wrote the behaviour as user stories: matches expand to their children, matching children first. Requirements were amended and the fix verified.

1. 01

   Clearer implementation guidance for engineering through the developer spec

2. 02

   Improved implementation fidelity through design QA against approved designs

3. 03

   New capability composed from established patterns rather than designed from scratch

4. 04

   Light and dark held as modes on one component set, not two sets of screens

1. 01

   Composite patterns: genuinely had to wait

   A wizard shell, a job scheduling pattern, a review-state workflow. You cannot systematise something that has not repeated yet. These needed the product to mature first, and settling them early would have been guesswork.

2. 02

   Primitives: did not

   Spacing, control heights, states, colour roles. None of these needed the product to mature. They could have been modernised in an early release at almost no cost to the timeline.

1. 01

   A feature list is not a requirement

   Every item had to be taken back to the task and the role behind it before it could be designed. That translation was the work, not a step before the work.

2. 02

   Serving opposite expertise levels means designing two products

   Search has an author surface and an audience surface, at very different densities. Averaging them into one interface would have failed both.

3. 03

   One module has to serve every use case

   Archiving, live production copies and analytics share the same metadata, search and compliance surfaces. Designing a module for only one of them breaks the other two.

4. 04

   Structure before styling

   Deciding which level a task belongs to, and whether it belongs on a page, a panel or a dialog, settled most of the design before anything was drawn.

5. 05

   Retrofitting a system is mostly negotiation

   Drawing the components was the easy part. Bringing modules that had each settled their own spacing, control heights and states into one language meant agreeing rules across the whole product.