A picture is worth a thousand words. But sometimes, a picture isn’t enough. There’s a story behind every picture that often requires context that a picture alone can’t provide.
In user experience design, wireframes are our pictures. Wireframes help convey what bulky requirements documents used to convey. A lot of teams don’t even make requirements documents that are hundreds of pages long anymore. But, I’ve been doing user experience for long enough to know sometimes wireframes are not enough.
I can’t tell you how many times I’ve been in a meeting and someone says: “I just don’t see it. I don’t understand these wireframes. Why is there fake text? Why is there a big box with an x in it? Will it really be just black and white?”
Wireframes are a great tool to help convey requirements. But, if wireframes lacks actual content, then there’s a lot left to the imagination and interpretation. This is when teams and projects start to break down – timelines start extending, budgets start expanding, people start getting frustrated – all because requirements and content were not conveyed through the wireframes.
If you want to avoid this cycle, then you should consider using real content in your wireframes. In the design process, I use different levels of fidelity for the wireframes I’m working on depending on the stage if the project.
Early on in a project when I’m exploring ideas with a client, the wireframes and sketches are very high level and don’t have much detail. The reason for not adding much detail at this phase is because details take time. Also, the more detail you add to wireframes, the higher the risk that the stakeholder or client will get attached or confused by the content (images, color, icons, text, etc). Trust me, time and time again I’ve had clients get hung up on placeholder headline text, and because of that, they deem the entire wireframe inaccurate. Beyond frustrating!
Exploring a variety of design directions early in the design process is critical. I call this stage diverging. At this stage, the goal is to get as many ideas down as possible either in sketches or wireframes. This helps confirm stakeholder goals, business needs, technical feasibility, and content requirements. It’s rare that a client will come to you with the exact requirements for the product. So, this is why creating a variety of early, high-level concepts is so important. In this phase we focus on space allocation and prioritization on the page for various features, messaging, and other content.
As a project progresses and requirements become clearer and we start to head down the path of a single concept – this phase is called converging. At this phase, everyone starts to agree on the structure of the screen, features, and prioritization of information on the screen. It’s now time to start to fill in the details of the experience in the wireframes. These details include elements such as form labels, key content blocks, various interaction states such as drop down menus and more.
When it comes to content though, a lot of people argue that it’s not the job of the user experience designer to create the content for the client. I agree that it’s not your job to write every sentence or choose every icon.
But, I do believe that creating a great user experience is a result of everything that the user experiences – and that does in fact include the content.
The icon you choose can help guide someone or totally confuse them as they scan the page. The label you put on a form field can either make complete sense or raise a bunch of questions for the user. Every little detail matters, including content.
The bottom line is that content drives requirements. Without a solid understanding of the content you’re designing for, you’ll never be able to identify the requirements.
Fake content results in fake requirements. But when you take time to use real content, you’ll help bring clarity to requirements that were unknown or that may have changed since the project started.
When I’m working with a client, I put a lot of thought and care into helping shape the content on the screen. Why? Because every word, every image, every icon shapes the experience of the page. I always try to influence that early on in my wireframes.
Just last week I was working with a client on redesigning their homepage. I could have used what they already had on their homepage in terms of images and text. But, when I looked at the homepage, I realized that half of the problem was the story they were telling through the images, text, and icons. So I re-wrote most of it and helped them shape their story and message. If I had just approached the project with the attitude that I was only going to use their existing content or placeholder content, then the homepage probably wouldn’t turn out very well.
What happens if you don’t have access to content or it’s a totally new product with no content already existing? I’d recommend going to a competitors’ site and using their content to get started.
Here are 4 reasons why you should use real content in wireframes:
1. Real content will help stakeholders give better feedback
A lot of clients and stakeholders I’ve worked with have had a hard time wrapping their head around wireframes. As a result of this, they end up giving very poor feedback and input because they just don’t see the idea. I admit, not everyone has vision that lets them see beyond the black and white boxy documents we make. If I were having a house built, I too would probably have a hard time imagining the final product just from a blue print! The more detail you can add to your wireframes, the more people will truly absorb and think about them – yielding better collaboration and communication amongst everyone involved.
2. Real content will help clarify product requirements
Imagine you’re designing an e-commerce site and on the left of a search results page will be filters to help people narrow down to the specific types of products they’re interested in. In the first wireframes, you might just have a rectangle that says “filters”, in the second wireframes, you might list out the possible filters such as price, brand, category, rating, etc. But that’s not enough detail! Let’s take the filter of “brand”- it’s important to know how many brands a user could filter from. If there are 10 brands, they could easily be presented in a list. But, if there are 50 brands, that would result in a list that would be far too long for the left column. So, you’d have to develop a solution that presented the 50 brands to the user, without showing them all at once. Details like that matter up front. If you don’t take time to understand and design for the real content, then you’ll end up playing catch up later in the design process.
3. Real content helps speed up the entire product development process
In 99% of the projects I’ve worked on, one of the top 3 reasons for a product launch being delayed is because the content isn’t ready. Everyone gets so excited about creating a website or app that they forget the part of what makes it successful is the actual content within it. As a designer, by focusing on real content early and often, you will force the rest of the team to start thinking about, creating, and gathering the realistic content earlier in the design process. In doing so, this should help the product not be delayed and sometimes worse, avoid a rush at the end when content is just hacked together and it doesn’t have a cohesive message or brand, all of which create a confusing user experience.
4. Real content will help the visual design team understand space constraints
The visual design team needs real content in order to do their job. Here’s a simple example: if a designer is creating a top navigation bar, and doesn’t know the actual names of the navigation links, then that’s a problem. How many navigation links will there be? What is the exact name of each navigation link? If the link names are very long, does the designer have liberty to come up with shorter words? I can’t tell you how many times I’ve worked on a project and the designer creates a top navigation bar and then the client says, “actually, we need to add two more, and we need to rename 3 of them”. This is a design nightmare! You can avoid this by trying to draw out realistic content from the client as early as possible and include it in the wireframes.
Conclusion
Are you working on a project that’s going over timeline or budget? If so, consider asking yourself what the true problem is. Could the use of real content help get your team and project unstuck?
Could real content help stakeholders be more engaged and give more your actionable and relevant feedback?
Join the discussion in the comments below.