Wireframing and Vilfredo Pareto

Design informs even the simplest structure, whether of brick and steel or prose.

– E.B. White

Wireframing is a crucial planning step in the software development process that provides an early visualization of the concepts, organizational structure, and functionality to be represented. When implemented properly, wireframes help guide the development process with clear communication and a common and consistent representation of design deliverables. The focus of this article aims to provide a detailed understanding behind the benefits of wireframing using the Pareto principle.

The Pareto Principle:

The Pareto principle, or 80/20 rule, gets its name from the economist Vilfredo Pareto’s observations on Italy’s income distribution during the late 1800’s—that 80% of the land was owned by 20% of the population—and is commonly used to analogize disproportionate cause and effect relationships. However, it is important to note that when discussing the principle, proportions are not necessarily fixed, nor do they have to total to 100. In other words, the Pareto principle elaborates on how many relationships are generally lopsided in terms of their inputs and outputs, rather than being directly correlated in a 1:1 sense.

Applying the Pareto Principle:

We probably have an intimate understanding of how the number of hours spent building a new feature does not always yield a consistent productive output—especially if we experience an error to debug or get lucky and enter a state flow.

Figure 1: Pareto distribution | Source: Adapted from [1]

Azad provides an excellent visual explanation to this concept in [2]. Adopting his approach, is a time-lapse recording of an artist drawing a picture of a boy within roughly 6 minutes; think of the drawing process as a metaphor for the lifecycle of a development project.

It is interesting how after only a minute and a half--which is less than 1/3 of the time taken to completion--we already have a pretty solid understanding of what our portrait will look like.

Figure 2: Time-lapse checkpionts | Source: Adapted from [3]

The devil is in the details

Our time-lapse example demonstrates how about 30% of the time needed to complete a task yields quite a bit, if not all the necessary details in terms of visualizing the final product. Moreover, it also indirectly speaks to why the latter time spent does not produce the same type of output. As this section title notes, the devil is in the details. With many software engineering tasks, the core concepts and major details can be abstracted in a relatively straight-forward manner in the beginning (MVP), followed by a lot of refinement, refactoring, and added complexity.

Ask an economist

Given the example above, if you were an artist that needs to conjure up a portrait in the next 10 minutes for a client, how would you proceed? Would you present two completed beautiful drawings, or take a different route, like consult the client on five roughly drawn out sketches, and implement their chosen favorite?

If you chose the latter over the former, then you are most likely aquatinted with the benefits of tools like Figma.com and Draw.io. These tools make it fun and easy to ideate and stub out the basic structure of your next endeavor.

TL;DR

We are limited and bound by our resources and therefore should make intelligent tradeoffs—especially when delegating how we utilize our time. When planning your next software engineering project, remember that the final version needs all the bells, whistles, and details… but the planning stage does not.

References

[1] “Pareto distribution graph.” East London NHS Foundation Trust. qi.elft.nhs.uk/resource/pareto-charts (October 17, 2023).

[2] K. Azad. “Math and Analogies.” Math Better Explained. betterexplained.com/articles/understanding-.. (October 17, 2023).

[3] “Portrait Drawing with Graphite - Timelapse.” Proko. youtu.be/2delOXUlLRo?si=VrPbxMdhoYp0kkwq (October 17, 2023).

Hiroki Kato's Blog