Prototyping

Once the problem and our solution has been validated, or perhaps to facilitate validation, we need to build a prototype.

The goal of a prototype is to be high fidelity with a potential solution, while remaining inexpensive and easy to change.

You should only build prototypes to test a hypothesis about the product. Without an idea of exactly what you are testing and why, there won’t be enough value to justify a time commitment.

Talking to potential customers is always cheaper than building software.

Skip the design docs

Separating design and development along a pure design phase and then development implementation lengthens the feedback loop.

We avoid using software like Figma, Photoshop or others unless working directly with an outside designer.

The optimal workflow is:

• HTML/CSS wireframe
• Then sprinkle some Javascript for interactivity
• Then build a backend once stakeholders agree on a good solution

The prototype will be high fidelity as its presentation will exactly match the final product, but its costs will be low as only the window dressing allows.

Stay away from no/low code options as the gradient from low to high fidelity is usually quite jagged, requiring time to move from one stage to another.

The frontend ecosystem has evolved to the point that the costs of developing a design system in code vastly out-competes designing with anything else.

Mechanical turk what you can

A mechanical turk was a prototype for an automated chess-playing machine in which a person plays inside hidden compartment as though they were the chess machine. From the outside world it looks fully automated, but inside is an actual person pulling the strings.

Amazon launched a service by the same name where you can pass out microtasks to a crowdsourced workforce which can be used for user testing, data entry, and other manual parts of a service.

This allows for a few advantages:

• Databases could be spreadsheets first.
• Data entry and emails can always start off manual.
• It’s much easier to change a human process than an automated one

By putting more effort into the presentation than the internals of the solution stakeholders can focus decisions on a user-centric perspective.

Features become easier to change and new ideas can be tested without as much effort when we focus on the user first.

Minimize the feature surface

While building a prototype we should only limit ourselves to a smaller subset of features.

Avoid building:

• Dashboards, metrics
• Admin panels
• Too many features

As with all guidelines, certain apps will feature these as their core features.

The overall rule should be to avoid features for users who are not being tested by the prototype. Even if important to the overall success of the project.