Platform and Foundation
Medium or large product organisations usually have one or more ‘platform’ teams - the folk that develop and maintain common infrastructure, developer tools, build and release pipelines and so on.
These teams are important to an efficient product organisation. It’s tricky work that deals with lots of trade-offs and cross-team dependencies.
The more I worked in a setup like this, the more I grew frustrated that the user-facing aspects of the system were not formally included in ‘platform’ work. After all, the trade-offs and dependencies look very similar.
I’m not thinking so much about work like integrating JavaScript unit tests into CI or developing static asset build pipelines.
I’m talking more about the shared tools, systems and approaches to help designers and developers to do better work.
Design systems, UI component libraries, API client libraries, JavaScript utility functions, and even full application starter kits could all be considered ‘platform’ work, as they are useful or enforceable beyond a single team.
This cross-team work often starts in an ad-hoc, informal way by designers and developers who have an interest in doing it. But it can be difficult to formalise it and get the organisational commitment needed to improve it.
Part of the problem for me is in the word ‘platform’. We use it to imply server-side infrastructure and hardware, not the whole gamut of enabling tools available to a product organisation.
Marty Cagan uses the word ‘foundation’ instead. And this might be a better word for design and UI activities. It implies stable, supportive, but unseen structures that allow for creative and varied products to built around them.
Plus it sounds pretty cool if you say you work on a ‘UX Foundations’ team, right?
How does foundational design and front end work get done in your organisation?
All the best,
– Jim