Quick Turnaround Usability Testing

It starts with any number of scenarios: Design and development have taken too long to produce a prototype, you need to release in three weeks, and you suspect there may be design flaws. You are trying to incorporate usability testing into an Agile development process. Or maybe you simply want to pare down your process to make it shorter and less expensive.

Completing usability testing quickly is a challenge anywhere but especially in consultancies, which have to overcome additional challenges, such as learning a new application. To assure success on these projects, I’ve developed a quick turnaround usability testing methodology (QTUT) that minimizes the time needed to complete testing. In Part I of this article, I discuss how to make the first three steps of QTUT—Sales & Kickoff, Recruitment, and Preparation—as short and efficient as possible. In Part II, I will discuss the final two steps: Testing and Analysis & Reporting.

Steps in the QTUT Process

Step 1: Sales & Kickoff
Step 2: Recruitment
Step 3: Preparation
Step 4: Testing
Step 5: Analysis & Reporting

Sales & Kickoff

A new client or a group within your company has approached you about doing usability testing. They need the results next week, which works out to six business days from today. What should you do?

Before a project kicks off, we typically have a number of discussions with the client to understand their goals and deadlines for our engagement. However, in QTUT, each day spent in the sales and kickoff process takes a day away from testing and analysis. To help our sales team conduct initial discussions efficiently, we’ve prepared a one-page guide outlining the do’s and don’ts of QTUT.

One critical “do” for our sales team is that they should discuss the method with the client and immediately set deadlines for our testing results. Starting with the final due date, an experienced tester can work backwards to determine the dates for testing, beginning recruitment, and finishing the test plan.

It’s also important to review expectations with the client. For example, current clients typically expect a certain level of quality in our deliverables. When we compress a week of work into one day, delivering a perfect document or presentation is impossible, so simply reviewing the timeline and discussing how we plan to shorten the process is extremely helpful.

Since the project must start very quickly, our sales staff and project team use part of the kickoff as a working session. During this working session, we develop specific goals, learn what types of results will be helpful, develop an initial list of testing tasks, and learn about the users that we need to test the application. We also compile a list of what we need from the client. Depending on the project, we may need:

  • Information about users for both recruiting and for writing the test script. For example, do people regularly use the application or do they only use it occasionally?
  • Training materials for the application and a subject matter expert who can answer questions.
  • Background information, feedback, or previous testing materials that give context to the current design or may help us to write screeners and test scripts.
  • Access to a stable application, especially when it is under development.

Sales & Kickoff Tips

  • Create a “Do’s & Don’ts” guide to help team members through the process.
  • Avoid clients who are rigid, who prefer not to participate in the process, or who want long reports.
  • Use the kickoff as a working session to learn about the participants and potential tasks.
  • Have a facilitator available with the domain knowledge needed to quickly learn the application.
  • Refine your methodology before you have a project.

Recruitment

Before starting the project, you called several of your favorite recruiters to see if they could meet the deadline. You’ve gotten information about participants during the kickoff meeting, and now you simply need to write a screener in less than two hours!

Recruiting quality participants is a big challenge. There are two key components to recruiting: writing the screener and scheduling the participants. The screener is a list of questions used to filter out participants who are not appropriate for your study. Scheduling involves calling potential recruits, asking the questions on the screener, and scheduling participants who qualify and are available.

Because scheduling is time-consuming, it’s critical to write the screener immediately; in fact, we often start and finish the screener immediately after the kickoff meeting. That’s why it’s important to get information about participants during this meeting.

The level of effort required to recruit depends upon whether you’ve recruited similar participants before and whether you handle the scheduling internally or externally. If you’ve recruited similar participants before, you can reuse the same screeners almost verbatim. To facilitate recruitment for new participant types, we’ve built a list of standard questions so that, at worst, we need to write only a few new questions. In addition, we use a screener template that has our facility procedures, location, and contact numbers; the facilitator need only fill in the specific test questions.

External schedulers. We typically use external schedulers, which is particularly helpful for QTUT, because it takes burden off the facilitator. I highly recommend contacting your external recruiters before agreeing to do a study to see if they can meet the timeline that you need. If at least one of your external recruiters cannot meet your timeline, do not hesitate to ask your client for assistance before agreeing to the study.

Internal schedulers. If you do your own scheduling for QTUT, you may have a list of participant leads in house, so writing a screener isn’t always necessary. However, depending on your timeline and your success rate when calling, it’s often necessary to ask your client or a co-worker to make the calls for you.

