SYNECHRONSE561Process intelligence for banks, and an AI skill for the whole firm
An 8-week enterprise internship in two seats: designing a process intelligence platform for banking, and writing a spec development skill used by engineers across the firm.
- Role
- UI/UX Product Design Intern · AI Engineer
- Timeline
- Summer 2026 · 8 weeks
- Skills
- Enterprise UX · UX research · prototyping · motion · spec writing
- Tools
- Figma · Claude Design · Figma Agents · Figma Motion
In one project I used AI to help me design.
In the other I flipped seats, and built the thing that helps engineers work with AI.
Synechron is a digital consulting firm specializing in financial services. Its pitch to banks runs through FinLabs, a collection of frameworks the firm implements inside client organizations. My summer sat inside that motion: one product to design, one framework to ship.
Process intelligence for a bank that cannot tell you what its own processes are.
Problem
A bank runs thousands of processes a day, and no one can say what they actually are.
Those processes run across hundreds of systems that do not talk to each other, and every one of them exists in variations that keep changing by country, by regulation, by team.
Documenting them today means asking people to write down what they remember. At bank scale, that is thousands of people.
Card fraud dispute
One process, 3 shapes
- Intake
- Provisional credit
- Investigate
- Resolve
- Notify
- Intake
- Investigate
- Resolve
- Notify
- File report
- Intake
- Refund by T+1
- Investigate
- SCA check
- Resolve
- Notify
Dozens more variations sit below this, per team and per exception. And every one of them keeps changing after you write it down.
How might we automate documenting processes across disconnected systems, when every one of them is a variation and none of them stay still?
Solution
Read the event logs the systems already write, and never touch the data.
Every system already writes an event log, and the Case ID inside it stays constant. So instead of asking anyone, the platform connects read-only, reads Case ID plus timestamp plus event, and stitches the real path of a case back together.
What each system already writes
Customer service
- CASE-8821309:14Dispute opened
- CASE-8821309:22Card frozen
Fraud investigation
- CASE-8821311:05Assigned to analyst
Compliance
- CASE-8821316:40Reg E clock started
One reconstructed path
- CASE-8821309:14Dispute openedCustomer service
- CASE-8821309:22Card frozenCustomer service
- CASE-8821311:05Assigned to analystFraud investigation
- CASE-8821316:40Reg E clock startedCompliance
The Case ID is the constant. Time and event do the rest. Nobody was asked to remember anything.
Where it stops, on purpose
When the output is evidence for a regulator, a person makes the call, not a black box. The platform produces bottleneck reports, control gaps and audit packages, and humans act on them.
It documents and flags. It never executes.
Three flows
Three screens carry the whole story.
Dashboard
Systems onboarded, processes mined, variations detected. Case ID matches below 85% get flagged, which is the platform raising its hand for a human.
Onboarding
Eight steps to connect a system, with a real access control gate. The system owner approves before any data moves, and it is not a rubber stamp.
Process map
The case as one reconstructed timeline instead of five disconnected logs. Where the thread broke, the break is flagged on the map, not buried in a footnote.
How I worked
I didn't know what process intelligence was in week one, so the order of work mattered.
- learn the domain
- competitive analysis
- task journeys
- personas
- platform goals
- design the platform
- iterate
You cannot define goals before you know who you are building for.
The competitive map
Celonis and IBM sell to any industry. Pega and Appian automate processes you already understand. Nobody was building for one specific client type, a bank, and for the processes nobody has mapped yet.
Iterations
Two features got rebuilt, and neither final version was the prettiest one.
The process map and the variations view are the two screens the platform is judged on, so they took the most rework.
The process map
From a viewer you look at, to a tool you work in.
The step editor covered the workspace.
- kept
- The flowchart elements were right, so those carried through untouched.
- broke
- Opening a step buried the map behind it, there were too many buttons competing on one screen, and the variation switcher got overlooked entirely.
A simpler, cleaner screen, which is what users preferred.
- kept
- The editor docked into the rail so the map stays visible, and the variation switcher moved to the top where people actually found it.
- why
- Inside the panel, editable attributes now sit above read-only mined data and read-only controls. In a tool whose output becomes evidence, seeing what you cannot change is the point.
Variations
From one at a time, to all of them at once.
The heat map idea was right, the framing was not.
- kept
- Reading coverage as a colour grid worked, so that idea survived into the final version.
- broke
- It only showed one jurisdiction at a time, so comparing meant clicking through them, and the matrix underneath was small and secondary.
All three combined into one visual.
- kept
- Easy to see the detail and compare across jurisdictions at the same time, without losing either.
- why
- It also carries just enough detail that the separate process map view became redundant, which is how I knew it was the right one.
The fine print
This was scoped as a front-end prototype to be used in sales pitches to clients, so there were no end users in the loop. The feedback cycle ran through my manager, domain research and competitive benchmarks instead.
Branding stayed deliberately minimal, because client branding would overwrite it anyway. Naming that scope is part of the work.
A spec development skill that now lives in Synechron's enterprise repo.
The ask
This one wasn't assigned. I went and asked for it.
I went to leadership on the AI side and asked where else I could learn and be useful, because I was curious and wanted more than my lane. They threw ten directions at me.
We landed on spec-driven development.
A spec is a specification, a written description of a change that says what to build, why it matters, what counts as done, and what was considered and rejected. Engineers write them before they write code, and an AI coding agent needs one to build reliably.
The thing I made is not a spec. It is a skill, a set of instructions that teaches an AI agent how to produce a good spec from whatever someone has already written down.
The call
Parse the spec out of messy notes rather than prompting people through a form.
Option A, rejected
Prompt people through a rigid Q&A
Forcing a form on someone before they have thought out loud produces box-checking answers.
Option B, chosen
Parse structure out of what they already wrote
Let them dump messy notes, then extract the spec from that.
Shipping it
It passed enterprise GitHub on attempt four, on my first real Git workflow.
I took Anthropic's courses on the domain, drafted the skill with Claude, and benchmarked it against existing specs. Then two rounds against real projects: feedback, changes, retest.
What someone actually writes
- “need a way for users to bulk export the audit package”
- “right now they screenshot everything, takes forever”
- “maybe csv? or pdf. compliance said pdf”
- “don’t let them export if the case is still open”
What the agent can build from
- 01Whatthe change, in one sentence
- 02Whythe user problem behind it
- 03Acceptance criteriahow you know it is done
- 04Testswhat has to pass
- 05Alternativeswhat was considered and dropped
Enterprise GitHub, the part nobody warns you about
Contribution guidelines, automated review, formatting gates, on my first-ever real Git workflow. It passed on attempt four.
The skill now lives in Synechron's enterprise repo, used by engineers across the firm.
Takeaways
This summer needed a designer, a PM, and a little bit of a developer in the same seat. The design work was the visible half. The skill sitting in the enterprise repo is the half other people are still using. Ship where the leverage is, even when it is not in Figma.
Config 2026 shipped motion, code layers and agents, and I was using them in my workflow within the week. In a field moving this fast, knowing what just became possible is a design skill, not a side interest.
The skill exists because I went and asked for it. Nobody assigned it, and nobody would have.
This is the short version
Every section here has more behind it: the research, the iterations, the dead ends. If you are interested in the long version, let's get in touch.
Next flight
An AI copilot for cost segregation engineers
BASISBK165
