07
Action
A.Ran the early stakeholder interviews, then handed the method over
I conducted the early stage client stakeholder interviews myself, then coached the team on running them: what to ask, how to avoid leading questions that confirm a roadmap, and how to keep going until the occasional users surfaced.
That is where the finding was. The people most likely to stall an engagement were not auditors. They were HR and operations staff outside the firm who would open the product a handful of times a year and had no reason to learn it.
We built personas across two organizations. Firm side: partners who own engagement outcomes and dates, auditors who run testing and request evidence, firm admins who manage users and configuration. Client side: a client admin who owns the relationship and the response, and client members asked for specific documents and nothing else. Those personas became the product's structure, not a research artifact filed after kickoff.
B.Turned the persona split into the information architecture
Two audiences, one build. The firm sees a portfolio: clients, engagements, firm users, frameworks. The client sees only its own work: overview, engagements, company profile.
This was settled in the wireframe phase, before any visual system existed, which is why the structure held once the interface was built on top of it. The permission model resolves to four roles, firm admin, firm member, client admin and client member, surfaced as chips on the user record rather than buried in a settings tree, so access can be audited by reading a list. I directed a client impersonation capability for firm admins that shows the firm exactly what a client sees, which collapses the most common support conversation in products like this into a single click.
C.Designed the request as the unit of work
An engagement is a container. The request is where the product either moves or stalls, so it got the design attention.
One screen holds the description, target date, status, assigned users, the mapped framework and control, the comment thread with @mention, and the document dropzone. A contributor who receives a link lands on a screen stating what is wanted, when it is due, and where to drop the file. There is no navigation to learn.
Status is not binary. Custom statuses, open, under review, needs changes and completed reflect how evidence review actually works, and roll up into a percent complete readout at the client and engagement level. A partner reads a figure and a five number breakdown rather than opening records to find what is stuck.
D.Advised on accessibility as a requirement, not a review step
The firm's marketing palette was not built for a product interface. Marketing color is tuned for large type on white in a controlled layout. Product color has to survive small text, dense tables, disabled states, status chips and both themes.
I set the rule the team followed: brand color is allowed to be a surface and to carry display type, and a deeper neutral carries the persistent chrome where sustained reading happens. The sidebar uses a deep navy that clears AA for white text with substantial margin, so the navigation people look at all day is never the compromise. Status color got the same treatment. The five request states are distinguishable by position and label, not hue alone.
Because I was advising rather than sitting with the team daily, this went to them as principles with thresholds attached rather than as annotated screens, which is what let them apply it to surfaces I never reviewed.
E.Called out where the component library would not get there
The team was building on Tailwind UI. Most of the product should use it, and does. My job was to be specific about where it would not deliver the workflow, early enough that the team did not build it twice.
The named exceptions were the request status readout, the permission chip pattern on the user table, the impersonation control in the sidebar, and the comment thread with mention behavior. Each carries product specific logic that a generic component flattens. Everything else stayed stock, which is what let a four person team ship this much surface area.
F.Designed the responsive and interaction behavior
The firm's people work on laptops and large monitors. Their clients open a request link on whatever is in hand. I directed layouts across the full range rather than designing desktop first and letting small screens degrade, including a collapsible sidebar that returns horizontal space and a light and dark theme.
Alert and confirmation behavior got explicit attention because it is what tells a user their work landed. Every write produces a toast, success and failure both, including the duplicate email case on user creation. Assignment and status change events produce notifications with unread filtering.
G.Structured the data so automated evidence checking became possible
Late in the engagement the team began exploring automated document ingestion into Azure cloud services, with AI reading submitted evidence and checking it against SOC 1 and SOC 2 criteria.
That exploration was only tractable because of how the request had already been designed. A request in Lockstep is not a generic task with a file attached. It carries an explicit mapping to a framework and a specific control, and it moves through a defined status set rather than a free text field. Evidence arriving against a request is therefore already labeled with what it is supposed to prove and what state the reviewer left it in.
That is the difference between a document store and a checkable record. The structure was designed for human legibility, so a partner could read engagement health at a glance, and it turned out to be the same structure a machine needs to evaluate evidence against a criterion.