You might be tempted to schedule testing sessions very closely together in order to complete more sessions per day. However, we find it more efficient to leave time between sessions in order to quickly debrief and begin analyzing what we observed during the previous session (I’ll discuss this analysis method in more detail in Part II). You may also need the extra time to modify the testing script as needed before the next session.

Recruitment Tips

  • Start recruiting as soon as possible.
  • Create a screener template so that you only need to write the questions.
  • Reuse questions from past screeners.
  • If you do your own recruiting, ask a coworker to make the calls for you.
  • Budget more money than usual when using third party recruiting firms.
  • Screen carefully but avoid particularly restrictive screeners.
  • Schedule backup participants (“floaters”) to cover multiple time-slots in case a participant fails to arrive.
  • Leave time between participants to summarize results and to change the tasks as needed.

Preparation

You’ve started recruiting. You are familiar with the application type but you need to learn this particular application. You need to write the tasks and questions for your test script and you need to clear them with your client.

With recruiting underway, you can turn your attention to learning the application and writing the test script.

One critical note in our sales guide is to avoid aggressive timelines for applications in unfamiliar domains or those which require extensive training. Even if you’ve followed this advice, you will still likely need to learn certain aspects of the application.

It may seem obvious, but you cannot learn an application if you do not have access to it. Often the clients who come to us are still developing the application, so be sure to schedule adequate access to a stable version.

After you’ve had a chance to learn the application, writing tasks and questions for QTUT is similar to a normal study. We rely on client stakeholders more than usual because they help to prioritize testing needs and to identify key tasks. In QTUT, most clients are releasing soon so they’re more interested in finding easy-fix problems than in statistical data or qualitative feedback. Consequently, we tend to focus our effort on creating tasks vs. writing a lot of questions. You also need to consider what you can realistically summarize quickly. For example, if it takes two hours to compile error rates, then eliminate error tracking from your test plan.

We run pilot tests as early as possible because they help us more rapidly iterate and improve the script. Keep in mind that you probably will not have perfected your script when your first participant arrives, so you may need to modify slightly the tasks and questions between sessions.

Preparation Tips

  • Avoid gathering data that takes a lot of time to compile and analyze.
  • Use open-ended questions such as “Tell me about what you did yesterday at work” and allow time for discussion with the participant in order to learn about them during their session.
  • For tasks that require more information that you currently know about participants, use a series of questions to build more realistic tasks.
  • Use Likert-style scales to get data if you need it, and rely less on task completion data (as your tasks may often change).

Next time: Part II

In Part II, I will discuss how to facilitate the sessions, and I’ll describe a novel approach to analyzing and reporting the results.

Information Architecture for Audio: Doing It Right

Content today is increasingly delivered by audio both online and in the real world. We have radio shows and newscasts, and in recent years, podcasts, audio books and navigation/car assistance systems have been added to the field. Audio is more emotional, as sound effects and acoustic atmosphere enhance content to help deliver its messages. It also affords users the opportunity to interact with content while their hands and eyes are busy (i.e. when doing physical work, driving, walking, etc).

However, the inclusion of audio often results in usability issues that make it difficult for users to access and understand content. That is why we need new tools to organize linear content like audio. Luckily, a wide range of techniques employed in information architecture, journalism, usability engineering and interface design are available. All that’s required is the knowledge to combine them effectively. This article presents a practical framework for designing and implementing audio-based content, such as podcasts.

“There is no reason to over-estimate the importance of writing and thereby under-estimate other technologies of information processing.” Harald Haarmann in History of Writing.

The Problem with Audio

When using audio today, we face challenges similar to those of written text about a decade ago. During this time, information was being transferred from hand-held documents to the computer screen, without being optimized for the new online medium. Now the same mistakes are being repeated with audio. Existing text is read by a narrator, or worse, the text is speech-synthesized by a computer. Audio doesn’t function the same way as written text, so its execution is often poor. The main difference between printed text, be it on paper or on the computer screen, is that audio is linear. You can only consume it in a linear fashion and you have to listen to it at a given speed.


Figure 1: Part of the “Web Trend Map by Information Architects, Japan

For example, Figure 1 shows part of the famous “Web Trend Map by Information Architects Japan”:http://informationarchitects.jp/web-trend-map-2008-beta/. It’s an excellent example of how information can be displayed in a two-dimensional space. It’s not possible to use one-dimensional spoken text in the same way. When accessing audio, users have no idea how long the segment will last, unless this information is provided by the interface or the narrator states it at the beginning of the segment. Users only have a vague idea of where they are within the narration. If you don’t have any visual hints it’s difficult to determine how much time is left and what topics are going to be discussed. Finding specific content by rewinding or forwarding is difficult. In contrast, finding the next subsection within a text document is very simple. You can easily find a particular word on a page by scanning it or by using your browser’s find function.

