The no-handoff prototype sprint primer

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

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. This is the shared language of the team. Not everyone can understand a spec sheet or a vision statement, while everyone understands a website. Communication is easier and more democratic as it can incorporate a wider array of disciplines. Involving all disciplines from day 1 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. Ive often experienced a product vision becoming out of date and quickly relegated to the useless artifacts bin, but when the prototype itself is the vision it’s naturally never out of step with the product direction and goals.

Un-design

During the prototype sprint the team goes straight from paper to the prototype. Visual layout programs act as a visual crutch at this stage, appearing to introduce value very quickly (because good designers make good looking things), but the real value of a high-fidelity mockup this early is very low, while the potential danger it introduces – wedding stakeholders to the wrong solutions – is high. These tools are best at high-fidelity flat mockups but the initial prototype is neither high fidelity nor flat. Whiteboard and pencil and paper let the team work through ideas quickly without being wedded to them, and democratizes the process. Then get that thinking into a functional prototype as soon as possible.

In my teams we use Fomantic UI for front end because its straightforward and makes many steps that used to be hard very easy. The right framework for your team could be the one you are using already to build websites, the widely embraced Bootstrap or a spinoff, or a minimal framework like Bulma. Every team member, including designers, should become familiar with and be able to work on the prototype directly during lo-fi phases. But if that’s not possible – or its a longer term goal and you need to move forward now – then a paired approach where a designer and developer work side by side is good. Sketches can be described by the designer and interpreted by the developer together, broadening their shared understanding of each viewpoint.

Another reason it’s critical to keep the initial prototype lo-fi and not include any “design” elements is that team buy-in can be derailed by irrelevant visual elements that elicit unintended visceral reactions. We stay away from color and dont even include the client logo (instead use a blank space or a light gray box as a placeholder). The conversation must be continually guided towards functional criteria like content hierarchy, accessibility, usability, language, and meaning. Reassure the team that the “fun stuff” will come but not at this early state.

In fact an important goal of a successful prototype sprint is to make as few design decisions up front as possible. Successful design is fed by user experience, so allow time for emerging project knowledge to inform the UI.

Test early and often

One of the most important tenets of agile development is to test early, often, and iteratively. In a prototype sprint planning happens concurrently with doing, by the end of the first sprint the prototype is ready for initial testing across several fronts including general usability, accessibility, and mobile responsiveness. On my teams this is a valid and important done increment.

The prototype sprint also produces an initial, validated product backlog. As backlog items get completed in future sprints the prototype gains in fidelity. The prototype is not throwaway code, it’s foundational.

Some common issues

  • Embrace the value of low fidelity and avoid emphasis on the visuals. Be vigilant about this point as stakeholders who are new to this approach might need help and reassurance as they move beyond “where’s our logo” and focus on deeper questions of functionality and hierarchy.  
  • A different facet of the above, also be vigilant about not getting attached to your own design ideas. It’s helpful to remember during prototype sprints that nothing precious is being generated and to remain detached from the end results. That’s yet another reason to keep the prototype minimal and, frankly, rather ugly. It serves the purpose of keeping all team members detached. 
  • Early process buy-in from executive leadership is critical. Your client, your development team, your boss, their boss, all need to support and nurture the process with their engagement, creativity, and time. Don’t be a lone cheerleader, the whole team needs to wave their pom-poms! 
  • Poor communication is ofcourse the Achilles heel of all teamwork. The prototype sprint won’t solve persistent communication issues but it will bring them to the fore sooner as the entire team dives into a collaborative workflow almost immediately. Any already existing communication issues will come up early and often in a prototype sprint as you work towards consensus and your first done increment. Embrace the opportunity for improving communication and engage the whole team in finding solutions. 
  • Pick the right front end framework. If you dont have one already you might need to try out various front end frameworks before you find one that clicks with your team’s workflow. I recommend looking into minimal frameworks like Fomantic or Bulma and not getting bogged down by bells and whistles. However, the right framework is always the one that works for your team.
  • The UI/UX team needs to develop a comfort level with and access to the front end framework. Ideally they will work directly on the prototype, avoiding unnecessary handoff and the need for translation from one medium to another (ie: from Sketch to the prototype). If your front end team do not have familiarity with css and html then a paired approach, with one designer and one programmer working together on the framework, also works well. 
  • And remember that you’ll get better and faster as a team! Running a productive prototype sprint is a skill that grows with practice.

When is the prototype sprint complete

The sprint is complete when the prototype and accompanying artifacts are approved by the full team (including the client), and the prototype is deemed ready for initial usability and accessibility testing.

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). Decisions regarding tools, working environment, and code stack will be made with the input of the entire team.

Reaching this done increment 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 weeks. Prototype sprints should move at a quick pace and going over the two week time frame can be a red flag. It may mean there are other issues at play.

What’s next

The prototype sprint is a great start to any scrum process but 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.

In a dual-track process prototype organically develops, fed by UX research and emerging functional needs. UI/UX and development support one another’s workflows and avoid project handoff.

The guiding vision that results from a prototype sprint wont be perfect and will likely change as more is learned, but the recognition that we know less at the beginning than at any other phase of a project is at the heart of the agile workflow. When we apply this same philosophy to the emergence of the project vision and design through a prototype sprint what results is an actionable done increment, genuinely useful artifacts, shared buy-in, and a pattern of teamwork and collaboration that can be sustained throughout the project.

A prototype sprint is a practical way to address the need for guiding vision that agile requires while simultaneously laying the groundwork for stronger agile collaboration during future sprints.