Working a queue used to mean repeated round trips: open one, lose the list, go back, find your row. I designed peek view so the request opens over the queue, and closing it leaves you exactly where you were. Two details make it hold up: a link inside a peek opens another peek, so a chain of records unwinds back to the queue. Expand promotes the peek to a full page without a second navigation. It is a preference, always or on demand.

What I dropped. One exploration folded the list into a card column beside the record. It was a second way to do the same job, so I kept one model.

Over the listA card column

To see where the open requests sat, a manager used to build a report. The tree view I designed splits any list by any field, with a count on every node, and any node opens as a filtered list. I put it in the list's own toolbar, beside kanban and graph, because it is a way of looking at the list you already have, not a report to build.

Try it · press the tree icon on the toolbar, then open a branch.

ListTemplateKanbanGraphTree

Within the team's new sidebar, I reorganised Setup around the tasks admins perform. The ordering changed: Zia from 14th to 4th, Mail Settings from 3rd to 16th, the last. A guide line shows where you are in the tree, and sub-pages that hid in tabs became branches you can see. Every Setup page also answers what is configured for this module, through an icon beside the module picker.

Old SetupNew SetupThe module iconAll of one module

I led the Ask Zia pane so the assistant can remain beside the current page. The available skills follow the context: Approaching SLA on Requests, Stalled Problems on Home.

The trade-off is a narrower surface and context-specific skills to maintain. The AI case study shows the pane and the feedback path on an answer, followed by my Agent Actions configuration work.

I contributed to the surrounding navigation, workspace and custom-page work. The examples below show that team context; the four sections above are the areas I led.

Workspaces and the wider team redesign

The team's workspace design lets a module open on a workspace instead of a list: a page that answers the module's first question before the list. Home shows what is overdue, pending and waiting on the person signed in; for other modules, customers build their own in Setup, Custom Pages. On the demo account, 13 modules open on one, from 21 custom pages in all.

Launch page footage · plays on click

The launch feedback records interest in the redesign. I would evaluate it through switch-back behaviour, peek expansion, list-view use and finding settings. No usage data is available to me.

Try it · ask a question, leave one person silent, then advance the days.

The reconstruction checks this rule. A test of this reconstruction enumerates the defined input sequences up to six steps in a two-person model, then checks reachable states in the twelve-person model to depth seven. Approval must require an explicit Approve; planted automatic-approval branches make the check fail.

The banner and the threadResponse Status

Real approvals raise more than one question. Threads are numbered by level and each level has its own status; an answered question says so in green, with who resolved it and when. While a question is being edited the approval cannot move. When the question moves to someone else, the first person is told on the portal, before they waste time answering it.

Two levelsThe requesterThe rule for silence

Every round started as a requirement from the product manager. I worked it into shape in design, with a developer in the room early to say what the approval framework could support. The timeout has two outcomes for a reason. A change that goes ahead on missing information is the expensive mistake; an automatic reject only costs the requester a resubmission. Teams that prefer patience let the approval wait again. After each build I checked the screens at desktop, tablet and phone widths and marked what drifted.

What I reversed. Between the January and July 2024 rounds I narrowed the scope. Clarification events moved out of Approval History into Change History. The approval record holds only status changes, so an auditor sees who decided what and when, and the conversation stays with the change it was about. A block of reminder and notification settings came out, and so did the Mark as Resolved confirmations. The requester's widget became “My Pending Clarification”. For approvals on modules customers build, the panel kept only Approve and Reject, with the details read‑only.

Approvals taught me the rule that runs through the rest: when the product cannot decide on its own, it should name the state, show who is waiting on whom, and decide what silence means. I carried it into how changes are governed, from freeze windows in 2018 to the CAB Workbench in 2026. Release builds for this work are not recorded.

Freeze windows, 2018 to 2025Conflicts, 2025CAB Workbench, 2026

Zia also infers Pending Clarification from an approver's email asking for information. See the Zia story.

I wrote a colour-difference tool to compare production values with a proposed ramp using CIEDE2000, alongside contrast ratios. The recorded run matched colours in order using a difference threshold of 2; it was not a global nearest-colour optimisation. It absorbed 199 of 453 greys into a 14‑step ramp. The remaining values identified where additional ramps needed design. The threshold was a screening rule, not a guarantee that every substitution would look identical.

The tool's tableOriginal specification

