The Engineering Behind Customer Onboarding
A customer sees a form. The engineering team sees the systems that have to agree about what happens after the customer presses submit.
At Fisher Funds, from May to October 2021, I collaborated on new customer onboarding forms as an Intermediate Software Engineer. The frontend used Gatsby and TypeScript, with SCSS for styling. The work connected that customer-facing experience to MuleSoft and Salesforce services.
MuleSoft is integration software that connects applications and data. Here, that meant working across the frontend and the customer systems behind it.
I also helped mentor a junior engineer and investigated better observability tooling, including Dynatrace and Datadog. Those responsibilities share a concern: making a system understandable to the person using, building, or supporting it.
A form is a conversation between systems
Inputs, labels, validation messages, and a button look like familiar frontend work. But the form is also a boundary between a person's understanding of a question and the backend's representation of the answer.
A person should not need to understand the organisation's internal data model to become a customer. The frontend has to present questions in useful language, while the integration still has to preserve the meaning of the answers.
That is where I think form design becomes engineering design. Which fields belong together? Which values can be absent? What does an empty answer mean? When should an error appear, and what can the customer do about it? Those questions affect the UI, the types, and the service contract.
Types help explain the agreement
TypeScript helps describe the data a team expects. A type can distinguish a value the customer is still editing from the information a service requires, and make optional fields visible across the codebase.
It still needs care at runtime. A type assertion does not inspect an incoming response or turn it into valid data. The TypeScript handbook explains that assertions are removed during compilation.
For onboarding, I want explicit boundaries: what the user entered, what the frontend considers valid, what it submitted, and what the service confirmed. Those states have different meanings. Collapsing them into one success flag makes the next change harder to reason about.
The same applies to errors. An answer the customer can correct needs a different explanation from a service that cannot currently complete the request. Good error handling starts with understanding that difference, before choosing the message or styling.
Submission is part of the experience
I think of the submission state as a promise the interface makes to the customer. A spinner says work is happening. A success screen says something has been accepted. An error should say what the customer can reasonably do next.
Those messages have to match what the system knows. A useful design review asks what each response guarantees: receipt, validation, or completion? The UI should communicate the answer rather than guessing from the absence of an error.
This is also why preserving the customer's effort matters. A failed request should not casually turn a completed form back into a blank one. Recovery belongs in the design discussion alongside the happy path.
The case for observability
At Fisher Funds, I investigated and advocated for stronger observability, including tools such as Dynatrace and Datadog.
The question I want observability to answer is simple: can we explain what happened to an operation as it crossed the system?
For onboarding, useful signals could include where a request failed, which dependency was slow, and whether a failure was caused by invalid input or unavailable infrastructure. Collecting every field a customer entered would be a poor substitute for answering those questions. Diagnostic usefulness and restraint can coexist.
Tool selection comes after that discussion. A dashboard is useful when it helps someone distinguish causes and choose an action. Buying a platform cannot make those decisions for the team.
Helping another engineer see the whole system
I helped mentor a junior engineer in development practices during this role. My view of that work is that explaining the reason behind a change matters as much as suggesting the change itself.
For this kind of frontend work, useful review questions connect the layers: how is an answer represented, what does the service expect, and how will the customer recover if it fails? That gives someone a way to reason about the next form, rather than only fixing the current one.
The part of onboarding engineering I still find interesting is how much responsibility sits in an ordinary-looking screen. The interface, service contract, and operational picture all contribute to whether the experience makes sense.