I said it. Wireframes suck. I hate wireframes. Wireframes do more to protect an agency than they benefit clients, and that’s why we don’t usually do them. Instead, we suggest a content-first approach.

There are exceptions, though, and if the site is very functionality based, wireframes serve a purpose. But for the sake of this article, we will dive into the issues with wireframes for marketing websites.

What is a wireframe?

Wireframes are a common deliverable of the UX phase of web development. They are effectively a page schematic and serve as a skeletal framework or visual of a website. They are not stylized and therefore are not focused on aesthetics, but rather the layout, components, fields, functionality, and any other details of the page. As part of that, they often indicate where certain content will appear on the page and sometimes show character counts for different fields and elements.

Once wireframes are approved, then they are stylized and made into UI designs. 

Why are wireframes used?

Wireframes help show how all the elements of a page will come together without spending design effort. It makes sense from that perspective, as you wouldn’t want to spend design hours that end up being throwaway because the layout, functionality, fields, etc., are not approved.
In short, they are used to get approval on the schema before doing the designs. By this logic, even though it is an added step, it prevents rework and ultimately keeps schedules on track. 

Then what is wrong with them?

Well, the reasons I mentioned benefit the agency. They don’t really benefit the client. Because most agencies use a gated approval approach, if during the design or build phase, things need to change that were detailed in the wireframe stage, that will likely result in additional cost to the client, as it will be changing a previously approved deliverable.

Although that may seem fair, it really isn’t, because clients often do not understand wireframes. They may not understand the implications of what they are approving or if those wireframes even make sense, because they typically don’t know what their content will be at this phase.

Wireframes are usually filled with lorem ipsum, so although a wireframe might make sense at the time, once content is added into the designs or into the build itself, the layout, functionality, fields, or character counts may not work based on that content.

While reading this, you might not think this seems likely, but in our more than 15 years of experience in web development, we’ve seen it happen in almost every project that used this methodology.

Consequently, this whole wireframing exercise often results in a giant waste of time and money to the client, and just pads the pockets of the agency and buys them more time on the project. 

So what do you propose instead?

We recommend a content-first approach. You can read more about it here.

That means you define your content first, so you can do information design to best present that information to the user. With this approach, you can usually jump right into UI design after developing your content. In other, more complex cases, you may still need to do wireframes, but at least the content is taken into consideration in the development of the wireframes instead of just guessing.

Sure, this might result in a longer initial schedule, but it will set the project up for better success. This will more than likely result in actually meeting the overall schedule, while a wireframe-based approach will likely result in cost and schedule overruns.

We care about our clients, and we are not interested in making a quick buck. We’d rather do the project right and deliver the best possible experience to our clients.

Back to INSIGHTS

Share