Website User Experience Analysis: Designed for multidimensional users

Intermediary transaction SEO diagnosis Taobao guest Cloud host technology Hall

The author of this article Stephanie Troeth is a user experience strategy expert, in this article, the author introduced a very novel user experience tool, can be said to be a method. This method combines the axes and the matrix graph, makes up for the user's role, the user journey, the mental model and so on the common user modelling method insufficiency, and through an app design brings the reader to feel one of the unique. This approach is easy to use, very suitable for small team agile development, but also for large team members, stakeholder exchanges, reduce communication costs.

Original link:

Http://uxdesign.smashingmagazine.com/2013/03/12/design-multifaceted-user

It's a tricky thing to focus on the user at all times when designing. Not only do we have to be clear about who our users are, but we need to quickly transform our understanding of the user into a well-designed product. This is usually not easy to do.

Currently, the User experience tool we use tends to focus on who is our user. I think this is a way of using traditional marketing and market research. A few years ago, I stumbled upon a different approach, and the effectiveness of this method has been confirmed in my project. This approach is also handy when building value propositions and describing assumptions we make about user behavior. And I like it the most important thing is that it can help me to complete the product priority design decisions.

So let me start by saying where the current toolset is imperfect, and then I'll take you through a case that uses this new method. After reading this article you should be prepared to try this method yourself.

We are faceted (we Are multifaceted)

Stand in the user's perspective and think about it. A friend recommends you join a group of Facebook, and the theme of the group is that you all like two. If you are the kind of shy person like me, you may dive for a while, and when you become familiar with the dynamics of the group, slowly you will have the courage to comment and share the connection.

Imagine, you accidentally read a post on your blog that you're interested in, where someone has responded, but you can't agree with him-I bet if you happen to get fired, you'll just have to refute it, rather than take a moment to look at the comments. You're still the same person, but your reaction to one thing depends on what it is and what happened at the time, which is normal.

What does this mean for designers? For me, this means that my deliverables are too detailed for "who is our user" rule. A deeper understanding of the multiple contexts in which the user is situated (different environments produce different behaviors and decisions) may be better.

In short, most of the tools we use now seem to focus on the people themselves rather than predicting the user's possible response. But the point we are ignoring is precisely where designers should design effectively.

Personas (personas), User Journey (username journeys), mental model (mental models)?

Personas are created from a reasonable research approach, and content is refined from several representative user images. Personas have many advantages, especially when it comes to determining who is our user, it can build a common language among many stakeholders.

User Journeys and experience maps (experience maps) reveal potential paths for users to use Applications (creator) and Web sites. They are helpful to understand user flow (flows) and to transform user demand to function.

Both of these tools, and the tools they derive from them, are a deep reflection on the user. The user journey can describe what the user is likely to do, but does not explain why the user is making such a decision. Through personas, you can gain a certain level of user background and activity information, but the information you need is only as good as the current design, and it's clear that personas give you more than you need.

Consider what you actually include in your typical design process. At any stage, your design needs to meet different activity flows (flows). As designers, what makes us break down is that we have to translate a series of complex user behaviors into quantifiable feature sets and actually adapt to the product management plan.

It is very difficult to apply personas and user journeys to research and describe these complex user behaviors and to ensure the portability of the entire process.

Of the three tools mentioned above, the closest approach we use is a mental model that can help you generalize the user's intentions and tasks. However, the mental models used are often not visually revealing the contents of different scenes.

So far the problem remains: what can we do to ensure that product positioning and interface design conform to the user's decision model (decision patterns) when the user's behavior and motivation change within a certain range?

User group build module (modelling user groups)

Finally, by chance, in a guest speech, I heard the solution I was looking for, the speaker was David Rollert, my friend and colleague, and a seasoned designer.

On that day, David drew in a series of user experience tools to attract students from all the intelligent design engineering majors, which included a way to create user groups (groups of users). He used a dating site as an example to show how to define critical dimensions (dimensions) for user groups. (Figure 1 Population dimensions, figure 2 liking dimensions) This step is no different from the way we normally use to create user roles. After David's permission, the following refers to the picture on his slide.

The next step is to explore the model (patterns). David combines the two dimensions above and illustrates a set of 3x3 matrices that show the relationship between the user's immediate goals and the roles they want to play. To fill the blanks in the Matrix, David asked the question: "What is the demand for each group?"

Similar user modeling methods are mentioned in the "A Project Guide to UX Design" (chapter 6th, page 90th) written by Russ Unger and Carolyn Chandler, but only in a few words. In addition to emphasizing the need for real user studies, other than our usual practice-creating user groups based on "Who is the user" rather than "what the user wants" or "what drives them".

