The prototype sprint primer

The prototype sprint kicks off every no-handoff project. Following is a quick primer on what a prototype sprint is and how it sets the stage for a no-handoff project.

The prototype is the shared language of the team. Not everyone can understand a technical spec sheet or can translate a vision statement into actionable items; everyone understands a website. Communication is easier and more democratic as it can incorporate a wider array of disciplines.

You need a front end framework that is ready to work

It is critical to have a front end framework that works for your team. If you dont have a framework ready then UI/UX will be slowed down with Long Design tasks, and will not be able to be fully immersed in Short Design flow. Essentially, UI/UX can only keep up with the fast pace of agile iterative development if a trusted framework is ready to go.

There are so many options (Bootstrap, Tailwind, Bulma, custom, and so many others) and your organization might have it’s own framework already. The only criteria is a useful grid and library of UI elements ready to go so you can quickly prototype.

Designers in no-handoff projects either learn a simple front end framework themselves, or work side-by-side with a front end developer. Copy-pasting UI patterns and learning a grid system is no more complicated than learning Sketch, Figma, or Zeplin; designers, if you havn’t already, dont be afraid of taking this step into code!

Collaborate from day 1

A prototype sprint is collaborative and merges both UI/UX and development from the earliest stages of the project. Everyone benefits from the involvement of all disciplines and, critically, it ensures code and design goals are not at cross-purposes. 

In a prototype sprint brainstorming ideas are translated into a low fidelity working prototype as quickly as possible. The prototype is written in a functional frontend html and css framework. Involving all disciplines in the creation of the prototype creates shared buy-in and lays the groundwork for communication moving ahead.

In some no-handoff projects it can make sense to generate a companion vision document concurrently. But in most of my projects the prototype is the vision. Product visions created outside of the iterative progression of the project are often relegated to the useless artifacts bin, but when the prototype itself is the vision it’s never out of step with the product direction and goals.

Start with un-design

Keep your prototypes lo-fi until functionality is determined. Do not include “design” elements, as functional discussions can be derailed by visual elements that elicit unintended visceral reactions. Stay away from color and dont even include a logo. The conversation should be continually guided towards functional criteria: content hierarchy, accessibility, usability, language, and meaning.

In fact an important goal of a successful prototype sprint is to make as few design decisions up front as possible. Like development, successful user design is fed by user feedback, so allow time for emerging project knowledge to inform the UI as well. The “fun stuff” will come but not at this early state.

The prototype is a foundation

By the end of a prototype sprint it is ready for initial testing across several fronts including general usability, accessibility, and mobile responsiveness. This is a valid and important done increment. The same prototype will continue to be built on in subsequent sprints and grow in fidelity and functionality. The prototype is not throwaway code, it’s foundational.

An early functional prototype brings to life the project vision through scale (number of pages, scope of navigation and other main UI elements), future complexity (placeholder content with useful descriptors, possibly some early functionality coded), and identifying needs (specific technologies needed, where they will be deployed, any dependencies). When working with a functional prototype its easier to become aware early on regarding tools, working environment, and code stack decisions that need to be made, and the whole team can have early input.

A prototype sprint can take as little as one day for a seasoned team with a responsive client but typically lasts about one week and no more than two. Prototype sprints move at a quick pace. If you go over that time span it may mean there are other issues at play, most commonly that you dont yet have a trusted, hard-working framework.

What’s next

The prototype sprint is a great start. In my projects our next step is to move to a dual-track workflow where UI/UX works a half or whole sprint ahead of development doing discovery and visually updating the prototype to reflect new insights. Here is my review of dual track agile for designers with more information.

The same prototype is worked on by both design and development, used directly in user testing, and is fed by ongoing user feedback. The prototype is the primary communication tool between the team and users, and within the team itself. In this way UI/UX and development maintain communication, support one another’s workflows and avoid project handoff.