Intapp Time — Dashboard POC

The problem

Intapp Time exists so that partners and professionals can record and submit complete accounts of the time they spend on each engagement. When it works, firms recover revenue that would otherwise evaporate as missed and under-recorded effort. When it does not, people reconstruct their week from memory on a Friday afternoon and the firm eats the difference.

We were asked to build a proof of concept for the dashboard of the legacy time-capture product. The two questions framing it:

How might we capture a legal professional’s time automatically? How might we help them keep up with their clients more efficiently?

The objectives were not only design ones. Alongside understanding daily capture needs and upgrading a dated visual layer, we needed to work out what metrics the dashboard was not showing, build a central documentation repository for brand, content, developer guidelines, and component usage — and get buy-in from product leaders to fund this as an annual initiative.

That last objective shaped everything. A proof of concept that does not persuade an executive is a portfolio piece, not a product.

Learning how lawyers actually work

I did not know what a lawyer does hour to hour, and designing time capture without that is guesswork. We ran multiple rounds of conversation and persona planning, drawing on prior research and internal subject-matter experts to validate assumptions rather than inventing a user.

User research board for the time-capture concept dashboard, synthesising interview findings and prior research. — Research synthesisValidating against existing research and internal SMEs before committing to personas. In an enterprise product the expertise usually already exists inside the company — the work is finding it and checking your assumptions against it, not restarting discovery from zero.

Three user types came out of it, and they do not want the same dashboard:

Practice Group Leader — needs the firm’s position, not their own hours.
Senior Associate — the heaviest individual capturer; lives in the daily view.
Paralegal — captures against other people’s matters, often retroactively.

Persona documentation for the proof of concept, covering practice group leader, senior associate, and paralegal. — PersonasThe useful distinction was not demographic, it was temporal — whether someone records time as it happens or reconstructs it afterwards. That split drove what belongs on a default dashboard versus what can live one level down.

Sketch, then low, then mid

We met with the technical writers to settle content strategy before layout, because on a data-dense dashboard the words are the design — a metric nobody can name is not a metric.

Hand sketches exploring content framework and layout options for the dashboard. — Content framework sketchesIndividual sketching and in-person planning. Sketching is where you find out whether a dashboard has one story or five competing ones, and it is much cheaper to find that out here.

Low-fidelity wireframes of the concept dashboard showing block-level content hierarchy. — Low fidelityShifting data around to test content hierarchy. At this fidelity the only question being asked is what earns the top of the page — and for three personas with different answers, that question was the whole project.

Three mid-fidelity dashboard iterations side by side, showing time rank, today's time, a feed of capture nudges, calendar, time reports, client and matter investments, and team member time. — Mid fidelity — three iterationsThree layouts of the same content, which is the point: the feed of capture nudges ('You spent three hours in a meeting with Coca Cola. Would you like to add this to your timesheet?') moves position in each. That element is the product's actual thesis — capture should be a confirmation, not an act of recall — so where it sits relative to the manual timer is the decision the iterations exist to settle.

What I owned

On the final deliverable I designed the fees section and the navigation bar, and collaborated with the Senior Designers on the rest of the design decisions. The work ended in a Figma prototype.

I was one of several designers on this, and the direction was shared. I would rather tell you precisely which parts were mine than imply I led a six-month enterprise initiative as an associate.

What I would tell you in an interview

The transferable part is the nudge pattern. Automatic time capture is a prediction problem with a trust layer on top: the system guesses what you were doing, and the interface has to make accepting, correcting, or rejecting that guess cheaper than typing it in yourself. Get the confirmation cost wrong and people ignore the feed and keep reconstructing Fridays.

That is the same problem shape as every AI feature I have designed since — a system producing probable answers, and an interface deciding how much work it costs a person to disagree with one.