Best Practices for Audio

When beginning an audio-related project, ask yourself whether audio is the right medium for your message. In some cases, text is a better choice and in other cases it’s video. Don’t use audio just because you can. If you are certain audio is the best choice, there are several fields to help inform how you implement it. The most important professions we can learn from include:

  • Information Architecture
  • Journalism
  • Educational Psychology
  • Usability Engineering
  • Interface Design

Information Architecture for Audio

The principles of information architecture are exactly what you need to create usable audio. Your approach to creating audio should be similar to developing a large website. In both scenarios you don’t want the user to get lost or overwhelmed by content. For any informational audio that is longer than a few minutes, follow these guidelines:

  • State the Length: Typically the user has no way to assess the length of the audio segment. Sometimes the length is provided by the interface, but not always accessible. For example, if you listen to a podcast with your MP3 player, it might be in your pocket so you don’t see the time and duration displayed on the device.

  • Give an Overview of the Structure: Informing users how the audio is structured helps them find the content they’re looking for. It also gives them the option to directly locate the information they’re most interested in.

  • Introduce the Topic: An introduction helps set the mood and prepares the listener for the content to come. In printed text, such an introduction might seem hackneyed, but with audio it’s good practice to describe a situation the listener knows from everyday life. It’s better not to jump right into the topic, but instead provide some information about it.

  • Provide Orientation from Time to Time: If the audio is longer than a few minutes, help the user form a mental model of the content by repeating its structure from time to time. Tell the user where they are within the content and give an overview of up-coming topics. For longer audio pieces, consider giving users the option to skip sections/chapters via the interface or offer content in segments.

Journalism for Audio

Radio has been around for more than a century, and most of the best practices from radio journalism are ideal for creating usable audio. Here are some of the most important points.

  • Keep it Short: Ideally, audio narration should be shorter than printed text covering the same subject. If you have three pages of printed text, don’t write three pages of text for the narrator. Since users are unable to easily scan audio content and must listen at the narrator’s speed, concentrate on the most important content.
  • Moreover, the sentences and the individual words should be kept short. It is much more difficult to comprehend a long, complicated sentence read aloud than to read it in print.

  • Repeat Often: Repetition is something you usually try to avoid with written text. With audio, however, it helps to get your point across if the most important facts are summarized and repeated. The key is a summary at the end of the audio. It’s also a good idea to repeat the main subjects or themes rather than referring to them by pronouns or synonyms. The text might seem strange when you read it, but as soon as you hear it, you will realize the audio is easier to follow.

  • Use Mental Pictures: Good journalistic audio sparks the listener’s imagination. It not only makes the piece more entertaining, it also helps the user understand and remember it. Try to create pictures in the listener’s mind. Describe what they might see and feel if they were in your place. For example, let them hear the sounds of the location where your story is set.

  • Take Advantage of the Possibilities: Different styles of speech, tone, speed and dialects can be used to create memorable audio. When the language is too formal, you lose credibility and narration is more difficult to understand.

  • Don’t Overuse the Thesaurus: This is another piece of advice from radio journalism. When you use overuse synonyms, you decrease comprehension. The listener has to decipher the synonyms while the narrator continues talking, so he might not understand some of the text. For example, when referencing Japan, avoid using the terms “Nippon” or “Land of the Rising Sun.”

Here is an example of how to structure an audio sequence:

1. Greeting
2. Introduction (i.e. audio length, what subjects/topics will be covered and how the user can interact)
3. First section of content
4. Describe the structure (i.e. summaries, repetition, overview and acoustic bumpers)
5. Repeat Steps 3 and 4 until all content is delivered
6. Conclusion (i.e. summary or what action users can take next)
7. Farewell

This structure is derived from the typical sequence of a radio show and has been successfully adopted by many podcasters.

Educational Psychology for Audio

Much research has been conducted on reader comprehension and written text, notably the work of Norbert Groeben from 1972 onward. Most of the results show that the techniques from information architecture and radio journalism cited above are also valuable for creating accessible content to be used in an academic setting.

  • Keep Short-term Memory In Mind: It is important to write short sentences and to repeat words rather than using synonyms.
  • Design Audio Content for Different Reading Speeds: Research shows that reading speed varies by individual, depending on age, familiarity with the subject, education and other factors, so it’s important to adapt the complexity and the reading speed of the narrator to your intended audience.

Usability Engineering for Audio

