User-centered design

Visibility helps the user construct a mental model of the document. Models help the user predict the effect(s) of their actions while using the document. Important elements (such as those that aid navigation) should be emphatic. Users should be able to tell from a glance what they can and cannot do with the document.

Users should be able to find information quickly and easily throughout the document, regardless of its length. Users should be offered various ways to find information (such as navigational elements, search functions, table of contents,[15] clearly labeled sections, page numbers, color-coding, etc.). Navigational elements should be consistent with the genre of the document. ‘Chunking' is a useful strategy that involves breaking information into small pieces that can be organized into some meaningful order or hierarchy. The ability to skim the document allows users to find their piece of information by scanning rather than reading. Bold and italic words are often used to this end.

Text should be easy to read: Through analysis of the rhetorical situation, the designer should be able to determine a useful font-family and font style. Ornamental fonts, text in all capital letters, large or small body text can be hard to read and should be avoided. Text-colouring and bolding can be helpful when used in text-heavy scenarios. High figure-ground contrast between text and background increases legibility. Dark text against a light background is most legible.

Certain types of languages are needed depending on the rhetorical situation. Short sentences are helpful, as are well-written texts used in explanations and similar bulk-text situations. Unless the situation calls for it, jargon or heavily technical terms should not be used. Many writers will choose to use the active voice, verbs (instead of noun strings or nominals), and a simple sentence structure.

During the UCD process, a Persona representing the user may be created. A persona is a user archetype used to help guide decisions about product features, navigation, interactions, and even visual design. In most cases, personas are synthesized from a series of ethnographic interviews with real people, then captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to bring the persona to life.[16]

For each product, or sometimes for each set of tools within a product, there is a small set of personas, one of whom is the primary focus for the design. There is also what is called a secondary persona, where the character is not the main target of the design, but their needs should be met and problems solved if possible. They exist to help account for further possible problems and difficulties that may occur even though the primary persona is satisfied with their solution. There is also an anti-persona, which is the character for which the design is specifically not made.

Personas are useful because they create a common shared understanding of the user group that the design process is built around. Also, they help prioritize the design considerations by providing a context of what the user needs and what functions are nice to add and have. They can also provide a human face and existence to a diversified and scattered user group and help create empathy and add emotions when referring to the users. However, since personas are a generalized perception of the primary stakeholder group from collected data, the characteristics may be too broad and typical or too much of an "average Joe". Sometimes, personas can have stereotypical properties, which may hurt the entire design process. Overall, personas can be a useful tool to be used by designers to make informed design decisions, as opposed to referring to a set of data or a wide range of individuals.

Personas can also be modified all through the UCD of a product, based on user testing and changing environment. This is not an ideal way to use Personas but should not be a taboo either, particularly when it becomes apparent that variables surrounding a product's development have changed since the design started and current persona/s may not cater well to the changed conditions.

A scenario created in the UCD process is a fictional story about the "daily life of" or a sequence of events with the primary stakeholder group as the main character. Typically, a persona created earlier is used as the main character of this story. The story should be specific to the events that relate to the problems of the primary stakeholder group, and, normally the main research questions the design process is built upon. These may turn out to be a simple story about an individual's daily life. Still, small details from the events should imply details about the users, and may include emotional or physical characteristics. There can be the best-case scenario, where everything works out best for the main character, the worst-case scenario, where the main character experiences everything going wrong around him or her, and an average-case scenario, which is the typical life of the individual, where nothing really special or depressing occurs, and the day moves on.

Scenarios create a social context in which the personas exist and create an actual physical world, instead of imagining a character with internal characteristics from gathered data and nothing else, there is more action involved in the persona's existence. A scenario is also more easily understood by people since it is a story and is easier to follow. Yet, like the personas, these scenarios are assumptions made by the researcher and designer and is also created from a set of organized data. It is important to ensure that scenarios are created as close as possible to real world scenarios. Nevertheless, it can sometimes be difficult to explain and inform how low level tasks occur, for ex- the thought process of a persona before acting.

In short, a use case describes the interaction between an individual and the rest of the world. Each use case describes an event that may occur for a short period of time in real life but may consist of intricate details and interactions between the actor and the world. It is represented as a series of simple steps for the character to achieve his or her goal through a cause and effect scheme. Use cases are normally written in the form of a chart with two columns: first column labelled actor, second column labelled world, and the actions performed by each side written in order in the respective columns. The following is an example of a use case for performing a song on a guitar in front of an audience.

The interaction between actor and the world is an act that can be seen in everyday life, and we take them as granted and don't think too much about the small detail that needs to happen for an act like performing a piece of music to exist. It is similar to the fact that when speaking our mother tongue, we do not overthink about grammar and how to phrase words; they just come out since we are so used to saying them. The actions between an actor and the world, notably, the primary stakeholder (user) and the world in this case, should be considered in detail. Hence, use cases are created to understand how these tiny interactions occur.

An essential use case is a special use case, also called an abstract use case. Essential use cases describe the essence of the problem, and deals with the nature of the problem itself. While writing essential use cases, no assumptions about unrelated details should be made. In additions, the goals of the subject should be separated from the process and implementation to reach that particular goal. Below is an example of an essential use case with the same goal as the former.

Use cases are useful because they help identify useful levels of design work. They allow the designers to see the actual low level processes that are involved in a certain problem, which makes the problem easier to handle, since certain minor steps and details the user makes are exposed. The designers' job should be to take into consideration these small problems in order to arrive at a final solution that works. Another way to say this is that use cases break complicated tasks into smaller bits, where these bits are useful units. Each bit completes a small task, which then builds up to the final bigger task. Like writing code on a computer, it is easier to write the basic smaller parts and make them work first, and then put them together to finish the larger more complicated code, instead of tackling the entire code from the very beginning.

The first solution is less risky because if something goes wrong with the code, it is easier to look for the problem in the smaller bits, since the segment with the problem will be the one that does not work, while in the latter solution, the programmer may have to look through the entire code to search for a single error, which proves time-consuming. The same reasoning goes for writing use cases in UCD. Lastly, use cases convey useful and important tasks where the designer can now see which one are of higher importance than others. Some drawbacks of writing use cases include the fact that each action, by the actor or the world, consist of little detail, and is simply a small action. This may possibly lead to further imagination and different interpretation of action from different designers.

Also, during the process, it is really easy to oversimplify a task, since a small task derived from a larger task may still consist of even smaller tasks which were missed. Picking up a guitar may involve thinking of which guitar to pick up, which pick to use, and think about where the guitar is located first. These tasks may then be divided into smaller tasks, such as first thinking of what colour of guitar fits the place to perform the piece, and other related details. Tasks may be split further down into even tinier tasks, and it is up to the designer to determine what is a suitable place to stop splitting up the tasks. Tasks may not only be oversimplified, they may also be omitted in whole, thus the designer should be aware of all the detail and all the key steps that are involved in an event or action while writing use cases.