Joy of Wireframing
Data structure pitfalls and validation
Drupal manages content based on data — as do, ultimately, most applications and content management systems. However, Drupal data structure is more transparent to the content managers than an app’s data structure is to their client base.
An application can create a form entry that could be several steps removed from multiple databases to make entry elegant; Drupal can only remove by a single step for the content managers. While a Drupal site can be set up to make pages based on HTML code that a content manager can manipulate — throwing all the content into one field — it hobbles the data. Want to pull in an executive summary on the search page? Can’t do it unless there is a specific field set up to capture what that data is, or you train your staff to build in an executive summary as the first part of the text field, and that training would need to include all the ways in could go amok.
Without a content model, a wireframe is a shot in the dark. It will be great for sparking more conversations, but it’s not going to be any closer to something that can be implemented. With a content model/data structure, the wireframe can start validating whether we’re thinking of the nuances correctly, if we’re overthinking beyond what the content manager really needs, understanding the level of data involved, even finding data gaps.
Before that word (validating) can go swimming by, yes, wireframes can be used to test the tires on a data structure. It can be approached as dealing with a list of data that someone wants to be included and making sure there is a spot for it all. Especially if the data is complex, though, as the information goes on the page the gaps appear. Or there could be real-world pieces that are being incorporated and someone along the line decided that a content inventory was unnecessary; a question comes up and spelunking in those pieces uncovers a hornet’s nest of data that wasn’t considered.
When data is found that should eventually be incorporated doesn’t mean that the process comes to a halt to include it. What is in everyone’s best interest is to make sure that these particular future data additions will have good places to be folded in, without having to reconstruct the data structure around them.
Experience design
Wireframes are also the best place to test user experience design. They can be done in the mockup phase, but truth be told: people get distracted. More on that in the next section.
When wireframing, we care less about perfect spacing, the right font, colors, etc. Those are actually a great deal to worry about, and by clearing the field so other things can shine through, we are giving mental bandwidth over to functionality and data.
When wireframing, we care less about perfect spacing, the right font, colors, etc. Those are actually a great deal to worry about, and by clearing the field so other things can shine through, we are giving mental bandwidth over to functionality and data.
Being able to focus on functionality can mean something as simple as we’re remembering to include search field/button. If our time is limited, either by client budget or an escalated deadline, it can stop there: just remembering to include the functionality, and if you’re lucky enough to work with the same development team it can be a communicated understanding that this will be our standard search functionality.
That’s a mountain of assumptions! It can work, and if the search needs of the client is fairly bland it can be a corner to cut.
What if the search function needs more strength, though? Spending time thinking through what kind of filters (if any) should be included is relevant. Some of the many questions that come up are: if they need to allow for multiple parameters; if they will all be categorized by static keywords, or freeform, or somewhere in between; how and what data makes sense for a standard user to be able to find and click through to deeper/more nuanced data; even if there should be visual codes involved or intermediate steps to their search.
If the data structure is one that is complex, this can take a good chunk of time. Being able to do it without the distraction of typography and color can clarify more quickly and in a way that can be better communicated to those who weren’t in the room.
Layout
And yes, wireframing is a way to test layouts.
A widely known and little discussed truth is that text and visuals distract from the very important discussions about content structure.
As soon as people see text and visuals that are close to what they might use on their site, they start critiquing those as though they were actual content. It’s a given. Not everyone will feel confident critiquing functionality, data structure, or even layout. Everyone has an opinion about color, writing/copy, and graphics. Yet we really need verification of what needs to be next to each other because it is what sets up the story rhythm of the page.
In it’s most simplified form, layout is a framework to talk about data structure in a visual context. Most data is pulled together in abstract ways: spreadsheets, lists, even long-form writing of the ideas. Next stage visualizations can be made with mind maps and hierarchical structures, but that’s still not understood at a glance by most people.
Our every day life is filled with layout. We have been trained from a young age to use context to derive more meaning, and layout supplies both context and order. Good layout makes the information scannable so the reader can skip to the specific point in which they are interested.
Great layout tells a story with how it builds the information. There is the opening gambit (banner); the details that are woven together to create the plot (blog links, clients, twitter); the denouement (primary focus: our product/service/reason for existence). We have to account for limited average attention span, so the story structure might not always adhere to the classic curve, but the layout is there to support the story.
Layout is also there to understand how the pieces are going to move as the screen increases and decreases in size. The client usually cares more that it will work, not how; but the developer already has a thousand details on their plate, and the designer is in a good position to understand how much space is relevant.
In short
I love wireframing. It allows us to solve a discrete, highly connected number of questions in a relatively short period of time. It lets us work with data in an abstract but readily interpretable manner, can give us free space to have greater understanding of complex functionality, and is the first step towards understanding responsive parameters for a website. It also lets us focus on how we’re building a story through context and data rhythm without the distraction of content.
This article was originally published by Angela Madsen on our Isovera blog.