Because audio differs, some of the established techniques used in web development cannot be applied audio. Wireframes, card sorting exercises or eye tracking can be used to evaluate information architecture or interface design, but these techniques do not work for developing and testing audio content. Still, we can borrow from usability engineering when including audio:

  • Design for the Target Audience: It’s still uncommon to apply the techniques of user-centered design to audio, but do convince your design team to produce content for the users, not its creators.

  • Create Personas: Personas are the perfect method for representing your target audience, so use them.

  • Create Scenarios: Usage scenarios are a technique you can successfully apply when creating audio content. It is crucial to understand the user’s:
    • Environment (i.e. quiet or noisy)
    • Access Possibilities (i.e. Do users need to rely on their eyesight or hands right now? When driving or working out eyes and hands are mostly occupied.)
    • Mood (i.e. passive/reclined or active/leaning forward)
    • Expectations (i.e. entertainment or information)
    • Experience (with interface as well as with content)
  • Test With Users: If possible, test early versions with selected users from the target audience. Usability testing in a research lab is best, but informal tests are a good start.

  • Conduct Log File Analysis: Do your statistics. Look at which files are most frequently downloaded (and the least). Correlate the files with their content and then produce more of the successful content types.

  • Consider Users’ Goals & Tasks: Figure 2 shows that audio delivered over the web has a different level of interactivity than, say, just listening to the radio. Apart from listening on demand, users can forward or skip through audio. They may also be looking and interacting with other materials at the same time they are listening.

Fig1
Figure 2: Depending on the context, the amount of interactivity varies.

What’s more, knowing user’s expectations is crucial to creating the appropriate content (Figure 2). With audio this is more important because it is difficult to skip irrelevant information.

Interface Design for Audio

Finally, give careful consideration to the interface that provides access to and control of audio content. Again, the well-known principles of interface design apply. In general, give the user as many hints as possible about what to expect from the audio—before he even starts listening.

  • Provide a concise description of the content.
  • When linking, make it clear that an audio file is linked.
  • Explain how to locate content within the audio piece, if possible.
  • Include metadata (i.e. ID3 tags in MP3 files that are shown within the playback software, as well as on portable devices).


Figure 3: Podcast page of “The New Yorker website”:http://www.newyorker.com/online/2008/08/11/080811on_audio_grann?xrail

Figure 3 shows the podcast page of the The New Yorker magazine. Much of the information on how to subscribe to the podcast and how to download the audio file is in text. Some short links at the end of the paragraph might work better.


Figure 4: Metadata in iTunes

Above is a good example of metadata displayed via iTunes (Figure 4). Note the long description; it’s concise but not suitable for scanning.

Conclusion

Creating usable audio is not difficult when you follow a few simple rules. These mostly stem from the creation of usable content in the form of text. Information architecture, journalism, educational psychology, usability engineering and interface design provide plentiful tips for doing so. Most of the methods used in these fields can be applied to the creation of audio. To summarize, the main guidelines for usable audio are:

  • Write with your audience in mind.
  • Structure your content by providing an overview at the beginning and giving an introduction to longer audio pieces. Be sure to include a summary at the end.
  • Follow the rules of radio journalism for creating easily understandable narratives.
  • Rely on a familiar interface or put your design in front of users if you digress from a familiar practice.

If you follow these tips you will be able to create audio that is easily accessible, engaging and helps to communicate your message, not only intellectually but also emotionally. After all, emotional quality is one audio’s main advantages over text.

UX Design-Planning Not One-man Show

A lot of confusion and misunderstanding surrounds the term "user experience." The multitude of acitivities that can be labeled with these two words span a vast spectrum of people, skills and situations. If you ask for UX design (UXD), what exactly are you asking for? Similary, if someone tells you they are going to provide you with UXD for an application, website or intranet or extranet, what exactly are you going to get?

Is it just one person who is responsible or is it a team of people who are in charge of UXD? In this story I´ll sketch my ideas of UXD based on my experiences and at the end of this story I will give you my answer.

Let us start at the beginning – UXD starts with experience – experience of the users. And so I will talk about the users first.

 

 

UXD-P – every person is an individual

Every person is an individual. Every person is in possession of different roles. For each individual there will be many roles and each person adopts a different role depending on the circumstances.

roles of experiences

User Roles

Sometimes the individual person holds one role, but mainly he will hold quite a few roles like consumer, customer, user, client, investor, producer, creator, participant, partner, part of a community, member, and so on.

 

 

UXD-P – network of expectations, experiences and knowledge

Every user is multi-faceted – and is considerably more complex than they themselves can imagine – so it´s not very helpful just to talk to the user or ask him what he needs. We have to watch what people do; we have to listen to what people say and to recognize what decisions people make – and by observing we have to evaluate and understand why they do this and that. Why and what kind of visual elements will the user like, prefer and or understand? Why and what kind of mental model, navigation or function do they respond to?

