With the ever-increasing custom interfaces put on CMS tools, there comes the need for greater clarification of requirements and design for the UI. Using wireframes as a requirements definition tool is one of the most inexpensive and successful methods available, and yet some folks still prefer to use pages of prose to describe what one image would do. Or worse, build it and then make corrections.
Wireframes come in different levels of fidelity. A low fidelity wireframe can be as simple as a drawing on a cocktail napkin. It’s intended to express an idea. Though unassuming, these ideas are often the beginning stages of a much larger concept. This could be anything from the common elements of a user interface, to a the placement of tabs, text and general layout, without concentrating on the overall presentation, color, fonts, etc. At this level, people can collaborate on user flow and controls without taking the time and expense of building something using actual graphic design programs or code applications. The beauty of the wireframe approach is that requirements can be quickly and easily discussed, reworked, and then confirmed. Using an Agile approach, one could represent the user stories in a low-fidelity wireframe (using Balsamiq or something similar) and then use the wireframes to validate the stories with the product stakeholder. Alternatively, white-boarded wireframes can be a good starting point in the process, and user stories can then be written once the ideas have been more solidified visually.
Here’s a scope-definition incident. Below is an example low-fidelity wireframe. This was developed in short order after finalization of user stories. However once all the requirements were represented, the wireframe brought up additional questions not addressed during requirement gathering. For example, is there a search history? Is there a history of past keywords or common keywords? Is there a “Help” and if so, what kind of help is hidden behind that link? These might have been caught eventually, but only after the interface was built out to some degree and previewed with the client.
How and when to use wireframes with CMS development
While the client may have a good idea for what the tool should do, often they will not understand the limitations of the CMS software being used. As a result, their wireframes aren’t going to be adequate. However, if left only to the development team, then there may be extensive revisions from the client. Therefore one answer is to have an initial collaboration session once the technology stack has been determined. The tech lead will manage client requests on overly complicated alterations and changes. In turn, the client will provide immediate direction on the requirements. Out of this initial round can come enough agreement where the development team is able to create a second round of wireframe development on their own and not expect a ton of revisions. In the end, you’ll have a foundation of wireframes that visually express the requirements and help accelerate development.
The added advantage of taking this step is that once complete, the wireframes will then aid in the graphic design production. Additionally, if not included in the previous step, a UX expert can then evaluate the wireframes and make changes to increase usability. Refined wireframes can then be put in front of stakeholders or used in focus groups to get early feedback and acceptance before money is spent on development.