I think it's very interesting. If we don't ask, "Who are these users?" It's a different way of asking. For example, "What do users in this group want to do?", "What do they need to know?" In the next few projects, I began to use this approach in my work. And the results have proven to be very effective in many ways.

Before proceeding further, I would like to point out that this method is not the final deliverable. This draft cannot be taken to the customer or Product manager for signature. This is only a method that is useful in workshops and in discussions with stakeholders.

Explore assumptions made to users

User has become a load word (loaded word). We always attach our beliefs, interpretations, and emotions to the "users" and their needs. After several teams, I became aware of a pervasive problem: not all stakeholders and team members understood the word "user" the same way. This is why having a set of user roles internally can solve the problem of language communication well.

The problem with user roles, however, is that it simply presents a single specific user scenario and is not the best tool to study a series of sequential user scenarios.

The method of matrix diagram helps us to study known and unknown user behavior and motivation through different scene perspectives. I've done the following things in this way:

Create a key audience role

Understand or validate value propositions

Identify areas of priority research and product functionality-Identify information we know and lack of data

Find out which features are very important

Its essence is a structured brainstorming tool for understanding user patterns. The best thing about it is that it's easy to "unzip" (unpack) the assumptions that different stakeholders make to the user.

The first step: Draw a matrix diagram

I have used this method of thinking on many occasions in my interactions with customers and workshop participants, and the 3x3 matrix is the most effective for me. It may be because it gives me enough samples, and it's not too precise--so it avoids analysis paralysis.

Step two: Identify the important axes

The next step is to determine which of the different users (the different user groups represented in the matrix grid) can be included in the system we are designing.

Let's look at a potential social application designed for runners. Local running users can post running routes, and visitors can find the route by application.

We can imagine the virtual competition factor. A running user sends a running time message at a certain time, and when you see it, you want to break his record on the same route. Or, when you get to a new city, try to trot out a little bit to get a glimpse of the city. Imagine what behavioral attributes we need to satisfy the user to entice users to use this application?

I prefer to choose the opposing attribute. You may not agree with my point of view and then list the following properties and corresponding user scenarios.

Explore (explorative)

"I want to run and find a new way to feel the city," he said. ”

Competition (competitive)

"I want to race with others or I want to go beyond myself." ”

Frequent (frequent)

"I often run, several times a week or even once a day." ”

Occasionally (occasional)

"I run once a week, or less. ”

Your axis might be like this:

Interested in (curious) ↔ in use (engaged)

Social (social) ↔ personal (individual)

Exploration (explorative) ↔ competition (competitive)

Frequent (frequent) ↔ occasionally (occasional)

Visitors (visitor) ↔ native (local)

For the project you are working on, you may know a little about the current user, or you may not know anything about it. The team that worked with us for this social-application ideas belonged to a sports shoe company, and it was made up of runners who often went to marathon races around the world. The team has done some research before, and has gained some information about people from novice to senior runners at all levels, and has some insights into the people who have used a Web application they've developed.

When you practice with this method, keep in mind what you know about the user information and what you assume. Select two of the axes listed above that you are most interested in, or that you think is worth delving into. If you've just come in contact with this method, you may have a problem with your choice, and the best thing to do is to select two at once to see what happens. If this direction doesn't work, change the coordinates and try again.

Step three: Identify key issues

I compare this step to "the Magic 8 Ball" ("Magic 8 Ball"). Usually I start asking questions, "What are these users likely to want to do?" or simpler questions like, "What do they want?" The second question contains what users want and what they might want to do two points. You can also ask, "How does the user feel?" As an intensive exercise. When you think about the problem, write down what you think and use it later. In this case, our question is, "What can they do?" Or from the user's point of view, "What can I do with this software?"

Fourth step: Fill in the form complete

Do your best to complete the matrix. If you've got some insights in the study, you can mark out what you know and what you think is right but not supported by evidence. In general, when you fill out the first matrix, you'll figure out the following two things: what information do you already know about users? What do you need to do next?

Fifth Step: Iteration

When you have finished the above matrix, put it aside and draw a table. There are one or two things you can do:

1. Choose one of the questions you list, such as "What do these users want from us?" Or，

2. Keep the problem unchanged and replace one of the axes with another.

After you finish drawing the form, fill in the matrix form, and remember this step this is a brainstorming process. The idea of a quick record for later refinement is more important than wasting time, so don't use it for too long each iteration.

