You should wireframe

Wireframing for Everyone

Some exciting news this week! I was able to write the foreword for Wireframing for Everyone, from a Book Apart.

I've been a huge fan of A Book Apart for years. They put out some of the best content for people who are creating software. Two of my go to recommendations to get better at designing products are Elements of Content Strategy and Just Enough Research. Wireframing for Everyone adds a third to that list.

As Mike Monteiro pointed out earlier this week, people in the software industry like to proclaim that wireframing is dead. It's true that as a formal "stage" in the software development process, we talk less about wireframes. In college I remember taking physical pieces of paper around to do usability studies. I can't imagine using wireframes for that anymore. I don't sit down to say "first we generate requirements, then we make wireframes, then we..."

Despite that, many of my favorite work memories are from wireframing. It's fast and collaborative. Much like it can be easier to have a tough conversation while walking or driving in the car, it can be easier to work out contentious product issues side-by-side at a whiteboard. If you're a designer, PM, or founder you probably know most of what is in this book. But it's nice, quick way to refresh yourself. These skills might be things you've dabbled in roles adjacent to software creation, and this book can take you deeper.

I think this book will have the most impact if you aren't already someone who feels comfortable building software. "I can't code" also tends to encompass "I don't know what I should code." Even if you don't intend to build your own software, learning about wireframes can help understand how the software you use you use fits together. Today you might know "this website is bad" and learning about wireframing can help you articulate why.

Wireframes ask and answer key questions about a product. They make underlying assumptions explicit:

• How do I expect people to sign up for this product? What services do I assume they are already using? How much effort will they be willing to put in before they get value back out?

• What do people want to see every time they use this product? What needs to be easy and quick to do?

• What's more complex and requires expertise? What's okay to require documentation or guides for? How do users navigate between tasks?

• What are the edge cases that come up that need to be accounted for somewhere?

• What don't we need to do?

If you haven't been exposed to wireframing as a concept, I'd highly recommend picking up a copy of the book.