The first entry in this two part article talked about the fundamentals of wireframes testing and its advantages/disadvantages. In this entry, I will touch upon my journey with expert review method of testing wireframes.
Expert Review
Expert Review involves a subject matter expert, reviewing the wireframes and providing feedback, from the gamut of his/her past experience.
High Fidelity Wireframe
A wireframe which is quite close to the final product, with high level of detail and a good indication of the final proposed product with good aesthetics and functionality is high fidelity type.
Consider a high fidelity wireframe in the picture above. This wireframe includes placeholders for tabs, hyperlinks, images, search box, breadcrumbs and others. In short, this wireframe contains the layout, navigation and hints on how the product might work or behave.
Low Fidelity Wireframe
A quick and easy translation of high-level design concepts into tangible wireframes constitutes a low fidelity wireframe. In the above picture, placeholders are defined at a very high level, providing information on layout and structure of how the product might appear on low fidelity wireframes.
Problem Context
An year ago, I happened to test high-fidelity wireframes for a web-based product used by call center folks to sort incoming service requests and process them into appropriate queues. The product sounds simple, until the time you hear that the analyst has to pick each service request, convert it into a format that another automated system can understand and push it into different queues depending on the type of service request. Each analyst has to process at least 100 per day and the current system was too un-friendly to let analysts work productively, without making mistakes. Hence, the need for re-design!
In their quest to help analysts use the product better, the development team wanted feedback on the wireframes they had developed, which they hoped would fix some of the challenges the analysts were facing, if not all.
Wireframes Testing using Expert Review Method
High Fidelity wireframes have information architecture and content strategy, fairly sorted out, although wireframes are early work products. This means that in addition to layout and navigation, placement of information and presentation of content are described to good degree that is good enough to make a call on whether the product conveys what it is built for.
Layout
A low fidelity wireframe above has few placeholders within the layout. Once can provide feedback only on the structure of the layout, positioning of placeholder elements and possibly the titles used. Beyond that, this is a pure skeleton of how the product looks like and has little scope for review.
On the other hand, a high fidelity wireframe provides better scope to review not just the layout, but a major part of the product itself.
User Interface Elements
Validating the need for UI elements is extremely useful while reviewing wireframes. This is when, one can make choices of selecting sliders or pickers over dropdowns or accordion views, based on the context of usage or make other appropriate choices. UI elements include:
- Landing Screen (Look & Feel)
- Header / Footer information
- Title (Browser Title and Page/Screen Title)
- Labels and other Tech Jargon
- Logo / Buttons / Icons
- Images
- Text Fields
- Settings (Login / Sign In / Logout)
- Date / Copyright Format
- Placement of Scrollbars, Dropdown menus
- Accordion Views
- Others
Navigation
- Buttons / Links as visual cues
- Workflows
Content
- Presentation
- Alignment
- Size and Style
Functionality
- Existing functionality – features that depict existing functionality
- Missing functionality – features that may be missing, although, highly relevant to the context of the product.
Above information may or may not be available to full degree in the wireframes. Depending on the type of wireframes provided, it would be good to review them and provide appropriate feedback. Feedback can be provided at two levels:
For each item (element based feedback. For e.g. a particular dropdown may be positioned wrongly on the landing screen)
At a product level (Navigation could be streamlined better w.r.t ‘Translation’ feature)
Challenges I faced
One of the biggest challenges with reviewing wireframes was the fact that transitions, interactions and other subtleties, are not visible and need a further level of probing/questioning to get clarity. Although, at wireframing stage, we might not worry much at this stage, it always helps to outline interactions and behavior of the product early on. At each screen level, I would put a list of all interactions a feature might have with other features and design how interactions can happen. This way, many flows can get sorted out upfront.
Summary
Wireframing, either on paper or using software is much cheaper, faster and offer better benefits like portability and accessibility compared to a working prototype. Today, ‘Go-to-market’ cycles are shrinking with lesser time to design products. This means that spending several man years on programming an interactive prototype is a costly affair. A key deciding factor to create an ecosystem that believes in wireframes begins with creating great wireframes that communicate well and iterate on them based on inputs from different kinds of users.
Wireframes have personally helped me gain design insight and find usability problems early; which means we save *some* time, *some* effort and *some* money that might have been spent on building *big-failure* products.
How have wireframes helped you?