Once you have done your best to complete this iteration, repeat the following steps: Select a question, or change to another axis.

In this step, your team members are best to align their views on the choice of issues and coordinates.

Perfect and repetitive. You'll find that a lot of matrix graphs can be completed in just one hours, even if the progress is slow at first.

Analysis & Main points

After finishing the work, you should start looking for "mode" (patterns). Let's look at what might happen:

Hypothesis (assumption) VS. Knowledge (Knowledge)

Remember one thing--I have to repeat it again--when you and your team write it down, all you have is a summary of a bunch of complex assumptions. When you are discussing any conclusion, it is clear that you are talking about a number of different levels of potential facts (potential truth). Keep in mind that these can effectively avoid getting bogged down in the details of excessive discussion.

With the matrix, it's time to look at which user groups we already know better and how much we have to meet their needs. Obviously, we can also know that the user is unfamiliar to us, whether we have done some research on a particular type of user, and whether there are case studies to support the answers we write in the matrix. Simply summed up in a word, we know what, do not know what.

If there is no evidence on hand to support our documented user needs, then this is the assumption that we need to validate. Assumptions are great because they provide the perfect design hypothesis. Using this set of matrix graphs, we can determine what user research needs to be done to validate our assumptions.

Common factors (Common MX)

You will often find a phenomenon in which the answers are similar in every lattice of the horizontal or vertical axis. For example, in Figure 7 we assume that users who like to "explore", whether locals or tourists, are interested in finding new running routes, and that all users who like to "compete" are interested in timing. There's nothing wrong with that, but when we're testing these requirements, we're going to use certain parameter limits to determine what kind of user we need to communicate with. When we design for these scenarios, these features may be substituted for some of the underlying functions that are present in our application.

Precedence and dependencies (priority and dependencies)

Sometimes, when you prioritize a function, the method of drawing a matrix diagram can help you sort out the correlation problem at the same time. In the case where we design this application, this approach quickly makes the problem clear: the users who will mark the route in a meaningful way are usually local users--before the route is used by tourists. This means that our application should first attract local runners, on any occasion, for example, in the function settings, in our communication, and in our marketing.

Core value proposition (proposition)

"Value proposition" is a fun way to describe the value you promise to your customers. Once you've finished drawing a few sets of matrices, you can determine what you actually promise to the user by using the scope of your needs and scenarios.

In our small example above, we have completed several matrix diagrams in less than one hours. A team member suddenly stood up and excitedly said, "I want to know where I can run!" That's the question we need to answer.

I handed her a pen, and she wrote it in the back of the last matrix we finished (Figure 8). Then we learned that in order for this application to succeed, no matter what kind of scene the user is in, we have to answer that question-and this will be our most original core value proposition. At this point, we can focus on the rationality behind the design, and we just need to pass some bottom-up thinking (bottom-up thinking) to let ourselves have a clear basic principles on the line.

Further

Now we have some matrix maps on hand, and some more profound analysis and insights. What's next?

First, as with many of the tools commonly used in workshops, this approach also encourages structured brainstorming, which is as important, if not inadequate, as the results of the implementation. As I was beginning to say, this set of methods does not produce deliverables with a pretty format--it describes how we actually consider users. Follow the steps above to complete the matrix and analyze them, and you will find that you will have a clearer idea of what to do when you meet the following challenges:

For example, decide which user groups need more in-depth user research, and from which user groups can obtain a sample of personas, thinking models, and user journeys to meet more detailed task requirements.

Determine which features are cross user groups, and then create a product roadmap based on functionality. So you can decide which features to design and develop.

Using this matrix method to express the user's needs is a happy by-product, you can describe them as a corresponding user story, which is story for agile methods. Once again, take our application for example, we can create a user story: As a local runner, I want to find a new running route. Then you can see if this user story is an authenticated user requirement. If yes, then you can go into the design-development process.

When is this method best used?

I have successfully used this approach as a link to other people, and it works well when I teach startups how to bring them closer to the user base and tell them what they should be developing first. It coincides with some methods, such as Lean Startup, because he provides a structured basis for the creation of hypotheses. I also found that it can be used as a preliminary thinking tool to help design decisions, or as an integration tool in the user's research process.

There is no doubt that when you study this method, you may find other uses for him, or you may find him useless to you. You might say it's the best tool for all the work, but the best tools are the tools that make it quick and easy to do.

In this case, I have a very simple way of making it easy to think about the scope of the user's behavior and motivation--always remember where they are.