An ETL tool built specifically for the Infor M3 product. I designed Datamesh, a large-scale data management and transformation platform with complex, data-heavy workflows for enterprise users — work that contributed to product maturity during the period culminating in the company’s acquisition by Infor.

An Infor M3 migration starts with a source file — in one representative project, 34,000 rows across seventeen columns. Every single column needs three separate decisions: what it maps to in the M3 target, how its values are cleaned, and which reference table resolves its codes.

Those three decisions were being made in three different places. By the time an analyst reached reference mapping they had lost sight of what they decided at the schema step, and there was no single view that could answer the only question that mattered: is this column finished and correct?

For the business, mapping accuracy was the product. A mis-mapped column does not fail loudly; it surfaces months later as broken reporting, and every failed migration is consulting time the company absorbs. Datamesh had to make mapping auditable enough to stand against incumbent ETL tooling in enterprise evaluations.

I interviewed the implementation consultants who run migrations for customers and the data analysts and owners who do the column-level work, and sat with them through live mapping sessions. Separately I ran a heuristic audit of the existing tooling and the competitor products customers compared us against, and went through support tickets and product analytics from migrations already in flight.

The tickets were the most useful source. They were not feature requests — they were people asking each other what a column meant. That reframed the brief from “make mapping faster” to “make the unresolved questions visible and answerable inside the tool”.

The mapping experience was restructured into four explicit steps, with a per-column overview acting as the audit layer across all of them. The steps are sequential but not locked — an analyst can jump back to schema without losing transformation work, because the column, not the step, holds the state.

The hard question was not what the operations were, but how to show a chain of them for seventeen columns at once. I wireframed three structures and tested each against the same 34,000-row file.

Explorations — the transformation editor

With the row model settled, the remaining work was the editor inside it: how a chain reads, where properties live, and how the preview stays visible while a rule is being written.

We ran moderated usability sessions with data analysts and implementation consultants, using their own migration files rather than sample data. Tasks were the real ones: finish mapping a column end to end, find out why a value came out wrong, and hand an unresolved column to someone else.

The sessions were where the row model earned its place — and where three things broke.

Bulk operations came late. Analysts frequently apply the same cleaning rule to several columns at once, and the column-as-row model makes that natural — we should have designed the multi-select case alongside the single case rather than after it.

Reference mapping still assumes you know your reference tables. It reads well if you do, and is opaque if you do not, which is a research gap: I spoke mostly to experienced analysts and under-sampled the consultants picking up an unfamiliar customer domain.

Enhancing the tax payment experience with a clean and minimalist UI. Finance managers were struggling to complete tax payments and get them approved: tax sections were hard to find, payment progress was uncertain, and approvals were slow and opaque.

Finance managers at mid-sized companies pay direct and indirect tax through their corporate banking portal, in cycles, against fixed statutory deadlines. In the existing portal the tax sections sat inside a generic payments menu, there was no dependable way to tell whether a payment had been submitted, scheduled, or was waiting on an approver, and approvals were chased by phone and email.

The cost of that uncertainty is asymmetric. A missed deadline means interest and penalties for the customer, and for the bank it means support load, escalations, and a real churn risk on exactly the high-value corporate relationships tax payments make sticky.

I interviewed finance managers who initiate payments and the approvers who release them, alongside stakeholder interviews with the bank’s product and operations teams. I audited the existing portal heuristically against the tax workflow end to end, and reviewed support tickets and portal analytics to find where people stopped.

The initiator and the approver turned out to want almost opposite things from the same screen. Initiators need to assemble and submit a batch; approvers need to judge and release one, fast, often on a phone between meetings. The original portal served neither, because it treated both as the same “user”.

The flow was rebuilt around triage first and a shared form shell second, so the switch between single and bulk changes the inputs and nothing else. The approval queue was separated from the payments table entirely, because it belongs to a different person doing a different job.

Three wireframes settled the dashboard: what the landing state leads with, how a row carries its own status, and how single and bulk payment share one form.

Initiate flow — bulk direct tax  /  scroll to pan

I ran moderated usability tests on the prototype with finance managers and, in separate sessions, with approvers. The tasks were the cycle in miniature: pay a single challan, submit a batch, release a batch as approver, and retrieve last month’s receipt.

Delegation is unsolved. If the named approver is on leave during a filing week, the flow has no honest answer, and I learned that late because I recruited approvers who were at their desks.

I would also push for deadline awareness in the product itself. The portal shows what is pending but not what is urgent, and the deadline is the one fact every user in this workflow already carries in their head.

Keep your design system honest — from inside the file. Undetach scans every component for live thumbnails, instance counts and deltas since your last scan, and flags detaches the moment an instance turns into a plain frame.

Detaching an instance takes one keystroke and leaves no trace. Over a few months a library quietly stops describing the product: components are duplicated, tokens are overridden with raw values, and instances become plain frames that no longer inherit anything.

The cost lands on engineering, as rework on components that were supposed to be settled, and on the maintainer, who can only find drift by opening files and looking. Existing plugins could count what was in a file but could not tell you what had changed since last week.

I interviewed designers who maintain systems for product teams and audited the plugins they already had installed. The pattern was consistent: they did not want a report, they wanted an early warning, and they would not run anything that could write to a production library without asking first.

Maintainers recognise their components visually long before they recognise the naming convention, so the scan view leads with a live thumbnail per component and treats the name as secondary. Counts sit next to the thumbnail with the delta attached, which makes a scan readable at a glance instead of row by row.

The plugin is in beta with design system maintainers running it against live libraries. The first round of feedback moved the delta from a detail inside the component row to the thing the row leads with, and added the confirm step on every write rather than one confirmation per session.

Scan history is local to the person who ran it, which is wrong for a system owned by a team. The honest next version keeps shared history and reports drift on a schedule, so the warning arrives without anyone remembering to look.