The 4 Ds

The four phases shown at the top of Figure 2-1, Discovery, Definition, Design, and Development, are the main user-centered design phases that are covered within this book. These four labels may differ based on the methodology that you use, but the tasks associated with each one are consistent across most projects.

Figure 2-1. UX process

Discovery

Within the discovery phase the business analyst, information architect, and technical architect conduct sessions with business stakeholders to gather and define the business and system requirements. They also identify who the users of the system are and create personas as needed. The discovery phase has two steps, as shown in Figure 2-2. The first step is to gather business and system requirements. The second step is to identify user personas.

Figure 2-2. Discovery phase

Discovery Documents

The documents that are created during the discovery phase set the foundation for how the portal will function. This phase is really the start of the project. There is a kickoff meeting to identify the purpose and scope of the site, introductions of team members, project schedule, critical success factors, deliverables/milestones, risks, and escalation paths.

The business analyst starts with interviews of the business users and key stakeholders to identify what the users need this site to provide and what features and functions it should have. All of the requirements that are gathered are compiled into the traceability matrix and organized into multiple columns, as shown in Figure 2-3. The traceability matrix can be created in Excel or managed directly in SharePoint as a custom list.

Figure 2-3. Traceability matrix

Another very helpful discovery document records the various personas and the defined users of the system. This document provides a detailed description of the “user by role.” Personas can be as simple as the name of the roles to very detailed specifications, as shown in Figure 2-4. This type of diagram allows you to quickly identify what type of user they are. Here are some key questions that you will want to ask users when defining your personas:

• What are your current roles and responsibilities?
• How often do you use the current portal?
• What do you use it for?
• What do you like/dislike about it?
• Have you ever used SharePoint before? If so how often?
• Do you use any social websites like Facebook, Twitter, or Linked In?

Figure 2-4. Persona snapshot example

Definition

During the definition phase the information architect takes the business and system requirements from the traceability matrix and creates a variety of documents that help define the taxonomy, navigation, page layouts, and templates. The definition phase consists of two steps, as shown in Figure 2-5. The first is to define the site map, navigation models, and content types. This gives you a base set of information to then move to the second step, which is to start wireframe development.

Figure 2-5. Definition phase

Definition Documents

The types of documents that might be created in the definition phase are either visual representations of the requirements or groupings and labeling of information. To help define either a site map or a navigation model, conducting a card-sorting exercise, as shown in Figure 2-6, can identify how users group and label information.

Figure 2-6. Card sorting

Creating wireframes is a very quick and effective way of displaying an idea or layout without having to be concerned with its visual appearance. Wireframes can start out as sketches and then mature into something much more polished. There are a few software applications that can help you create wireframe sets. Some people like to use OmniGraffle, iRise, or SketchFlow to create dynamic and interactive wireframes, but these types of programs can be expensive and hard to use. Visio is a simple yet effective tool that you can use to make and reuse wireframes, web parts, and UI controls for multiple projects. The information architect builds out wireframes to conduct usability testing and also shows them to the development team so that they have a better understanding of what the end result should look like. Wireframes can range from 5 to 10 pages for small projects and 50 to 60 pages for larger ones. This more involved type of wireframe, shown in Figure 2-7, contains a lot of detail and is easy for the development team to understand.

Figure 2-7. Example wireframe

The site maps and navigation models that were generated by card-sorting exercises should go though some sort of usability testing. This testing can be as simple as showing the structured model to a variety of people and documenting any questions or concerns that they have. Another method is to provide the people you are testing with a task like, “Submit a time sheet,” or, “Download PPT templates.” Document how long it takes them to complete tasks and in what category they feel they would successfully accomplish their task.

Remember that site maps do not always have to be linear, parent-and-child categories in a traditional “boxes and arrows” tree hierarchy. In some cases you can afford to get very creative in mapping illustrations, and encourage your stakeholders to take part in creating a more innovative navigation model. For example, a non-linear site map can be very flexible. The goal is to provide system owners with an acceptable level of governance through controlled placement of content while giving end users the freedom to accomplish daily tasks and navigate the system unimpeded by labeling and navigation constructs. As demonstrated in Figure 2-8 not all sitemaps have to be boxes and squares. The size of the circles can represent importance and also the number of sites under them.