The design system came after the new UI was built, not before, and that was a decision. The goal was to ship a refreshed UI fast, so the team settled how it looks on real screens first instead of building a system up front. Working back made the system a consolidation of existing decisions, while leaving drift to identify and correct. I worked it back from what had been built; the old UI had only an SDP UI kit.

The audit. In August 2026 I audited the SDP library in Harmony against the lab build. The pages named Component held spec sheets rather than reusable components; 20 publishable symbols existed elsewhere in the file. A separate 20 August paint audit found 52% of 1,563 component paints unbound to tokens.

Library census, 1 October 2026. The library contains eight foundation sections (colour, type, spacing, effects, motion, z-index, iconography, layout), 70 publishable components (290 with variants), 907 product icons and 321 illustrations, and 1,052 variables. The pages a designer builds with are split from the internal audit pages, so the library shows only what you build with. The other SDP designers now build from it.

One-screen comparison. I pushed a coded Requests screen into Figma as library instances: 103 per frame, with a pixel difference of 0.67% in light mode and 1.22% in dark. I sent the review's library findings to the library owners.

This site runs on the system's token file. Open Preferences in the nav: dark changes 466 of 699 tokens, darker 484, an accent 22 and its focus ring; measured by the build in the token file I generated from the Harmony library. Those counts describe the generated CSS, not the 1,052 Figma variables; the two are never one figure.

FoundationsLibraryMotion

Inspect the one-screen browser-to-Figma comparison

Lab buildPushed to FigmaPixel diff

Earlier UI kit and icon work

I put the ramps into UI Kit 3.0 and the first SDP design system beta: components, icon sets for light and dark, and the spec developers built from.

Contrast in the palette helps everyone; some people need more. I designed Accessibility Controls for Preferences, organised by need rather than by setting: Vision, Hearing and Mobility, with increased contrast, a reading mask, a focus ring, underlined links and display font size. Ten persona presets switch on a set at once, and each control maps to a WCAG success criterion. They carried into the new Cloud UI unchanged in 2026.

The design, 2024In the new Cloud UI

I rebuilt the UI as a working replica so I could measure rendered pages across themes. The replica contains 73 pages; 60 entered the contrast sweep and 21 were compared with the lab build.

The contrast sweep traced 388 of 415 failures to ten text colours. I separated kit colours I could change from product colours to report to the team. Fixing a shared colour still requires checking the affected screens; the count is not a claim that the product became compliant.

The verification case study shows the check that passed with most pages unmeasured, how I repaired it, and what it then found.

Try it here. Open Inspect colours on a story prototype, select an element, then change the theme. The card shows the token values and contrast measured in this reconstruction.

The brief was to let an admin define what to watch, group similar incidents, and act when a group grows too quickly. I worked from the product wireframe through iterations of the configuration and cluster screens, then reviewed the built product at desktop, tablet and phone widths.

The admin chooses the incident conditions, the fields to compare, and a threshold within a time window. The technician sees the resulting clusters, the requests inside each one, and the rule behind the grouping.

Try it · watch incidents group by their rule.

What shipped. Several analyses, AI-written names with a choice of provider, linking requests, associating a problem, and notifications. Announcements, creating a problem, major-incident escalation and anomaly detection were designed beyond this release.

Follow the design rounds and build review

1. Wireframefrom product
2. 1 Dec 2025Round 1: model cards, the analysis form
3. 8 DecOne switch, AI provider, AI limited to naming
4. 8 to 18 DecClusters explain themselves; full storyboard
5. 24 Dec to 9 JanReview of the build, desktop to phone
6. Jan to FebRelease fixes
7. 12 Mar 2026Shipped as Cluster Analysis

The next task was delegation inside automation. Under Custom Actions, an admin creates an Agent Action that a business rule can run on a request. My work here is the action configuration flow, built on the team's Zia Agents platform.

The execution boundary. The supporting agent configuration distinguishes a user's identity from a shared-admin identity. Automation uses a shared-admin connection. Saving an action configures future execution; it does not ask a person to approve every subsequent run.

Inspect the original Context Assist and identity controls

The retained enhancement file shows both decisions: replace or append the context draft, and distinguish Ask Zia's user identity from automation's shared-admin connection. These are original design controls, separate from the reconstruction below.

Context AssistAgent identity

Try it · choose an agent, draft its context, map its inputs, then save and select it for a rule.

Generated content enters an existing workflow. The important choices are which information it uses, what the person can change, and when the result becomes part of the record.