Jakob Nielsen said “To design an easy-to-use interface, pay attention to what users do, not only what they say. Self-reported claims are unreliable, as are user speculations about future behaviour.” (Jakob Nielsen – Alertbox) and I agree – I think no statement can be objective. Perhaps the circumstances are not realistic or not reasonable for the person. Or maybe the person himself is not really in the “situation,” or he is being influenced by other factors (trying to please the tester for example). Or maybe he is trying to succeed with the test rather than trying and failing, which tells us so much more.

When all three perspectives (do, say, make) are explored together, we are able to realize the experience spectrum of the “normal” user/customer we are working for.

Jesse James Garrett said: “User experience is not about how a product works on the inside. User experience is about how it works on the outside, where a person comes into contact with it and has to work with it” (J.J.Garrett – The Elements of User Experience) .

areas of experiences

Experiences

Areas of experiences: different areas which effect the quality of communication

 

 

UXD-P – personal and individual

When we talk about experiences, we take the individual into consideration, including the subjective occurrences felt by the person who has the “confrontation” with what we want them to use. Experiences are momentary and brief – sometimes they are part of a multi-layered process or they are on their own.

Normally such know-how has been learned as a part of something or by itself and will be remembered in the same way – but that’s not always the case – and the person deals with the situation in a different way. If we look at their exeperience as a continuum, the user brings their experiences of the past to the interaction in the present and adds their hopes for the future. That future could be: to interact with their banking in a safe and secure way.

flow of experiences

Flow of Experience

Flow of experience: the individual user/customer is always in the present – they act in the present. They are influenced by former experiences and current expectations.

UXD-P is taking the users’ views, behavior, and interactions, to figure out the emotional relationship between them and the thing we have built. For the most part these "people" and their experiences are unknown. It requires an appreciation of the customer: their journey, their personal history and their experiences.

