In this section, we develop an initial sketch of what the user interface could look like that takes advantage of the granular information model we have designed. In the next section, we will assess its usability. Finding shortfalls, we will create a refined version.
Our initial sketch for the microsite’s landing page looks like this. Sketches like this are called wireframes. They are constructed to illustrate and explore just those points we are trying to make at a given stage in the design process. They deliberately ignore many considerations that may become important later, if our approach is pursued. What does this wireframe highlight?
- it presents an overview of the consulting group’s capabilities and track record, which was the initial project brief,
- it shows that the user has a choice to just read the overview material, or navigate to more detailed information about Practices or about Projects, according to their preference.
What does it ignore (at this time)?
- it ignores all branding
- it does not make any claims about content quality, providing dummy or placeholder content for illustration
- it ignores layout choices; a UX colleague may recommend that Practices and Projects be stacked vertically, or that scrolling galleries be used for the Projects; our contribution was to tease out these two concepts and offer an approach with richer user experiences.
Here is the wireframe again, this time with blue callouts showing how the areas of the page relate to the information model. It is important to cross check the wireframe against the information model in detail, to make sure that there is a source for all information that we want to present to the user. In this case, for example, we find that the information model does not yet provide for images and thumbnails. Let’s assume that we fill in the gaps by adding Image to Consulting Group, Thumbnail to Practice, and Thumbnail to Project.
From the landing page, a user can navigate to a Practice page, let us assume Software Development. Our initial wireframe for a Practice page looks like this. The left-hand side presents information from the Software Development instance of Practices. We could have stopped with just this, but we decided to exploit the cross-reference between Practices and Projects in order to display projects done by the Software Development group.
We did this for two reasons:
- we can reinforce the credibility of the Software Development group (business benefit)
- users have a natural forward navigational path (user benefit).
From the landing page, or from a practice page, the user can navigate to a project. Our initial wireframe for a Project page, let’s assume a Federal Government project, looks like this. The left-hand side presents project information. The right hand side displays project testimonials and the practices used to deliver the project.
Why did we put testimonials above practices? We had no good reason. We personally thought that they may be more important in demonstrating our credibility. At this point, though, the layout is open for discussion.
These wireframes seem plausible. They certainly give the user more navigation choice than the brochureware approach that we started with. Users can focus on projects or practices depending on their interests.
But when we do some usability testing, we find that there are still problems with overall flow. The good news is that we have a granular enough information model that we can improve the user flow in a straightforward manner.