Resolution sourceWorkflow briefSmart collaboration

A related checklist flow distinguishes adding generated items from replacing existing items, with a warning before replacement. The review step belongs at the point where existing work changes.

I led the Ask Zia pane in the new UI, moving the assistant from a separate destination to a surface beside the current page. Its available skills change with the page: Approaching SLA on Requests, for example, and Stalled Problems on Home.

On RequestsOn Home

Give an unsatisfactory answer a response path. The feedback designs pair Like with Dislike, then offer Irrelevant, Incorrect, Incomplete or Other and a comment. Designed November 2025 to February 2026; the widget shipped September 2026. The interaction captures feedback; it does not establish what happens to that feedback later.

Try it · dislike the answer, choose a reason, and submit.

The same questions appeared before agents: how to show prediction quality, make an inferred action inspectable, and provide an outcome when the model cannot answer.

Prediction settings and auditable approval replies

The 2020 settings showed accuracy per prediction, individual switches and training time. The 2023 approval audit paired the original sentence with the inferred action and included Unable to Predict as an outcome.

20202023Prediction history

The retained designs put a brief before Draw Workflow. It names the lifecycle and stages the model proposes to create, then lets the person review and edit them.

The brief, designedLab build, October 2026

Release evidence. ManageEngine lists Workflow Assist in its 10 September 2025 Cloud release notes, with wider availability on 1 July 2026. That establishes the capability's release, not which retained brief-design revision shipped.

I redesigned email configuration for custom-module approvals around one row with a module picker. The first round had separate layouts for no custom modules, one and many. The approval loop follows the model in the approvals case.

Round 1 · no modulesRound 1 · oneRound 1 · manyRound 2 · any count

I changed the editor choice from broad Basic and Advanced labels to the editing method and skills involved. The earlier draft offered predefined widgets and themes, or Zoho Creator customisation. The later design distinguished templates requiring minimal HTML from drag and drop without coding. The drafts show the design change; the exact shipped revision is not mapped.

Earlier draftLater draft

Many versions of the on-premise dashboard, around one idea: the customer, not the product, decides what is on it. A widget can be ours or an external page added by name and address; a dashboard can be private, public or shared with chosen roles, or marked as an executive dashboard.

I contributed to the team's custom-page work. 10 of 78 written launch answers asked for custom or landing pages. This records interest in the team's capability, not adoption.

The new Cloud UI takes it furthest: a module can open on a configured page, assembled from custom widgets, for technicians and requesters separately. In the demo, 13 modules open on one of 21 pages. These are demonstration counts.

Setup, Custom PagesA page on the demo account

A check reported success while it had nothing to compare on 69 of 73 pages. Repairing the coverage exposed 124 defects on 29 pages. The lesson was to distinguish a completed measurement from a completed process: a process can exit successfully without inspecting the intended target.

I changed the checking method so a deliberate defect must trigger the relevant failure. This portfolio uses the same principle for its own gates; the colophon explains what they cover.

I built a static, working replica: 73 pages with list, detail and create views, Setup, three themes, six accents, phone and tablet widths. My working loop was to read the live build, write a dated note, rebuild and check in all three themes. The correction log runs to 262 dated entries and keeps its own mistakes on purpose.

The sweep covered 60 replica pages in three themes. Of 415 text contrast failures, 388 came from ten text colours. That narrowed where to investigate; every shared correction still needed a check of the affected pages.

I separated changes to my kit from colours that matched the product and needed to be reported to its team. The foundations case study explains that boundary and the reusable colour decisions.

Most features begin with a product manager bringing what customers asked for. We work out the shape together, with a developer in the room early to say what the framework can return. On the Cloud team a UX researcher takes the requirement apart before anything is drawn.

I became a senior product designer in 2022 and joined the small Cloud design team in 2024. I am a Certified Usability Analyst (HFI CUA).

I wrote the feature decks for the 2023 user conference and gave the design team a talk on accessibility in 2025. On 29 July 2026 I ran a two-hour seminar on agentic AI for 150 students and 4 faculty at an engineering college: next-token prediction, why models invent answers, retrieval with citations, tool calls and agents. It included a from-scratch retrieval demo. The linked portfolio edition revises the explanations and examples, adds primary references, and offers slides or a reading view with speaker notes. It is not a verbatim record of the session.