It is the collective set of experiences, in the online-world, the offline-world, or even tiny little things (i.e. My coffee was cold this morning) that affects their experience of the products and the companies that represent them. It is about appreciating the individual user’s unmet needs, wants, capabilities and desires in a contextual way. It´s a box of experiences including the things the user saw, acted and felt. (BBC Two [12th February 2008, 9pm, BBC Two] had a program on rational thought. Highlights of the program include: Loss complex, Post-decision rationalization, Priming, Precognition. Watch highlights from the programme : http://www.bbc.co.uk/sn/tvradio/programmes/horizon/broadband/tx/decisions/highlights/ )

Experiences and expectations meet in the present. Both are inseperably combined, and every action we take takes both parts into consideration. When a person uses an application, he tries to understand what happens. He will always try to reference this to his past experiences. The moment is also tightly coupled to his expectations of his personal outlook.

At this point of “present” I think of the UX honeycomb of Peter Morville [1] …

honeycromb – Peter Morville

Morville’s "honeycomb"

honeycomb – Peter Morville (P.Morville – Facets of the User Experience)

In the present we have to deliver to the individual user and his specific task the best answers to following questions.

  • Is the application useful for the individual user and his specific task?
  • Is the application usable for the individual user and his specific task?
  • Is the application desirable for the individual user and his specific task?
  • Is the application valuable for the individual user and his specific task?
  • Is the application accessible? Available to every individual user, regardless of disability?
  • Is the target findable for the individual user and his specific task?
  • Is the application credible for the individual user and his specific task?

In the UXD-P the whole team has to take the users’ views of the GUI and the interactions to figure out the emotional relationship between the brand and potential customers. It requires a common appreciation of the customer journey and their personal history: not only with the product and similar products, but also with similar experiences.

 

 

UXD-P – teamwork and cooperation

The first stage in discovering – to invent or design for the experience – is to take a new viewpoint about the people who buy and use the products and services we are designing. This is a birdseye view and from step to step we have to use the "mouseview," which is to say a detailed view from the user’s perspective, as we develop the application we have to switch between these views. Our main desire is to to respect, value, and understand the continuum of experience and expectations our users have .

UXD-P can sometimes be a slippery term. With all the other often used terms that float around: interaction design, information architecture, human computer interaction, human factors engineering, usefulness, utility, usability and user interface design. People often end up asking, “What is the difference between all these fields and which one do I need?” If the UXD is aimed to describe the user’s satisfaction, joy or success with an application, product or website, however we specify it, there are a few key essentials which need to be tackled and I have to point out the UX honeycomb of Peter Morville [1] a second time. Each of these points, as enlightened above, makes up a considerable component of the user experience. Each is made effective due to the design offerings from each of the following elements:

Usefulness is based upon utility and usability. This means the product is able to give exactly the right kind of service and what the user is expecting from it. And it´s the joy of reaching my aims and the joy of doing so easily. The information architecture is in charge of clarity of the information and features, lack of confusion, a short learning curve and the joy of finding. The designing of the interaction is essential for a successful and overall satisfying experience. So the interaction design has to answer the questions of workflow, logic, clarity, and simplicity of the information. Visual design is responsible for the clarity of the information and elements, simplicity of tools and features, pleasant or interesting appearance of the interface, the visual hierarchy, and the joy of look and feel. Accessibility is a common term used to describe how easy it is for people to use applications or other objects. It is not to be mixed up with usability which is used to describe how easily an application, tool or object can be used by any type of user. One meaning of accessibility specifically focuses on people with disabilities: physical, psychological, learning, among others. Even though accessibility is not an element of its own, it is important to notice that accessibility also plays a role on the whole user experience to increase the likelihood of a wide-ranging user experience. People tend to gravitate to something that is easier to use regardless of who it might have been designed for.

The UXD innovation process is a nonlinear spiral of divergent and convergent activities that may repeat over time. Any design process begins with a vision. This applies particularly to the UX process. A vision, however, is not enough to start design. As I mentioned before, we always have different circumstances, users and roles. Therefore, it is critical to accurately understand the end user’s needs and requirements – his whole experience and expectations. The UX process relies on iterative user research to understand users and their needs. The most common failure point in UX processes is transferring the perspective of users to UI design. The key is to define interaction first, without designing it. First, all the research (the user, product and environment) have to be organized and summarized in a user research composition. These lead to user profiles, work activities, and requirements for the users. The user research composition feeds directly into use cases. The use cases show steps to accomplish task goals and the content needed to perform interactions. Completed use cases are validated with the intended user population. This is a checkpoint to see if the vision is being achieved and the value is clear to users and the project team. The next step is to design the user interface, generating directly from the interaction definition. A primary concern with design is to not get locked into a single solution too early. To keep the project on time, this step should be split into two parts: rough layout and exact and detailed design. The rough layout allows experimentation and rapid evaluation. Detailed design provides exacting design and behavior previews of the final application that specify what is to be coded. Iterative user evaluations at both stages are connected to be fast and effective in improving GUI, design feedback, rapid iterative evaluations, and usability evaluations.

UX workflow cycle

Image_7

design workflow – workcycle – workspiral

 


 

 

UXD-P – Gathering the elements

The diagram below presents the relationship of the elements above:

elements of UXD-P

Elements of UXD-P


Lewin’s equation

Lewin’s Equation, B = f (P,E) ( B – Behaviour; f – Function; P – Person; E – Environment ), …

… is a psychological equation of behaviour developed by Kurt Lewin. It states that behaviour is a function of the person and his or her environment [2].
There is a desired behaviour that we need to encourage, but we have no control over the person, so via interaction design, information architecture and interface design we control the environment and therefore generate the desired behavior. (see reference: books.google.com ).

 

 

UXD-P – many steps to go but every step is worth it

How do we involve our team, customer and our user/consumer? We can start at different points, but I like to think about the circumstances first. Where do we come from? Where are we? Where will we go? And who is “we”? “We” means each person who is involved in the project. Iin the centre of each effort stands the user. To get the user with his personal experiences and expectations into the project, the design team and the customer needs a combining glue / tool / instrument. I believe these are the personas of the “target users/consumers” in the process of UXD-P. If there are no personas the second or third choice are scenarios or the workflows (based on a certain user/person).

The management point of view for the most cases is also the view of our customer. It includes the user’s/consumer’s age, income, gender and other demographics. The perspective of UXD-P is to look at behaviour, goals and attitude.

To get a realistic persona we have to identify first of all the target users. Out of my experiences this is not only the task of our client to define the users and consumers – we have to support him. During the identification and characterization we have to go beyond demographics and try to understand what drives individual users and consumers to do what they do and these as detailed in quantity and quality as necessary and possible – like I mentioned above. The approach and the complexity of the characterization depend on the tasks, project and functionalities. Parallel to the very personal description we need a “picture” of the environment. For each persona we must define their business and/or their private concerns and aims. Do they want to research a product for purchase later? Are they concerned about not wasting time primarily? Do they just want to purchase something online as easy and quick as possible?

Depending on these personas we can formulate, discuss and prove scenarios – from the very beginning of the project, during the project and as check or analysis at the end of the project.

 

 

 

 

 

UXD-P – my blueprint of schedule – "todos" and deliverables

We are always asking and being asked: what are the deliverables. Throughout my career as an IA, UX-planner and designer, as well as during my study of architecture and town planning, I have constantly asked myself following the questions:

  • What kind of project is it? What are the key points?
  • What should our steps and milestones be in the project?
  • What should our/my deliverables be?
  • How can we/I explain the main idea?

I have realized that if I do not answer these questions previous to creating a deliverable, I waste more time and deadlines slip.

The deliverables are not for us. The deliverables are a means of communication with several people: manager, decision maker, client, designer, front-end developers, back-end developers, etc. Sometimes I have the feeling we overlook this from time to time. After I think about the project I have to ask myself, where will my deliverables and other efforts fit within the process of design? The following diagram describes different lines of work that will lead us to some questions each line must accomplish. Depending on these questions and topics I will outline the basis, basics and deliverables for which each skill and ability which is necessary.

Image_6___schedule of UXD-P_small version

Image_6

schedule of UXD-P ___ better view – schedule 1238px x 1030px

 

UXD-P – my conclusion

I studied architecture and town planning. And just like town planning and architecture isn’t just for architects and art lovers, the internet isn’t just for computer users and developers. Similarly, just as the towns and the cities are for the inhabitants and architecture is for the users of a building, so products and applications are for the user, the customer, the member and not for the people who build them.

In every kind of process we should act in a team but in the process of UXD-P it is absolutely essential that we have to think parallel, with the same focus . We have to act in a team, although every team member is a kind of lawyer: lawyer of budget, of the client, of utility, of usability, of look and feel, of brand and finally of the user himself. Because at the end of the project, our user/customer is the final judge.

Good design is not only interface, or look and feel, or technology, or hardware, or how it works. It is every detail, like the structure, the labelling, the border of a button or a little icon. Finally, it is the sum of every element. I believe that a shared vision of a group of creators will have more potential than individual creativity. And that is the point where creativity meets expectation. The point of view on IA and design and the process to get to a well-designed product will be changed by UXD-P.

The persons who use the application or other object that we invent are the real “architects” of the “architecture” – the real “inventor” of the design. The more we know about our users, the more likely we are to meet their needs.

As the capabilities of interactive applications and the internet go forward and grow, more and more consumers use the applications and the various possibilities in new and different ways. We must think about all aspects of user experience.

And I will ask you once again: Is it just one who is responsible or is it the team which is in charge of UXD-P?
Personally, I believe it is the process of planning and designing for User Experiences (and so I think it’s the team which is in charge), but the overview has to have an experienced planner as a kind of captain.

 

The most common cause of an ineffective website (one that doesn’t deliver value to both the business and its intended constituents) is poor design. The products have to follow, to cover the functions and the experiences. The lack of clear organization, navigation and values of brand and mood mean that people will have an unintentional and maybe bad experience, rather than one that will meet the business’s relationship objectives for each individual. User experience design and planning is a fundamental component to the creation of successful digital products, applications and services.

UXD-P is UXdesign and planning- – In my estimation there are distinctions between Design and Planning.

Design is usually considered in the context of arts and other creative efforts. When I think of design in the UX process it focuses on the needs, wants, and limitations of the end user of the designed goods, but mainly on the visual parts and the mood. A designer has to consider the aesthetic-functional parts and many other aspects of an application or a process.

The planning part provides the framework. The term "planning" describes the formal procedures used in such an endeavors, such as the creation of documents, diagrams etc. to discuss the important issues to be addressed, the objectives to be met, and the strategy to be followed. The planning part is responsible for organizing and structuring to support utility, findability and usability.

I strongly believe that both parts – design and planning – have to work closely together. Every team member should have the ability to think cross-functionally and to anticipate consequences of activities in the whole context.

I’ve often seen timelines like this …

Image_8___

and this doesn´t work for UXdesign and planning …

I give a timeline the preference which looks like this:

Image_9___

… to develop a UXdesign and UXplanning.

And in the center of this team and of this process should stand the leading person – the user!

Image_9___basis points of UXD-P

 

 

 

[1] _ UX honeycomb of Peter Morville

semanticstudios.com-publication

 

 

[2] _ The Sage Handbook of Methods in Social Psychology _ by Carol Sansone, Carolyn C. Morf, A. T. Panter

google-books (The Sage Handbook of Methods in Social Psychology)

amazon.com (The Sage Handbook of Methods in Social Psychology)

 

Extreme User Research

What is the biggest problem I face almost every time a client hires me to do something about a web project going awry? They don’t know a thing about their users. They don’t have a clue, whatsoever. Unbelievable but true!

Good designers will certainly argue that THEY don’t need user data to do proper design. That if THEY like it, EVERYBODY will… sure! This probably explains why so many web projects fail in so many levels: Usability, aesthetics, emotions, and profitability.

What’s the remedy to this world-wide infection? User research… but not in the typical version, meaning lengthy ethnographic studies that seem to take forever before obtaining some data. I’m talking about a simpler way, a faster way of doing it. I call it "extreme user research." What’s so extreme about it? Well, it can be done in 30 minutes per interviewee, and it generates loads of useful data that will have a real impact on design, thus making your website more profitable.

Getting information from surrogate users

Doing user research doesn’t have to be tedious and cost lots of money. In many cases, you should be able to do it in a few days, even a few hours, depending of the scope your project. The main idea behind extreme user research is that instead of going for the real users, we go for surrogate users. Those are the ones within a company who talk directly to the customers. We want to talk to the people who talk to the people.

For instance, let’s say we do an e-commerce project for a cable company. The surrogate users would be those in the call centers—the first-line personnel who provide information about products and the second-line personnel who provide customer support for billing issues and technical problems. Talking to those people means having access to tens, hundreds, or even thousands of clients. Not bad at all!

Doing extreme user research is simple. We simply perform individual semi-structured interviews that last no longer than 30 minutes. This time limit is a profitable constraint. It adds a stress that forces the interviewee to focus on the core, on the essentials. During those 30 minutes, we want to know as much as possible about the customers:

  • What triggered the call? For example, was it a problem, advertisement, word of mouth, season, news in the media, life event like a birth, the first job, moving to another place?
  • What is the whole purpose of the call?
  • What are the callers’ main concerns? Are there any misconceptions or incomprehensions about the company’s products or services?
  • What words do the callers use to express their needs?

Do what people do during speed-dating sessions: Focus on the essence. Ask for the top ten questions from customers. Ask for the five things you should know if you’d have to replace a surrogate user for an afternoon. You’ll see, it works!

Go for the individuals. Don’t, I repeat don’t go for group interviews, the infamous focus groups. Otherwise, you’ll have to deal with strong-minded individuals whose influence biases the group and thus the whole process.

How many surrogate users should you interview? About five per job description. You want a certain degree of repetition among the interviewees to avoid anecdotes or personal perceptions. Because of the speed factor, you can interview up to 12-14 people in a single day, which means more than 60 interviews in a week! Yes, these will be long days. Yes, at a certain point, it will be tedious to hear the same thing over and over again. But that’s the whole point. We want to make sure we have solid data based on facts, not perceptions.

Okay. Now, you have done your 40 interviews. You’re swamped with data. What’s next? Well, all you have to do is:

  1. Extract all the facts that you’ve found.
  2. Write them on sticky notes.
  3. Tag each note appropriately using a word or a symbol. I usually use words like user, goal, trigger, concern, FAQ, love factor, hate factor, and incomprehension. These tags will really help you later on for documentation. You can also use different colored sticky notes for this purpose.
  4. Find patterns and create groups around types of users.
  5. Create some first-version personas and then refine them.
  6. Show and tell everyone about your findings.

Designing using facts, not opinions

During the Québec city website redesign (which is not yet online), we interviewed five call-center employees and discovered that citizens interact mostly with city hall for:

  • their home (garbage collection and recycling, permits, taxes)
  • their street (parking, lighting, pavement and road works, snow removal)
  • public services schedules (library, swimming pools, skating rinks, etc.)

Knowing these interactions really helped us focus on what citizens really need. Garbage collection by definition is not very sexy, but when 30% of the calls are about this topic (based on interviews and call log analysis), it becomes clear that the city website has to address this subject before anything else!

Call-center personnel also told us that citizens always ask the same four questions about a topic:

  1. How to get a service from the city? They want to know the procedure (for example, how to get rid of an old sofa).
  2. When is it going be done? What is the schedule?
  3. How much does it cost?
  4. Who’s in charge?

Having this information helped us design page templates with placeholders answering those four questions. It’s that simple and straightforward.

Conclusion

Knowing, I mean really knowing your users has great benefits. Your design will be based on facts, not on suppositions or false perceptions.

Knowing your users means that you’ll spend money on what users really need, NOT on what you suppose they would need or like. It usually leads to simpler solutions. Having facts reduces those never-ending discussions where everybody has his own solution based on his own personal needs and preferences. It has been said before but I’ll say it again: We, the designer and the client, are NOT the users.

Get out of your cubicle. Get out of your meeting room. Go and get those surrogate users and know as much as you can about your users. You’ll see: Your users are not who you think they are.