How to Use Wireframes to Communicate with Users!

Howdy, Upstarts!

Wireframes are an excellent tool that can help you to write code cheaply and quickly, but only when they are used properly. In my experience, many software development teams don't use wireframes as efficiently as they could. So in this series of articles, I will take a deep dive into the way that Product Teams and Development Teams use wireframes and explain how to use wireframes to improve software development processes.

In the previous article of this series, I outlined a process for the Product Team Handoff that can be used to improve your software development process and help your team write code cheaply and quickly.

The process that I use for the Product Team Handoff with my software development teams is designed to transform wireframes into a robust specification that my Back End Teams and Front End Teams can use to work in parallel and to minimize the amount of re-work and debugging. This makes my software development process cheap and quick while consistently delivering high-quality code.

The goal of the Product Team Handoff Process to produce a Technical Specification that enables your development teams to work quickly and with confidence.

This process focuses on using wireframes to drive technical requirements. After the Product Team has completed a set of wireframes, they can quickly perform this Product Team Handoff Process with the Development Team. That means that as soon as the Product Team has a new set of wireframes, the Development Team can review them and begin the development process.

The first step of this Product Team Handoff Process is the Show and Tell Exercise. When the Product Team has finished a new set of wireframes, then the Product Team and Development Team perform this exercise and produce a list of information that the wireframe should show to the User and a list of commands that the wireframe should tell to the Product. These lists will then be used to write a set of clear Technical Requirements.

But the first step in mastering how to use wireframes is to perform this Show and Tell Exercise.

Let me explain!

UI is a Game of Telephone

The User Interface of any Product is used to communicate between the User and the Product, so the User Interface is a two-way communication channel.

The best way to imagine a User Interface is a Telephone. A Telephone is a two-way communication channel between two people, and so a Telephone needs a way to let users hear messages, the speaker, and a way to let users send messages, the microphone. So a Telephone has two pieces: the first piece of a telephone enables communication to the user and the second piece of a telephone enables communication form the user. The User Interface of a Product serves the same purpose!

So, the first step of the Product Team Handoff is to use wireframes to understand what the User Interface is showing the user and what the User Interface is telling the product.

What do the Wireframes Show the User?

The first part of the Show and Tell Exercise is to understand what the Wireframes Show the User. Just like the telephone’s speaker, a wireframe should communicate information to the user from the product; so, you must identify what information the Wireframe is showing the User.

The best way to do this is to review the Wireframe and circle each widget or the field that contains information specific to the user. Then use this information to create a list of information that the wireframe must show to a user.

For example, an email field communicates the user’s email, and that information is specific to the user; but on the other hand, a logo mage is universal and does not change for each user, so it is not information specific to the user

So the Show exercise produces a list of information that the Wireframe should tell to the user from the product.

What do the Wireframes Tell the Product?

The first part of the Show and Tell Exercise is to understand what the Wireframes Tell the User. Just like the telephone’s speaker, a wireframe should communicate information from the user to the product; so, you must identify what information the Wireframe is telling the Product.

The best way to do this is to review the wireframes and to circle all of the buttons because wireframes use buttons (mostly) to communicate information to the Product.

Then you should classify each button because buttons should only be used to Update, Delete, or Create information. For example, a button that lets a user change their email address is an update button because it is changing existing information; but on the other hand, a button that closes a user account is a delete button, because it removes (deletes) information (my account) from a product

Finally, you should determine what information needs to be communicated to the product to execute the command. You should review any forms in the wireframe and list the fields of the form. This is the information that you are sending with your command.

For example, a button and form that lets a user change their email address has an email field and so the command needs to send the email address along with the command; but on the other hand, a button that closes a user account is a delete button has no form or fields associated with it and so the command does not need any additional information

By the end of this exercise, you should have a list of Commands and Additional Information that the command needs for the product to execute the commands

When your teams have completed this Show and Tell Exercise, they should have a list of Information that the Wireframe needs to Show the User and a list of Commands (and additional information) that the Wireframes need to Tell the Product.

Conclusions

In this series of articles, I want to focus on a process that I use for my Product Team Handoffs that has helped my teammates master how to use wireframes and has improved my software development process. This Product Team Handoff Process has helped to cut costs and increase the speed of my software development teams.

In this article, I took a deep dive into the first step of this process, the Show and Tell Exercise, which should empower your teams to articulate what information your wireframes show your users and what commands your wireframes tell your product.

This list of information will be used in our next step, Defining an API, which I will review in the next article of this series.