Design Preparations

Before launching into the creative process, the designer needs to gather and review information on what has already been defined. This includes reviewing the style guides, information architecture, creative and UX discovery briefs, taxonomy, and any additional business and system requirements that have been documented.

Review Final Wireframes

The designer uses the wireframes as a basis for the placement and layout of the functional controls, navigation, and web parts needed on the page. Wireframes should reveal the positioning of the main portal features such as the header, navigation, content layouts, and footer links. The designer normally is tasked with creating multiple versions of designs using a single design template specified within the wireframes. In most cases this template is the homepage for the site. Depending on the time allocated, the designer might also be tasked with extending the design to other pages or templates such as community, department, team, and My Sites templates. The ultimate goal is to create a visual style for all of the unique design elements on the page. The designer will need to work with the IA to identify these elements and determine whether any special cases need to be designed. Special design elements might include custom filters, modal windows, and custom controls. The wireframes should not drive the design direction.

The designer should also work with the development team to identify anything that would add technical complexity and expand the scope of the project. In most cases the designer should be flexible and find alternatives that still promote the best user experience possible—either with out-of-the-box solutions or using an easier way to implement the custom solution.

Specifications within the wireframes help the designer and the developer understand requirements that cannot be represented in a visual format, as shown in Figure 4-2. You'll want to capture a few key elements (purpose, audience, layout, and content inventory) for each wireframe that gets created.

Figure 4-2. Example wireframe specifications

The first task is to define the purpose of the wireframe, clearly identifying why the wireframe exists and how it should be used. The second element is to specify for each wireframe the audience that the wireframe is targeting. Some wireframes show administrative functions or display the page in edit mode. Clearly identifying who the audience is for each wireframe helps the designer and the development team know what should be visible to readers versus administrators or content authors. The third item is to clearly define what type of page layout is being used. Typically, any SharePoint projects that include publishing sites will have custom page layouts. Some are as simple as just one for the homepage and one for the top-level publishing content site. However, with more advanced portal sites you might have 10 to 15 custom page layouts that have their own unique web part zone layouts and configurations. The last specification that should be included in each wireframe is the content inventory. This inventory list clearly defines all of the web parts and custom controls that are visible on the page. For each component it then provides a best match for either an OOTB web part or specifies if something is custom. This makes it easier for the developer to scope out the level of effort necessary to create the defined wireframe.

It is always a best practice to ensure that a complete knowledge transfer occurs between the information architect and the visual designer. These two roles need to work very closely together to ensure that functionality is not lost while transforming the wireframes into final creative designs.

Review Requirements

The visual designer must review and become familiar with all of the specified requirements for the specific pages that are to be created. It isn't enough to rely solely on the wireframes because some requirements might not have been addressed during wireframe development. Some of these requirements (or story tasks if you are using an agile methodology) further define the business or system rules for how the site should function.

Review UX/Creative Brief

The visual designer looks to the UX discovery brief and creative brief as the primary documents for giving the direction on the tone and style for the design. The business stakeholders need to have reviewed and signed off on these documents before the visual designer starts creating the visual designs. Because the designer is usually the one who created the brief to begin with, there's already a familiarity with the specifications and requirements. There might be an extended period of time between the creation of a brief and when it actually gets used as a reference for the design. If this is the case, the designer should review the approved brief again with the business stakeholders to make sure nothing has changed since its approval.

Establish Review Cycles and Schedules

The designer should work with the project manager to identify the number of review cycles needed and communicate to the stakeholders the amount of time they will need to set aside for review meetings. For smaller design projects there will be between two and three design-review meetings. The first review meeting usually takes around two hours. The second and third review meetings should not take more than an hour to review the changes and achieve sign-off of the designs. For larger projects, the designer will be creating a greater number of visual design compositions and extending them to multiple templates and pages. This will require multiple iterations and more time from the stakeholders. The first initial meeting should be no more than 2 hours. In these meetings it might cover the transition from wireframe to visual design. Before bringing any designs to the stakeholders for review, the designer should work with the project manager on scheduling weekly review meetings with both the development team and the information architects. This allows the internal team to make slight adjustments to the schedule to ensure that what they show to the review team represents the most accurate designs that can feasibly be built within the scope of the project.