Wireframing for Teams
This guide is intended for use by a non-designer audience wishing to learn more about the design process and how wireframes can help speed up and improve communication within development teams. The guide is also designed to be useful for design professionals, especially those who are not experienced with wireframes, mockups, or prototypes.
What is a Wireframe?
A wireframe is a skeletal framework of a web page or application program created for testing the purpose and arrangement of data on a screen.
There’s a lot of confusion in the area of terminology and sometimes you’ll hear mockups, prototypes and wireframes are thrown around interchangeably. This paper focuses on wireframes.
Wireframes - Typically low fidelity visualizations of a design with a focus on content placement.
Prototypes (Wireframes + Interaction) – Low, medium, or high visualization.
Focus on user interface and interaction.
Mockup – Medium to high fidelity visualization. Static content.
When to Wireframe
Before you jump in and start with the wireframes, you should have a solid grasp of whom you’re designing for; who’s your user? Wireframing is an early stage of the development process, and its primary purpose is to focus on function, not fashion. It’s a communication tool. For many it will be their first introduction to the product. Don’t let this scare you. Your focus is to provide the core functions and features, one page at a time.
Here are a few things we can test with wireframes:
• Look and feel
Completion of core tasks
Benefits of Wireframing for Teams
One of the greatest benefits of wireframing is the savings of development costs in the future. Being able to edit and tweak design and content before developers are involved can be substantial savings. Finding and fixing problems in the early stages is key to reducing development costs.
• Easy to share and modify
Quick to produce
Early problem solving
Determine programming requirements
Provide reference material for design
• Reduce costs by finding bugs or
glitches prior to code development
Test usability prior to code development
Wireframes Then and Now
Prior to using wireframes, our Product Leaders would work with Development team members, Business Analysts, and Subject Matter Experts to create FSDs that would detail the processes and pages within an application or web page. These documents would be data-heavy and could leave interaction and design elements open to interpretation by developers, which lead to future problems.
Using wireframes and HTML prototypes, we can now provide a link that is updatable and shareable within teams. These pages and images can be included within FSDs and shared with developers to minimize interpretation.
Hopefully, the future will allow us to create a living document as a dynamic FSD. A document that is online and always up to date, has interactive links, images and pages that will clearly communicate the application's needs.
Tips for Wireframing
• Have a clear objective. Don’t try to do too much on one page. Keep to the task at hand. Sometimes it makes sense to move features to other pages, or new pages. Keep track of these changes, but address them later.
Keep it simple. Resist the urges to add color, gradients, fonts and textures. Keep it simple and focused to the task at hand.
Size. Keep font sizes the same where possible. Typography decisions will come later in the design process.
Affordance. Keep common interactions consistent with expected behaviors.
Get Feedback. Early and often.
Accept critique. Don’t get attached to a layout or screen. Push to try new ideas. Save, Save, Save - Remember to save your versions.
Get everyone involved. Keep the initial Wireframing sessions small and focused, but once the ideas are shareable, allow other teams to respond to the designs and do their own discovery for what will be coming their way.
Remember the user. Before leaving a wireframe, play the user role and try to feel their experience.
Keep notes. Wireframing tools will have documentation areas to keep notes for documentation and interaction. Use them.
Don’t overdo it. Wireframes are a communication tool and a means to an end. Once they tell the story they need to, move on.
Who Uses Wireframes
Project Managers will compare the wireframes against the Functional Specification Documents (FSDs).
Developers will refer to wireframes for functionality and user interactions.
Designers will build off the skeletal layouts and create high fidelity versions of the pages with color, typography, images and more.
Users, or clients, will be testing the wireframes data, flow and interaction.
Tools for Wireframes
There is a large variety of wireframing tools available. Choices range from simple to advanced, static or interactive, online or desktop, and free or paid versions.
Free version is available. Good for quick, simple diagrams. Export to PNG, JPG, and other image formats.
Very popular tool for wireframing and prototypes. Online and desktop versions. No free version, but Has interactive, prototyping features.
Axure is one of the leading wireframing tools, and also known as a Rapid Prototyping tool. Can quickly produce simple wireframes, or complex interactive prototypes with documentation, notes and more.
Who to Involve (The Team)
Wireframing is not an individual effort. It takes a team to build an effective, well planned layout. Try to keep the team as small as possible without neglecting important decision makers. You’ll want to have 1 representative from each of these teams; Development, Product Leadership, Business Analyst, User Experience, and a Subject Matter Expert.
Running a Successful Wireframing Session
Wireframing can be mentally exhausting, so stay away from any all day sessions. Three hours should be more than enough to try some ideas, get feedback, and a good grasp of the content and interaction needed. The designer can work on the layout and interaction outside of the meeting and share at a later time.
The session should start with an overview of what you’d like to accomplish in this session. Then, review the concept and goal(s) of the page you’re working on. If this is an update of a previous product, or page, you should show or discuss the history of this page and explain why changes are needed. If you have a large group of 8 or more, you can split up into 2 groups and each group can take a few minutes to list out every feature and screen element they want to include. You can then bring these ideas back to the whole group and review. The rest of the session will be for organizing the content and data required.
Wireframing should be done early in the development phase or any time new changes are being added to a product that will need to modify the existing layout. Getting these concepts in front of Product Leadership, Development team, and others will help speed the approval process to move the project forward. These efforts can help save time by reducing QA testing, development changes, and future amends. If you have any questions about wireframing or to share your wireframing stories, you can reach me at email@example.com.
Figure 2: Software Engineering: A Practitioners Approach, by Roger S. Pressman.