Four product contexts: ServiceDesk Plus, AssetExplorer, FacilityDesk, and embedded experiences such as AssetExplorer inside Zendesk and Microsoft Teams inside the ServiceDesk Plus ticket. I work in Figma and FigJam, with earlier work in XD and Axure. I use Python for measurement tools and AI coding assistants for prototypes and checks. The colour comparison tool, Figma library and portfolio demonstrations show that work in context.

The engine that built the previous version: one static HTML file for every route, a small script, no dependencies. On top of it, this round's layer: a theme and accent state on the document, a shelf that frames every prototype, a ledger that explains marked headline figures, and Preferences in the nav.

Every prototype takes its colours from one generated file. In Darker the rest of the page does too, and so does every accent except maroon, which stays the site's own. I built the SDP design system in Harmony, the company's Figma design system, and exported its token file; a build step keeps only the names this site's CSS uses and writes a copy into the page. The counts Preferences prints, 699 tokens in the root, 466 changed by dark, 484 by darker and 22 by an accent, plus its focus ring, are computed from that file at build time, never typed.

The prototypes are the portfolio's own builds on those tokens: peek view, the view switcher, the approval, the agent action and the feedback tile. Sample data, sample personas, Public Sans rather than the product's font, and none of it is the product's code. The homepage uses a still from the Cluster Analysis design. Project previews use the source screens, with titles rendered as page text. The Cloud story retains its before-and-after clips and optional launch footage. Product footage comes from demo accounts; design screens are labelled separately. Screenshots and recordings retain their source colours in every display theme. Preferences change the page and the interactive examples.

The page is written only when every gate passes. A string gate reads the finished page, entities decoded, against the configured list of names, internal hosts, demo tenants, request identifiers and throwaway prototype values. A separate browser run checks selected routes, widths and themes; its OCR pass reads the resulting captures and referenced images against the same list. Coverage is recorded with each run. An asset gate checks that local references exist; packaging then collects the required files.

The ledger check reads headline figures in the configured facts, results and shipped strips and fails if a required claim is missing or an id has no row. The figure links to a record containing its baseline, method, caveat, source, period and permission. The gate checks required links, not the figure's meaning or source accuracy.

Two fixtures are planted on purpose: a prototype row carrying a colleague's name, and a facts strip figure with no ledger id. The self-test builds each in turn and asserts that the build fails, then runs the clean build and asserts that it passes. The planted defects are counted from the fixture files, so that figure is computed too. There is also a weight budget: the home page must paint under 1.5 MB before anything is clicked, measured in a fresh browser profile on every shoot.

Usage data for the new UI, the Ask Zia feedback widget and Cluster Analysis was not available to me when I asked on 13 October 2026. Delivery dates, design observations and replica checks do not establish customer outcomes. The cases retain "Not measured yet" cards naming the missing measures and what an evaluation would need.

"Reused" never becomes "adopted". A decision table that links to another step means I carried the same model there; nothing totals those links.

The token counts describe the generated CSS, not the 1,052 Figma variables in the 1 October 2026 census; the two are different measurements. The 388 of 415 contrast sweep ran on 60 pages of my working replica of the new UI, not on the product, and the replica itself is not packaged here: not its shell, not a view, not its CSS.

The marks say where a figure came from: a filled dot is shipped, with a release note or build number; a ring is design evidence, with release status stated in the case; a square is measured on my own artefact, a replica or a library. A design file alone does not establish whether its revision shipped. Figures with no mark carry only their card. The legend on About switches each kind off.

The token file was generated with an AI pair, and consuming it here found what reading it would not. Four easing tokens were emitted without commas, as cubic-bezier(0.4 0 0.2 1), which a browser ignores; the build adds the commas in its copy and the source is untouched and reported. A draft of the Preferences counter wrote the per-accent change as 23; the block holds 22 and the focus ring is declared elsewhere, which is why the counts are computed.

The two build fixtures check specific failure paths. They do not validate every gate or establish complete accessibility. The reason for testing coverage is a check that once read green while measuring too little, told in the verification story.

Developed with Claude Code and Codex as AI engineering and editorial assistants. The case studies distinguish my product design contribution from team work; the portfolio prototypes are reconstructions, and their limits are stated beside them. Type: Fraunces, Public Sans and IBM Plex Mono. The page's neutrals are the 14‑step grey ramp from the colour story.

The bundle contains the portfolio's own code. Interactive examples use illustrative records and personas; screenshots document historical designs and lab builds. The checks above describe what was inspected and the limits of that evidence.