Prototyping is at the heart of No Handoff. Following is a quick primer on how a prototype sets the stage for eliminating unnecessary handoff. Not everyone can understand a technical spec sheet or can translate a vision statement into actionable items; everyone understands a website. Prototyping from the earliest stages of a project makes communication easier and more democratic. It leapfrogs many potential issues and allows all disciplines and stakeholders (including end users) to be engaged earlier and more often.
Is your framework ready to work?
It is critical to have a front end framework that works for your team. Essentially, product work can only keep up with the fast pace of iterative development if a trusted framework is ready to go.
There are so many options, and more on the market all the time. Component frameworks include Bootstrap, Tailwind, Bulma, and more. No code design tools include Webflow, Bubble.io, Framer for Figma, and more. Your organization might have it’s own framework already. A useful grid and a library of basic UI elements will help you—to paraphrase Facebook—move quickly and learn stuff.
Designers in no-handoff projects either use no-code tools, learn to copy/paste in a simple front end framework, or work side-by-side with a front end developer. Or a combination of the three. The goal is simply that all parties contribute to the shared deliverable and source of truth.
(A note to designers: “code” is not a dirty word! There are so many ways of dipping your toe into functional prototyping, including no-code tools. Copy-pasting UI components or a grid system is no more complicated than learning Figma or Zeplin; designers, if you havn’t already, don’t be afraid of taking this step and contributing directly to prototypes. You are needed.)
Collaborate from day one
When prototyping, brainstorm ideas are translated into low fidelity working prototype as quickly as possible. This allows for early testing with users, as well as content evaluation, usability testing across devices, and measuring accessibility.
Involving all disciplines in the creation of the prototype creates shared buy-in and lays the groundwork for communication moving ahead. Prototyping is naturally collaborative and merges both product and engineering from the earliest stages, setting a pattern. Everyone benefits from the involvement of all disciplines and, critically, it ensures code and design goals are not at cross-purposes.
In some large, complex projects you will also generate companion documentation. In others the prototype is the documentation. Similarly, product visions created outside of the iterative progression of the project are often relegated to the useless artifacts bin when it comes to building it. But when the prototype itself is the vision it’s never out of step with the product direction and goals.
Start with un-design
An important goal of prototyping is to make as few design decisions up front as possible. Keep your prototypes lo-fidelity at first. Like engineering, successful design is fed by user feedback, so allow time for emerging project knowledge to inform the UI as well.
Stylistic work too soon in the project can derail the functional discussions that must come first. Stay away from color for example, and don’t even include a logo. The conversation should be continually guided towards functional criteria: content and hierarchy, accessibility, usability, flow. This is critical design, too; the time for styling will come, but not at this early state.
Mitigate risk with early testing
Rapid lo-fidelity prototyping means you will quickly be ready for initial testing across multiple fronts: content, usability, accessibility, user flow, and across devices. This is a valid and important done increment.
Thought rough, the same prototype can continue to be built on, tested, 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 early functional elements), and identifying needs (specific technologies needed, where they will be deployed, any dependencies); It forces early decisions around tools and code-stack; And user needs can be gleaned early and often through Lean UX.
Move at a quick pace. You may have something to test in one day, or one week. If you go over that time span it could mean there are other issues at play. Most commonly it is either a team’s discomfort with working in low fidelity, or that you don’t yet have a hard-working framework that allows you to rapidly mockup ideas.
The prototype is not throwaway work, it is the foundation of work to come. As it gains in fidelity the engineers will take more control over the codebase, but both front and back end will be iterated upon as more rounds of user feedback come in and project specifications firm up. At what point you stop calling it a prototype is up to you. I rather like Google’s approach of calling gmail ‘beta’ for over 20 years! Psychologically, calling it a prototype can free a team to iterate and experiment, to really listen to what the user feedback is telling you, and not be tied to the current solution.
Throughout, the prototype is the glue between all stakeholders. The same prototype is worked on by product and engineering, 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.