Product Wireframes, Mockups, and the Day I Almost Cried

I love building great products. There are so many moving pieces it keeps me engaged all day long. And when done right, each step of the journey is more exciting than the last. But there are always a few bumps along the way. Overcoming those challenges is part of the allure of the job.

It is the times when things do not go according to plan that usually become your most valuable lessons. Ultimately, it is how I learned to build the perfect wireframes. Here is what happened to me.

Many years ago, I was working with my product team on a redesign of our software’s initial getting started screen. After analyzing our data and getting customer feedback, we decided that it was time to add an additional view to help customers get going. Our goal was to get more people engaged earlier and to drill down deeper into the product. We all want that, right?

So, I put together a few wireframe options that described the new functionality and proposed user experience. The wireframes reflected the high-level features that the product team and I had agreed upon. The team approved and I was confident we were on the right track.

So, I decided it was time to present my thinking to the CEO. I completed a detailed presentation with Photoshop-designed screens for every possible customer interaction. I spent a few days working on it. I wanted to help him get a better visual representation of what we wanted to build.

What happened next? Disaster.

We had our meeting to review the designs. I showed him my mockups with great expectations; I hoped that he would love my initiative to start redesigning the page and customer experience.

But things did not go according to plan. He did not like the look and feel of the page, could not read the font I settled on, and was not a big fan of the button colors. Instead of earning praise for taking this bold step, I was quickly peppered with questions (and complaints).

After another 15 to 20 minutes of back and forth, it was clear that I had lost control of the meeting. It was a mess. I left the room with my head hanging low. It was also a valuable lesson for my career as a product manager.

Here is how I moved on.

I took a step back to think about the meeting and what I should do next. Almost all of the feedback I received related to design! We never even talked about the new and improved customer experience, which was why I prioritized the project to start with.

I went back to the drawing board and opened my initial wireframes to review them. My wireframes laid out the functionality in the same exact way as the “designs.” And both had the new features and functionality.

The only difference? The wireframes were simple black and white, and the design had bold color treatments and font styles (admittedly, poorly designed). That was it.

My CEO was getting distracted by all of the different visual treatments and could not get past them to focus on the customer value — which was the primary reason for our redesign.

A few days later, we met up again. This time, I brought along just the initial wireframes and nothing else. What happened? That meeting went as smoothly as I had originally hoped and expected.

We talked about the functionality, reviewed some high-level strategic concepts, and made some slight changes to help our users discover what they wanted even faster. We got on the same page — and set a date to circle back once I had worked with a designer to flesh out the final interactions and designs.

The key lesson is to think about wireframes as more of a conceptual and strategic tool than a final representation. They should be used to explain value, not button action.

The goal is to help you and other team members figure out the basic layout and navigation of the page. So, break up these tasks so that you concentrate first and foremost on how your new ideas will better service users. Then, focus on design elements later.

This will help you to focus on what matters most at each phase of your product development process.