An existing digital platform already had users, an established codebase and a working set of features. The task was not to build something new from nothing but to add new modules into a system with its own history, conventions and constraints.

That is a different discipline from greenfield work. Every proposed feature has to be reconciled with what already exists — the data the platform already holds, the patterns users have already learnt, and the assumptions the codebase already encodes.

I worked as a Digital Product Designer, sitting between the consultants and client stakeholders who held the product vision and the IT developers who had to build against something concrete. In practice the role was as much business analysis as interface design — the modules had to be understood before they could be drawn.

This was team delivery. My contribution was the discovery and specification layer: understanding the intent, prototyping it so people could react to it, planning the modules, working through the questions developers raised, and staying with the work through testing and release.

Discovery started in the kick-off meetings and continued in conversation with the product manager. The useful questions were rarely about features — they were about intent. What is this module supposed to change about a user's day? Answering that first stops a requirement list from becoming a wish list.

From there the work was decomposition: taking a described capability and breaking it into modules with clear boundaries, each with its own data, states and rules. Boundaries drawn well at this stage are what let two modules ship independently rather than as one entangled release.

Two new application modules, specified as distinct units of functionality and integrated into the existing platform rather than bolted onto it.

The specification work continued through the build. Developers raise questions that analysis did not anticipate, and treating those as specification updates rather than side conversations is what keeps the delivered system and the agreed design the same thing.

Two kinds of testing did two different jobs. Functional testing asked whether the module did what the specification said. A/B testing asked whether the specification was the right one — a question functional testing cannot answer no matter how thorough it is.

Using A/B testing selectively also kept it credible. Testing everything produces noise and delay; testing the genuinely contested decisions produces answers people accept.

Adding to an existing product is constrained in a way greenfield work is not, and the constraint is useful. The platform's existing patterns answer a lot of design questions for free — the discipline is noticing when you are inheriting a good decision versus inheriting an old one.

Knowing that I would personally run the functional tests changed how I wrote requirements. It is very hard to write a vague acceptance criterion when you know you will be the one trying to test it.