Step 6: Create First Draft of GUI
The first draft of the Graphic User Interface (GUI) should derive directly from the information hierarchy defined in the Detailed Site Map. Attention should be paid to the varying degrees of importance that some content types and functionality will have over others.
It is recommended that the creation of the First Draft include the production of three distinctly different design concepts. These concepts should each consist of designs for all defined template pages. The differences between the concepts should primarily be in regards to navigation approaches (how the site will be used) as color schemes for intranets usually come from standardized corporate palettes.
The rationale for three designs is that it allows a designer to conduct an exploration of possibilities that is ideally a lucid, thorough thinking process. If they understand good web design and usable interface theory, there are many GUI variations that can arise. As they think of different approaches, they may return to earlier ones and refine them.
The more significant benefit of multiple GUI concepts is that the stakeholder group will have a selection to review, analyze, and discuss. People with minimal interface design experience will point to aspects of concepts they like and don't like, and use a visual language that can more clearly state their intention than a halting non-technical vocabulary.
Before the GUI designs leave the realm of the designer, it is important that your project's senior technical developer and usability expert review them.
The developer needs to review the designs to make sure they are technically possible. They should advise you (and the designer) if they cannot be implemented at all (which may happen) or not in accordance with the schedule defined in the Project Scope Document. Remember the Factor of 2 Rule.
The usability expert should review the designs to make sure the design is intelligent. Sometimes a great flat design will become a nightmare when it becomes a fully functional web site. It's the usability expert's role to predict this and make appropriate recommendations.
When the team that is going to implement one of the designs has given their nod of approval to each of them, call a meeting of stakeholders. The meeting will be for the presentation and discussion of the three design concepts. If possible, have the senior developer and designer attend to answer specific questions and get first-hand exposure to the feedback. Bring printouts for people to refer to. And prepare for chaos.
If someone during the meeting is trying to convey an idea that they can't articulate, request that they provide a sample URL where the group can review their suggestion. Try to accommodate the non-technical people as much as possible, and listen to what they're saying even if they're not using the standard web designer lexicon.
The goal of the meeting is to walk away with either a stated preference for one of the presented concepts or at least a very clear understanding of what type of design is wanted by the stakeholder group. The meeting attendees should be told that a refinement of the chosen concept will be created by the designer and two variations of the final design will be forwarded to them as per the original schedule.
During the meeting, take extensive notes. If you can't do this while presenting, have someone meticulous take care of this for you. Notate suggestions, who made them, what was agreed on, what was dismissed (sometimes good ideas can be disregarded and brought back to life later) and what the action items moving forwards are going to be. Then create two reports, one for your personal use (with all the specific details) and one for distribution to the stakeholders (with a detailed summary).
Your personal document should include information about which stakeholder didn't say much and might need a one-on-one visit to get them on board or answer questions and address concerns. The intranet can be a highly political animal because it touches all departments, lines of business and individuals within an organization. So be politically savvy when necessary, but remember to protect yourself with extensive documentation.
The group document should be a comprehensive summary of the discussion outlining what was agreed to and an itemized schedule for next steps. Make this document one to two pages, if possible, but don't sacrifice detail for space when needed. Noting "the idea to have a webcam stream pictures from the Grand Canyon was dismissed as impractical and expensive" can keep you from having to explain later why it wasn't included when someone thought it would be...
Make sure that all legal requirements are fulfilled - if your company employs visually challenged or physically challenged people, the intranet should be accessible to them - or be prepared to spend time answering questions in court. See the chapter on usability for more information on the implications of this.