How to break platform usability test

Absrtact: Mobile phones, PCs, web pages, tablets a product has a number of terminals/platforms have been very common, faced with a large version of all the platform to be released over the same period, and the various platforms of the continuous experience is increasingly important, single platform usability testing has

Mobile phone, PC, webpage, tablet ... A product has more than one terminal/platform is very common, faced with a large version of all the platform to be released in the same time, and the various platforms of the continuous experience is more and more important, single platform usability testing has gradually failed to meet the current needs, Here's what you need to be aware of when you're facing multi-platform usability testing.

(The following story is purely to lay the full text comedy color and exaggeration, and the real product does not have a dime relationship.) )

User researcher Lao Wang recently encountered a worry, TA is responsible for a product two months to send a large version, looked at the eye of the project manager issued a weekly report, six platform to sync hair! (leaders are no longer worried about the old Wang's work is not saturated) it seems that the usability test of the platform can not run off, old Wang Pinch point:

We have a total of 6 platforms for our rogue products.

There are 3 new features and 5 basic features to be tested in this new edition.

Each platform is developed separately, so each feature completes the time point is different;

Then the project schedule could be as immoral as the following: (The following form is purely fictitious)

So:

And so on a single platform for all the characteristics of the development of the platform after the test is too late!

Such a single feature of all platform development after the completion of the test by the characteristics is not possible!

This can put the old king worried bad, the only few strands of hair will be tares (Hao) light.

Don't be afraid, Old King. The little Angel secretly tells you a secret--

Have turned the supercilious look of a little Ann not impatient, so bohemian premise is:

1. Many platforms;

2. Release time concentration;

3. The characteristic is high in different platform homogeneity.

The benefits are:

1. Reduce the number of usability tests;

2. Increase the number of rounds to verify the solution;

3. Predict and avoid recurrence of similar problems on different platforms.

So what is the difference between a specific implementation and a regular usability test:

Remember to keep the bottom line before picking up demand

First, tell us a little story:

Actually just ask one more thing:

The above mentioned situation is not unlikely to happen, take the demand before remember to keep their bottom line:

Can not be in the current version of the landing on the slow (next version is still unknown, perhaps the entire feature will be killed, then this test is a waste of effort)

There is no obvious change or improvement. Wait (if this version fixes only some of the details of the previous version, while the large interaction process and icon system are unchanged and irrelevant to the usability issues tested by the previous release, it is recommended that you do not, or use resources from other platform tests to test.) )

There is no effect on the interface even if it (sometimes with other products and even hardware cooperation, if we can not affect the interface, so even if there are problems can not change, this is not the case)

To ensure the basic characteristics of a main platform contingency leakage, other reasonable supplement

Although this Austrian righteousness is where to finish the test where, but also can not do wrong.

Typically, there are 4 of features that are tested in usability tests:

In multi-platform usability testing, first of all, to select a master platform to ensure that the platform all the basic characteristics of the accident leak, for other platforms, has a new feature completed platform priority, followed by improved characteristics, but one test not more than 3 platforms. This is to give the new feature more trial and error verification opportunities.

Heavy scene, light task, with platform, cross platform to see the scene

Scenario is a concise description of how a persona uses a software-based product to achieve its goals. Task, it seems to me more like the packaging of features, which need to be in the "scene" of the big script to be able to execute.

In the actual test I usually let the user know who Ta is (usually ta himself) now where (such as home) what to do (put the photos on the phone to the computer), and then see TA how to operate. As for TA is not in accordance with the ideal task order to operate in fact not important, the focus is TA's purpose (or the goal we set) whether to achieve. If you fail to reach your goal, look at what links the TA is causing failure.

As for the situation where a user simply skips a set of tasks to achieve a goal directly (or does not measure the characteristics that need to be tested), he or she can invite TA to try another way after the user reaches the target.

It is also noteworthy that although let the user natural operation is very good, but when the platform is more likely to appear in a hurry, so for the convenience of users or try to put together the task of the platform, need cross-platform words (such as on the computer download the ebook to the phone to see) Then put it on the task of using the computer and the task of using the phone as a transition, as shown below.

Crazy whipping small partners to modify the problem and repeatedly verify the solution

How do you measure a lot of usability problems? Hurry to change! To verify the solution in the next round, right?!ios's feature a This round is wrong, next to the android can be measured after the characteristics of a! Any more questions? then keep changing! And then there's the ipad! (See figure below)

Here we need to reiterate one of the major prerequisites mentioned above--the homogeneity of the characteristics on different platforms. That is, when feature a is basically similar to the interface between iOS and Android to save time and use another platform to verify the problem of the platform, it would be best to validate it on the original platform.

Write the report to the person who wants to see it and track the results in time

When the report comes out, let colleagues understand it and digest it immediately, so it's probably the case for the different characters:

To the boss to see the core issues and the main conclusions;

To the product manager to see the seriousness of the problem, provide the need for priority reference;

Give the designer the reason for the specific problem, so that the designer can think of a better solution, rather than a rude way to solve it by adding features;

To develop to see which problems are bugs, can be repaired immediately;

In addition, the owners of different platforms may be different, so it is best to aggregate the contents of the same platform together to render it.

Finally, it's good to maintain a usability problem tracking table (pictured below):

From the tracking situation to see which problems are left over and not resolved, and then similar problems will be more with the relevant colleagues to chat;

From the feature name to see which tasks are always done poorly, which is changed after getting worse, well, or to find colleagues to chat;

Problems from one platform can also predict where other platforms may go wrong when doing similar tasks;

To facilitate the statistics of their own landing rate, summed up the experience and lessons;

The best thing to use is--when someone asks questions about a version of a platform, you can instantly cut all the problems of the platform with different platforms/versions of the same version to TA. It would be great if you could solve the same problem with other platforms or the legacy of the platform.

Well, I don't know how it works for everyone.