UI foundations on a shoestring

While larger product organisations can afford to staff dedicated ‘platform’ teams full-time, smaller ones have to make do with part-time contributions.

How do you work on common tools and libraries (such as component libraries or design systems) that have a benefit outside your team? And is this really worth it when there are only one or two teams?

Development on these projects often starts out in an ad-hoc, unplanned and uncoordinated way. But it can be hard to sustain them without a clear vision. A product can suffer from stopping when tools are not yet well developed, but where decoupling them from the project involves significant work in itself.

Unfortunately, it can be hard to spot when you’re creating a weed like this until it is too late.

You could argue, with hindsight, that the wrong technical approach was taken, that the wrong technology was chosen or that the wrong level of abstraction was presented. But the real problem is usually a lack of ownership, accountability and product management.

If you do have limited resources to spend on tools and libraries, don’t just allow one or two keen individuals to ‘try it out’ in their spare time. Be clear on what the goals and expected benefits are, and manage the work like a real product, even if it is only something that is being worked on by one person for one day a month.

Start with an MVP to demonstrate the value of the work, and limit the scope and impact of the work to minimise the potential damage of taking the wrong approach.

This might add a tiny cost to the work up front, but it will be significantly cheaper in the long run if you avoid the problems caused by the entanglement of two or three half-completed efforts.

Once you have proven some value, it becomes easier to argue the case for a more dedicated effort.

Make a list of all the ‘foundational’ UI work that happens on your product. How are you currently managing it? What could you improve?

All the best,

– Jim