December 2, 2013


Importance of Low Fidelity Wireframe

A developer’s work methodology involves receiving the requirements as a rough and ready prototype from the designers, but with a vision to achieve a definitive end point. Their aim is to deliver a “bug-free product.”  Thus, developers know both the start and the destination.

Usability analysts always start with a clean slate. Building a usable, accessible, intuitive, error-free interface by understanding the users and their behaviors is an uphill task. They co-ordinate with all the stakeholders, gather basic information about the application, do extensive research, and put all their thoughts and logic in black and white to build wireframes for the application based on the usability guidelines.

But that is just the start. Post-wireframe creation, the visual designer plays a crucial role in bringing life to the wireframe. They have the power to make or break the application’s entire user experience. To achieve that awesome look and feel in the design, the visual designer should be given complete freedom to play with the design elements. If they are encouraged to mimic the presented layout in the wireframe as it is, guess what happens? Even a talented visual designer could fall into the trap of merely coloring the wireframes, and as a consequence, that brilliant interface design could become a big failure.

One alternative to avoid this situation is to share the low-fidelity wireframes as a reference for the visual designer, to give room for creativity, and in turn, help in churning out “out-of-the-box” design ideas.

Post initial understanding of the project, after finishing the content bucketing and information architecture, the usability analyst should keep in mind that the visual designer is going to play a key role in creating the look and feel through his/her input.

In order to give space for the designer to do the magic, the usability analyst should create very low-level wireframes, i.e. s/he shouldn’t focus on layout/structure/patterns; the wireframes should just be content-based placeholders and should never give a clue to the visual elements.

The usability analyst should involve the visual designer at this stage, and should explain the ABCs of user research results and understanding. It’s very important to first convey all the design necessities, e.g. if the application is multilingual, or if it should be responsive, or if there are limitations in choosing fonts, colors, etc. The visual designer should essentially know the ins and outs of the user goals and needs. This is possible by participating in a brainstorming session about the latest trends and patterns that can be incorporated into the application’s visual design. This will definitely provide the ways and means to achieve the goal.

When the visual designs are ready, it is the usability analyst’s responsibility to review the designs. S/he should cross-check whether the designs meet user requirements. If there is anything amiss, it is his/her job to inform the visual designer, explain the requirements, and make the required changes.

The best combo of usability and visual design is really the secret mantra that can make or break a user’s experience with any application. The sum and substance of this writing is that the usability analyst and the visual designer, as a team, should have a good rapport and work together with low-fidelity wireframe in full swing to achieve that awesome design.HCL has its very own usability testing unit that has institutionalized an automated approach to ensure re-usability and maintainability.