Balsamiq

The wireframes contract

Should founders, product managers, developers, marketers, business analysts and other stakeholders on a software team create wireframes, even if they're not trained in product design?

In organizations that don’t include a product designer the answer is an obvious YES. Someone has to do it after all.

In companies that are lucky enough to have a product designer available, we believe the answer to still be YES, as long as expectations are set properly. Wireframes are a fantastic way for people to communicate — a picture is truly worth 1000 words. But creating GOOD wireframes is very hard, it takes a professional. This can cause some friction between team members.

That’s why we created The Wireframes Contract: a set of simple ground rules that both parties agree to, which will turn a potentially frustrating process into long-lasting smooth and effective collaboration.

The Wireframes Contract

Between Product Designers and Other Stakeholders

1. Wireframes made by stakeholder

I, a Product Designer, agree to the following:

1.1.I welcome participation in the design process. If wireframes help stakeholder communicate with me, I will be happy to review them. I will not get defensive, no one is trying to tell me how to do my job.

1.2.I will not make fun of the quality of the wireframes I receive. Instead, I will give constructive feedback so that stakeholder gets better at wireframing over time.

1.3.I will remind stakeholder that I will create a new set of wireframes after reviewing theirs.

1.4.I will not let the stakeholder wireframes constrain my creative freedom. I am able to start from scratch and explore different possibilities even after seeing someone else’s ideas.

1.5.I will keep an open mind, and pay close attention to fully understand what stakeholder is trying to communicate with their wireframes.

I, a stakeholder, agree to the following:

1.1.I am fully aware that UX Design is a hard discipline, which takes years to master. I will be using wireframes to help me communicate, but I don’t pretend to be good at UX.

1.2.I will remind product designer that my wireframes are there to help me communicate the who, what and why.

1.3.I expect product designer to create a new set of wireframes, to work out the how.

1.4.My wireframes will be high-level, low-fidelity, not very detailed, and usually not interactive.

1.5.I will explain the why behind each wireframe element, ideally during a meeting with product designer.

2. Wireframes made by product designer

I, a Product Designer, agree to the following:

2.1.I will give stakeholder a first walkthrough of my wireframes, before sharing them with others.

2.2.When creating wireframes, I will be careful about not adding additional features, or at least check with stakeholder before doing so.

2.3.I will make sure to include “just the right amount of detail” at each step of the process.

I, a stakeholder, agree to the following:

2.1.I expect to see product designer’s wireframes first, to make sure all the requirements I care about were included.

2.2.I will help decide what’s in scope and what can be done later instead.

2.3.I will help decide what level of detail is needed in order to move forward.

3. Together

3.1.We will work with all the other stakeholders — business, development, design, QA, marketing, execs, etc. — to iterate on the wireframes and get them approved.

3.2.We will stay closely involved in the development process, performing acceptance tests and providing additional details as needed, such as error states, micro-interactions, etc.

1. Wireframes made by stakeholder

I, a product designer, agree to the following: