Thinking Out Loud

Start broad, then go deep 1

Start broad, then go deep

The currently accepted wisdom is to start with “horizontal” prototypes, followed by “verticals”.

Horizontal prototypes

Horizontals are simple mockup simulations used during the project scoping phase. They are primarily used to get an overview from the user’s perspective.

Horizontals give a broad view of the entire system, so you can concentrate on the big picture, rather than getting bound up in the details. They are best used for understanding relationships across the whole system, for demonstrating the scope, and ensuring all behaviours are covered. It is possible to develop one entire layer of the design without having to consider the “how” of the technical implementation. Issues of consistency can be noticed and addressed (similar interactions are grouped by actions or location).

A horizontal user interface prototype allows you to gather more information from customers and designers. It also allows you to confirm business requirements, define/clarify the scope of the project, and get buy-in from the key stakeholders.

Horizontals can sometimes be presented in sales demos, to get exposure in the media, or to make advance sales.

The process of building a horizontal prototype can enable good preliminary time and cost estimates, but may increase the influence of the planning fallacy.

All essential user interactions are covered, every screen and menu and function is shown in some form. Most importantly, none of the features are fully functional.
No real work can be done.

Some level of functional simulation is occasionally required, so that the prototype can be evaluated properly. For example, some dummy location data and mapping might be displayed, or pre-recorded videos play in place of a live webcam when a button is clicked. Sometimes this can turn simple horizontal prototypes into evolutionary prototypes, where the prototypes slowly transform into the final system by adding more and more functionality.

For simple projects, this may be desirable. But this approach can undermine the greatest benefit of a throw-away prototype – that the rough and simple nature of rapid throw-away prototypes allows, and in fact invites, large structural changes with very little risk or effort, before any coding takes place.

Vertical Prototypes

Verticals seek to demonstrate the complete functionality of a single feature, or a small set of features. They focus deeply on technical issues and are rarely shown to potential customers or non-technical stakeholders. Occasionally, they expose problems in a sub-system that may require changing the scope or the number of user interactions. The aim is to make sure that it’s possible to implement all the core features envisaged for the completed project. Where the product innovation is primarily a novel arrangement of common technical practices and solutions, there is less need for vertical prototyping.

Vertical prototypes are only used early in the cycle where proof-of-concept for a core feature is needed. Data processing volume testing, network sizing and latency tolerance, performance engineering, load balancing, code optimizations – identifying or solving problems “behind the scenes”.

These technical prototypes can be created in parallel with the interface, or built in advance of the user interface, or built after the interface is designed.
But they are commonly built to prove a concept, then thrown away.
If built early in the development cycle, it is not always known which platform/language will be used for the final product. Verticals generally do not allow for interactions with other features, use cut-down or dummy databases, and code is rarely optimized. Trying to re-use this code would take more time than starting fresh on the final build.

Modular Development

Where the end product is a series of modules, rather than a single system, it may be better to “start deep”.

Vertical prototyping may be the best method to use. Individual modules can be built with little regard to the ‘big picture’ as exposed by horizontal prototyping. Where the general architecture has been decided in advance (e.g. objective C on iOS) then it may be most efficient to adopt evolutionary vertical prototypes – simple operational frameworks that can be iteratively refined.

One comment

Add comment