Before we begin work on the design of any site, we always start with wireframes. Simply put, a wireframe is a blueprint of the structure of the site. It’s a way to visualize how the content will be arranged on the page without the commitment of design or development.
Because it’s a much greater investment of time and effort to design and develop a website, we start with a wireframe so you can easily visualize how the site might look, but also have the flexibility to make changes to the architecture. Wireframing typically takes place after we’ve created the sitemap, so the general structure of the site has been laid out. Still, even with a well-developed sitemap, it can be hard to envision how the pages will look. It’s one thing to plan out things like menus and page elements, but when you actually see them on the page, it helps you identify places to improve before actually committing to a design. The wireframe takes into consideration where the main pieces will be placed on the pages of the site, how the navigation will be organized, and the size and location of things like calls to action, header and footer elements, images, and so on. Laying out these elements gives you a sense of the user experience and helps to refine the interactions.
We disregard things like fonts, colors, and animations in favor of barebones sketches, completed with a wireframing tool called Balsamiq Mockups. The following example shows the evolution that takes place in the wireframing process. The wireframes displayed here show a Dashboard we built for Credit Builders Alliance members. The dashboard was based on a Salesforce integration that pulled in user-specific data.
You can easily see how calls to action, in-page navigation, and information display are adjusted throughout the process to reach a final version that takes into consideration user experience and makes efficient use of the space on the page.
In version 1, we started with the in-page navigation in a tabbed, lefthand sidebar that only displayed one screen at a time. The information display was simple, but the client had some concerns that some sections might seem too empty with this structure.
In the third iteration of this wireframe, we’d changed the navigation to an expandable and collapsible accordian-type display that would allow users to see many as many or as few sections simultaneously as he or she chose. More information was displayed in the default screen, and a sample expanded section was shown to get a better sense of the content layout. In both versions, calls to action were located in the sidebar and beneath the main text areas, simply swapping the location of the different calls from one version to another.
By the time we’d reached the final version of this wireframe, sidebar calls to action were eliminated in favor of a wider display of information. This way, more information could be displayed horizontally, reducing the amount of scrolling the user does when visiting the page. The fields displayed upon welcome were also updated, as was the type of information displayed in the expanded section. The in-page navigation remained largely the same, with a change in order being the only modification.
Had all of these changes been done in the design phase using a more sophisticated software like Photoshop, they would’ve taken much longer to implement, taking time away from the budget for more technically robust features to be built later, like the Salesforce integration. The result is an end-product that displays information in a user-friendly manner that was exactly what our client had hoped for.