A year-long implementation.
Reduced to two hours.
I redesigned HSBC Connect implementation so every step had a named owner, a clear next action and the evidence required to progress. People could work from the same implementation record instead of reconstructing progress from emails.
My contribution: product and service experience direction, end-to-end flow, task and state model, interaction design, ownership and recovery. Shared delivery: Product, Engineering and banking SMEs; bank teams retained engineering, security and compliance accountability.
Email had become
the project manager.
Finance, IT and HSBC needed to act in sequence, but calls and secure email carried much of the coordination. Status was hard to see and responsibility could get lost between teams. Five days of interviews and workshops revealed where the handoffs slowed work down.
The person responsible for the step
The action needed to progress
The prerequisite that must be ready
The result of the relevant check
Ownership and context
inside the task.
Mark assigns the secure connection to Scott, while Configure & Test remains his own responsibility. Each task shows its owner, prerequisites, latest conversation and next action, so the recipient can pick up the work without chasing an email thread.
Assigning work between stakeholders
The mobile view brings the assignment to the person responsible. Scott can see the prerequisites and Mark can pick up the next stage.
Assigning implementation responsibilities
Four responsibilities. One shared implementation record.
Mark / Assign · Scott owns the connection; Mark retains Configure & Test.
Establish secure connection
Prepare the connection in SAP and request the required authorisation.
Tom · Implementation managerMark assigned the secure connection. Documentation is ready; please complete the SAP step.
Scott · Technical leadI'll prepare the certificate and send the authorisation request.
Scott / Act · Scott sees what is required and the latest task conversation.
I put the task conversation alongside the prerequisite and assigned owner. A stakeholder can see what needs doing without searching through forwarded messages.
Mark configures the accounts
and runs the checks.
Mark reviews the accounts proposed for the connection, saves the scope for review, then generates a test file. The checks update individually, while connection verification, transaction testing and permissions remain outstanding.
Mark’s account configuration
and file testing.
Watch Mark change the proposed account scope, review the selection and run file-integrity checks. Each result is shown in the task that owns the work.
Connection testing
and recovery.
Connection setup, key exchange, connection verification, file integrity and transaction testing have separate results. The workspace shows the person responsible for the next step and the evidence still needed.
Protocol-dependent connection details
Transmission choices change the information your IT team needs to provide.
When connection verification fails
A failed connection test shows what needs correcting and which prerequisites are still valid. Scott can review the server details before running another test.
The authorisation request and connection verification are tracked separately. A failed test should retain work that has already been completed.
The test did not confirm a working connection. Review the server details and key installation before retrying.
Account scope and testing results
Account selection records the proposed scope. Permissions require review; file and transaction tests supply separate evidence before the implementation can proceed.
Which accounts should this connection cover?
Select the accounts for this connection. Review the scope before confirming it.
Verify the connection and test the file and transaction flows.
Mark / Configure · Select the proposed account scope, then review the consequences.
Readiness needs evidence.
File checks can pass while transaction testing and final authorisation remain outstanding.
Mark / Verify · Distinguish passed file checks from outstanding transaction evidence.
How implementation
progresses.
The implementation flow shows the prerequisites between setup, key exchange, verification and authorisation. Completing one task leaves the next team with a clear requirement and status.
Implementation stages shown together for context. Open the full-sized flow ↗
Decisions that made
implementation work.
Named responsibility
Evidence: the original Mark flow names the people responsible for the four stages.
Decision: each stage has a named owner and task conversation in the same workspace.
Trade-off: reassignment must remain visible when the team changes.
Prerequisites and recovery
Constraint: protocol choices, keys and connection tests have different prerequisites.
Decision: show the required information and retain completed prerequisites when a check fails.
Trade-off: the interface carries more status information, but makes the next action clearer.
File and transaction evidence
Evidence: the original screens record file and transaction tests separately.
Decision: show those results individually before presenting the implementation as ready.
Consequence: a completed form alone is insufficient evidence of a working connection.
Following security testing, compliance validation and regulatory review, HSBC ran a controlled real-world implementation. The broader process moved from up to 12 months into days; the two-hour result was achieved under optimal, staffed conditions.
My contribution was the product and service experience. Production engineering, bank infrastructure, security architecture and compliance accountability remained with the wider team.