Martin Colebourne

Any organisation that has a significant number of developers is likely to consider creating a development toolkit at some point. Toolkits are intended to make development faster, by allowing development teams to share common elements, rather than building everything from scratch. They aid overall efficiency by avoiding different teams doing the same work; allowing developers to move forward faster, focusing on the specific added value of their project.

A toolkit can also improve overall reliability and performance by focusing effort on optimising and bug fixing common elements once. In terms of the user interface, a toolkit can make the finished products more consistent in their look and feel.
In the end, these boil down to four core benefits:

• Increasing the pace of development.
• Reducing the overall cost of development.
• Increasing the quality of code.
• Improving the consistency of implementation.

While the benefits of a toolkit are clear, the best approach to creating one is not. Having seen a few of these initiatives play out, with varying degrees of success, here are my thoughts on what makes for a good toolkit.

FOCUS ON DEVELOPERS

Toolkits are for professional developers.

They are not a solution for product managers, designers, content authors, or anyone else to do ‘simple development’. A toolkit that allows you to develop apps by ‘drag and drop’ is not a toolkit. There may be valid reasons to want these groups to produce their own content without the need to involve development, but this is supported by other approaches, like Content Management Systems. Don’t mix the two.

FLEXIBLE

A good toolkit should be open and flexible. It should enable, not constrain.

It is quite possible to design your toolkit to be restrictive. The basic idea is: “let’s create a toolkit that will stop teams from doing bad development and force them to be consistent”. Whilst there is some logic to this, overall it is a bad approach. Forcing people to use a restrictive toolkit will be a constant challenge. It also stifles innovation and progress; preventing teams from the using the best solutions to maximise power and performance.

In the end, a restrictive approach suggests that, as an organisation, you don’t trust your developers. If this is the case, you need to reassess your views, hire better people if necessary and work on creating a better culture.

OWNED BY ITS USERS

A good toolkit should be the common property of all the developers who use it, rather than the jealously guarded scion of a small central team.

It is far easier to gain broad adoption of a toolkit by pull than by push. Ensuring that development teams feel a sense of ownership by contributing to the creation and development of the toolkit makes it far more likely that they will want to use it and encourage others to do the same.

At the same time, getting the whole development organisation involved leverages the skills and experience of all, rather than expecting a great toolkit to arise from the work of a small team.

This doesn’t imply that a toolkit can succeed without clear ownership. On the contrary, it makes sense to adopt an open source mindset: allow developers to contribute suggestions, patches and upgrades to improve the toolkit, but give a central group responsibility for the management of the toolkit and the ultimate decisions about its direction. The central group must maintain the respect of the entire development community, whilst making the tough decisions on the best way to keep the toolkit effective.

ENHANCING PRODUCTIVITY

A toolkit must make life easier for developers: enhancing their productivity and saving time and effort.

This seems obvious – it’s the whole point of a toolkit – but it can get lost in the push to gain other advantages, such as increased consistency. Failing to enhance productivity is a failure in itself, but as before, there is also the question of adoption: if using the toolkit introduces additional hurdles, then there will be an ongoing incentive for developers to circumvent the toolkit. A toolkit that isn’t used is doubly wasteful.

PROGRESSIVE

Creating a toolkit should be seen as a long-term, incremental process rather than a one-off big bang.

Toolkits are extremely hard to design in the abstract and the implementation of a toolkit is also likely to prove challenging in some aspects. Taking a big bang approach means asking development teams to wait for the toolkit to be ready. Inevitably, the first version will be just that: version 1.0. Early adopters will find countless issues and make lots of recommendations for improvements, whilst other teams will (with justification), proceed independently, realising that it will take time to iron out the problems and make the toolkit truly valuable. By the time you reach the genuinely useful version 3.0, several years may have passed and you are only just in a position to start encouraging mass adoption of the toolkit.

It is better to see toolkit development as a gradual, incremental process. Finding and formalising useful elements that already exist, and making these available to all. Then building new elements on top of this base. Developers should be able to use the toolkit and contribute to it from the outset, rather than asking development teams to wait until it is ‘ready’.

MODULAR

The toolkit should be modular, allowing development teams to use just those pieces that make sense for their project, rather than having to buy into a monolithic solution.

Taking a modular approach helps the process of creating the toolkit, since it can be done piece by piece as described above. It makes it easier to change direction if challenges with the toolkit are uncovered. And it can help with versioning, by allowing updates to elements to be released independently, rather than having to wait for a new version of the whole toolkit.

A modular approach also helps with adoption of the toolkit, since it reduces the barrier for entry and reduces the perceived risks of adoption.

USING STANDARD DEVELOPMENT TOOLS

The toolkit should work with standard development tools, like Visual Studio. It should not require developers to use custom tools, or specialist plug-ins that fundamentally alter their workflow.

Using standard tools allows you to hire and retain the best development talent: there will be plenty of candidates with relevant experience, who will be able to bring their skills to bear quickly. At the same time, as employees, they will recognise that they are staying up to date with the latest methods and building their knowledge and skills with relevant tools.

In contrast, using custom tools requires developers to adapt and means that they will ultimately leave with non-transferable skills, which is a disincentive to join and to stay. Going it alone also means that you are unable to leverage the insights and innovation of the rest of the industry in developing and maintaining your toolkit.

LEVERAGING EXISTING CONTROLS AND LIBRARIES

Leverage existing libraries, controls, layout tools, protocols and methods. Don’t start from scratch.

Your company is not in the business of developing toolkits. Rather than starting from scratch and doing all of the work yourself, look to the rest of the industry and leverage existing solutions as a starting point.

Finding a good base that you can build on can save a huge amount of effort. Although the core elements of toolkits look simple, they rarely are. For example, building your own basic controls is a huge waste of effort if there are good existing alternatives that could be adapted to your needs.

DESIGNED FROM THE INSIDE OUT

Look at existing controls and use their styling capabilities and behavioural options to get as close as possible to your desired state, before starting to build custom solutions.

From a design point of view, it is tempting to treat a toolkit as an opportunity to design the ‘ideal’ set of controls and UI elements. This is a mistake because these apparently simple, basic elements are actually very complex and difficult to get right. Designing and building everything from scratch is usually wholly unjustified.

Rather than starting with a blank canvas, design the toolkit from the inside out: ask how much can be done by customising existing controls and libraries. Then consider where to make strategic investments in developing custom solutions on top to get closer to your ideal design.

CONSISTENCY IS NOT A BENEFIT IN ITSELF

Prefer fitness for purpose over absolute consistency.

Toolkits can help to achieve a more consistent look and feel across different parts of a product, or family of products, by allowing teams to share style sheets, components and layout frameworks.

However, the only way to achieve a really high level of consistency is to be highly restrictive, which is a poor approach, as discussed above. However, perhaps surprisingly, this level of consistency is also undesirable from a user experience perspective.

Consistency is important for two reasons: First, a consistent visual appearance and implementation supports the perception of a quality brand. Second, ensuring that similar functions behave in a consistent way enhances usability, reduces errors and improves overall satisfaction.

However, with a restrictive toolkit, consistency can easily be pushed too far, forcing interactions that are not that similar to share the same implementation in order to reduce the size and complexity of the toolkit. This leads to design solutions that are confusing, inefficient and unpleasant. For example only providing one kind of mechanism to display and search through lists, regardless of whether the list contains 20 items or 20 million items.

Rather than aiming for absolute consistency, you should support a small range of solutions to fit different circumstances and be open to the need for custom solutions in certain circumstances; maintaining a sense of consistency by ensuring that all of the solutions share the same overall approach to colours, shapes, animations and terminology.