Figure 2-8. Graphical site map

The last area of the discovery phase is site columns and content types. Site columns are just like any other list or library column in SharePoint but are managed at a higher level. When you combine multiple site columns together into a set you are basically creating a content type. Content types, a core component of the functionality and services within SharePoint 2010. Content types are designed to help users organize their SharePoint content in a more meaningful way. A content type is a reusable collection of site columns that you want to apply to a certain category of content. Content types enable you to manage the metadata and behaviors of a document or item type in a centralized, reusable way. They most often come from a business need to identify and group unique types of artifacts. SharePoint comes with some basic and very useful content types out of the box. Additional content types can be defined and then instantiated in SharePoint during implementation.

For example, consider the following two types of documents: software specifications and legal contracts. It is reasonable that you might want to store documents of those two types in the same document library. However, the metadata you would want to gather and store about each of these document types would be very different. In addition, you would most likely want to assign very different workflows to the two types of documents.

With content types you can store different types of content in the same document library or list. In the preceding example, you could define two content types, named Specification and Contract. Each content type would include different columns for gathering and storing item metadata, as well as different workflows assigned to them. Yet items of both content types could be stored in and effectively retrieved from the same document library.

Design

Within the design phase the visual designer works with the information architect to transform the design requirements into visual design compositions and to create a style guide once the designs are approved. There are two steps to the design phase, as shown in Figure 2-9. The first is creating the visual design compositions. The second is taking the approved wireframes and adapting them to an approved design direction.

Figure 2-9. Design phase

The visual design composition shown in Figure 2-10 is usually created using photo-editing software like Photoshop. The designer manipulates colors, typography, background images, lines, and other design elements to create a visual interpretation of what the site will look like. This process can take time and is usually achieved in multiple review stages. For the first stage the designer would create a couple of design options for the stakeholders to choose from. These designs might come from a predetermined set of themes. After the first round of reviews, a decision on a particular design direction is typically made. The designer then goes back and makes any additional changes as requested by the review team. After the team is satisfied with the final design, the designer might be tasked with applying that design to some additional wireframe templates to give the front-end developer all of the design attributes and styles needed to build a complete system. Once all of the designs have been created and approved, the designer creates a style guide that defines the colors, fonts, heights, widths, margins, and any other specification that can help the front-end developer build the design.

Figure 2-10. Visual design composition

Development

The development phase, shown in Figure 2-11, is the last of the four phases that we will cover in this chapter. This phase includes the process of taking the final visual design comps and transforming them into a working prototype. During the development phase the front-end developer works with the visual designer to create cascading style sheets (CSS), images, master pages, and page layouts to transform SharePoint based on the wireframes and visual compositions. This process requires a person on your team with a solid background in CSS, HTML, SharePoint master pages, and SharePoint page layouts. It is good if the front-end developer has at least some level of design background; there are likely to be UI detail elements present that require a designer's eye or a judgment call will need to be made on a design that wasn't fully predefined by the designer's comps or the design documentation.

Figure 2-11. Development phase

If custom master pages and page layouts are necessary, the front-end developer also needs to have some experience with SharePoint Designer 2010. The developer can use either SharePoint Designer (SPD) or Notepad to modify the CSS. SPD provides the benefits of color-coding and multiple undo options.

During this phase the requirements, information architecture, wireframes, and visual design compositions have all been approved. Now it is the front-end developer's turn to step in and start transforming those definitions into a working site. SharePoint Designer has multiple panels that the developer can use when creating the HTML and code, as shown in Figure 2-12. You can view the site in three different view modes:

• Design: In design mode you see the site in what is called the What You See Is What You Get (WYSIWYG) mode. The site should look exactly as you see it in the window.
• Split: In this mode the screen is split into two panels; one is the visual WYSIWYG form, and the other is code view.
• Code: This view allows you to see as much of the code as possible.

Figure 2-12. SharePoint Designer 2010

Throughout the four phases there are multiple roles that are needed to support the different tasks. Some of these roles will overlap within the project timeline. In some cases a single person can play multiple roles based on their skills and expertise.