Статьи

Автор: Тира Рауч (Thyra Rauch) — работает в IBM уже почти 23 года. Она сыграла важную роль в усилении отрасли UI, роли пользователя в целом ряде областей для различных продуктовых решений. Истории пользователей и работа с архивными документами — неотъемлемая часть её процесса проектирования. Тира также использует целый спектр различных технологий, таких как контекстные запросы, постановка задач, сбор требований и приоритетов, разработка прототипов и проектирование дизайна, основанных на принципах human-centered design.
Тира активный член UPA с 1992 года, 2 года была президентом этой ассоциации и в настоящее время в третий раз входит в состав совета директоров. Она является автором 10 патентов в области дизайна пользовательских интерфейсов.
Тира - ключевой докладчик конференции User Experience Russia - UPA Europe 2009, которая состоится в октябре 2009 года в Москве. Данная статья написана специально по просьбе организаторов конференции.

Перевод Анастасии Рязановой:

Любой бизнес стремится к оптимизации процессов: начиная от бизнес-процессов, заканчивая процессами обработки данных. Мы, как профессионалы UX, также испытываем необходимость оптимизировать то, что мы делаем; а главное, то, как мы делаем. Мы не можем ограничиваться только юзабилити тестированием, тем самым включаясь в процесс разработки лишь тогда, когда вся основная работа над созданием продукта практически выполнена. Мы должны влиять процесс разработки продукта. Включение юзабилити специалистов в команду по разработке новых продуктов, способствует снижению рисков. В условиях ограниченных ресурсов и времени, юзабилисты все же могут быть эффективными, если будут внимательно подходить к организации того огромного количества задач, которые им необходимо выполнить в процессе работы над созданием продукта.

Я часто повторяю: несмотря на то, что различные программные приложения и гаджеты меняются, принципы и методы, которые юзабилисты используют для UX не могут и не должны меняться. Мы должны много работать в сфере UCD исследований, изучать пользовательское поведение, тестировать и оценивать удобство новых продуктов. Основной целью и достижением тех изменений, которые произошли в сфере юзабилити за последние годы, является значительное уменьшение сроков окупаемости новых продуктов. Есть две вещи, на которые действительно следует обращать внимание, когда вы планируете какие из своих идей следует реализовать: расходы на реализацию этих идей и ожидаемые выгоды, которые вы получите, после того как эти идеи воплотятся в жизнь. На самом деле у нас никогда не было достаточно времени, денег и ресурсов, чтобы осуществить все, что нам хотелось бы, так что приходиться очень тщательно выбирать между множеством проектов, что, с точки зрения бизнеса, очень правильно.

Методы уменьшения затрат
Методы уменьшения затрат в сфере юзабилити были предложены Якобом Нильсеном и Джаредом Споулом около 20-ти лет назад. Говорят, что “наиболее достоверные результаты получаются при тестировании не более 5 человек и при проведении большого количества мини тестов». Основная идея здесь заключается в том, что качественные исследования являются менее дорогими, чем количественные, и к тому же быстрее, дешевле и рентабельней. Как сказал Я. Нильсен: “Нет необходимости измерять удобство пользования продуктом, чтобы улучшить его … Если вы видите, что несколько человек затрудняются при использовании одного и того же элемента дизайна, Вам не нужно знать, у скольких еще пользователей возникнет подобная проблема”. Например, в одном из тестов, который мы проводили в прошлом году, мы наблюдали 2-х пользователей не справившихся с одной и той же задачей. В данном случае, мы даже не стали смотреть, как с этой задачей справятся другие пользователи, а просто изменили дизайн и продолжили тестирование с новым дизайном. Следующие 3 пользователя успешно справились с задачей, которая вызвала затруднения у предыдущих пользователей.

Таким образом, разработка сложной методологической базы, не всегда является лучшим подходом, даже если у Вас есть на это время, деньги и ресурсы. Для современного бизнеса сейчас очень важно не просто совершать правильные действия, но и следить за тем, чтобы затраты сил на осуществление этих действий были сопоставимы с результатами. Можно производить продукт, который будет очень полезным, но, тем не менее, не будет продуктом, которым захотят пользоваться, поскольку он не делает того, что необходимо пользователям. Для того, чтобы этого не происходило, нам необходимо как можно больше общаться с пользователями. Есть три наиболее эффективных метода, которые помогают снизить затраты на юзабилити:
• быстрое юзабилити тестирование с использованием качественных методов;
• представление пользователю черновой макет продукта – можно на бумаге;
• оценка пользовательских качеств продукта вашей командой - можно многое заметить.
Единственное, что пропущено в этом списке, это общие исследования пользовательского поведения (например, анализ задач, наблюдение, интервью). Как говорит Марк Херст, не посоветоваться с пользователями и не знать направления, в котором следует работать для уменьшения затрат, это все равно, что делать хорошие дела без видимой на то причины. Исследования пользовательского поведения, как правило, занимают много времени. Но что, если вы начнете комбинировать методы или, по крайней мере использовать различные методы в одной и тоже тестовой группе?

Хотя методологические пуристы могут негодовать, но я всегда считала, что границу между исследованием пользовательского поведения и пользовательским тестированием необходимо стирать. Я заметила, что в последнее время многие стали мыслить в этом направлении. Я думаю, что сейчас у юзабилистов очень много работы по усовершенствованию того, что мы делаем, как мы это делаем и как сопоставить все это с быстрыми темпами развития современного мира.

Девид Чиснелла считает, что юзабилити тестирование - это скорее формирующий инструмент, чем, как многие обычно думают, обобщающий. Он утверждает, что юзабилити-тестирование должно применяться “везде и всегда, когда перед пользователями встает какая-либо задача…”. Юзабилити-тестирование является мощным инструментом для юзабилити специалистов, но как мне кажется, лабораторные исследования все таки имеют некоторые погрешности ввиду того, что проводятся в незнакомой для тестируемых обстановке. Мы также должны учитывать, что продукты, которые удачно используются в повседневной жизни, не всегда подходят для тестирования в лабораторных условиях. По этой причине я всегда стараюсь проводить тестирования с пользователями на их рабочем месте.

Давайте рассмотрим пример. Предположим, у вас есть продукт, в котором требуется сделать некоторые изменения. Для того, чтобы сделать это, Вам необходимо четко понимать, что очень важно сохранить и что может быть изменено. Итак, что делать в таких ситуациях? Для начала можно просто понаблюдать за тем, как пользователи используют продукт, затем начинать задавать им вопросы о том: что они делают, почему они делают, что они не могут сделать, что они хотели бы сделать и так далее. Затем, двигаясь по направлению от исследования пользовательского поведения к тестированию, вы можете предложить тестируемым несколько альтернативных вариантов реализации продукта и спросить, стало ли ему легче выполнять задачи. Таким образом, Вы вовлекаете пользователей в работу над интерфейсом продукта, а также оцениваете то, что вы предлагаете. Стало ли так лучше? Что еще можно предложить им? Это действительно здорово, когда пользователям предлагается несколько вариантов, в таких случаях пользователи, как правило, более охотло рассказывают о своих потребностях и желаниях.

Далее, когда у вас есть какой-то продукт, который в принципе уже готов, дайте его пользователям для того, чтобы они протестировали его в привычной для них обстановке. Если дать пользователю возможность использовать устройство в повседневной жизни, то Вы обнаружите намного больше ошибок. В лабораторных условиях, если Вы захотите протестировать продукт с одним и тем же пользователем дважды, то вы увидите, что при повторном пользовании продуктом пользователь уже не будет помнить, где и какие у него возникли проблемы. А когда пользователь на протяжении нескольких дней или недель пользуется новым продуктом в повседневной жизни, он постепенно запоминает те проблемы, которые у него возникают, и, к тому же, часто делится с нами историями, которые произошли с ним во время использования продукта.
Примерно 10 лет назад я начала интересоваться пользовательскими историями об опыте взаимодействия с продуктом. Эти истории помогают нам понять потребности и действия пользователя. В них отражается не только оценка пользователем продукта, но его переживания, впечатления, эмоции. Как мы получаем пользовательские истории? От пользователей, конечно! Вы можете спросить тестируемых об их личном пользовательском опыте во время интервью, проведения тестов и т.д.. Пользовательские истории очень хорошо могут вписаться в процессы исследования пользовательского поведения.
Как и почему Agile Software может изменить положение?
Agile Software процессы различаются, но в целом они имеют и в общие характеристики, например:
• потенциальные покупатели продукта вносят свой вклад в процесс разработки продукта
• быстрая интеграция
• получение результатов в кратчайшие сроки

UCD / UX дизайнеры, как правило, работают не только с пользователями. Для них также очень важно изучать новые направления развития в дизайне и в исследованиях пользовательского поведения. Таким образом, при Agile разработке всегда смешиваются анализ, проектирование, разработка и взаимодействие на протяжении всего процесса разработки продукта, а это означает, что юзабилити специалисты должны будут обязательно адаптироваться к этой новой модели.

Пока есть люди, которые считают, что UX и Agile разработка не в ладах друг с другом. Мне же кажется, что в данном случае перед нами открывается чудесная возможность привлечь внимание общества к этой проблеме. Сколько раз вы находили то, что желали бы иметь пользователи, но Вам говорили, что введение этих обновлений возможно только в следующей версии продукта.

Agile разработка снижает риск создания плохих пользовательских интерфейсов, так как мы стараемся как можно раньше включить пользователя в процесс разработки продукта.

Работать в agile команде достаточно сложно, так как постоянно приходится комбинировать различные виды деятельности. Когда мы проводим юзабилити тестирования в нашей лаборатории, мы успеваем много узнать о каждом отдельном пользователе. Таким образом, мы получаем много полезной информации, которую можно использовать в будущих проектах. К тому же, основываясь на прошлых проектах, мы можем делать некоторые выводы относительно правильности реализации текущих проектов.
Использование истории разработки продукта способствует производству таких продуктов, в которых пользователь действительно нуждается в первую очередь. И еще: истории помогают команде взглянуть на целостную картину опыта использования продукта.
Эти методы действительно очень хорошо комбинируются с agile методами, потому что вы можете проводить тестирование с небольшим количеством пользователей и одновременно работать и изменять интерфейс Вашего продукта. Agile помогает разработчикам сократить затраты и ускорить процесс создания продукта.

Original Article

Just as businesses are talking about optimizing everything from business processes to utilization of data, we as UX professionals also need to optimize what we do and how we do it. We should not be merely usability testers, reacting at the end of the development cycle to code that is already complete. Instead we should be influencers of what goes into the product, working as a core team member on all aspects, helping to mitigate risks and prioritize features for inclusion. With less and less time for our various activities, and often a limited amount of resource, we can still be effective if we choose our activities carefully.

One of the things I’ve been saying for years is that just because applications or services or device types change, the basic principles and methods that we use for UX have not and should not change. And, applying them when more and more every-day users are involved becomes even more important. We should still do good UCD and good user research and good user testing/evaluation/validation. But, what has changed over the years is how those things can and should be done for the most return on investment (ROI). Two things really matter when looking at which activities to perform and when: the cost of those activities, and the expected improvements you will get or the potential lost that might result by not doing them. In general, we’ve never had enough time or money or resources to do everything we wanted to do, so picking carefully, no matter what kind of project you are on, makes good business sense.

Discount Methods
Discount methods have been proposed and championed by such folks as Jakob Nielsen and Jared Spool for over 20 years now, saying, for example, that “the best results come from testing no more than 5 users and running as many small tests as you can afford.” (1)

The basic idea here is this: qualitative studies are less expensive to run than quantitative studies, and deliver faster, cheaper ROI. As Nielsen states: “you don’t have to measure usability to improve it…….When you see several people being stumped by the same design element, you don’t really need to know how much the users are being delayed.” (2) For example, in one of my tests this past year, we observed 2 users fail with the same task. Here, we didn’t even wait to test the other 3 users, but instead, revised the design, and began testing again with the new design. The next 3 users were successful in the task.

So, doing heavy-weight methods, even if you can, may not be the best approach. And, what matters more and more to the business is not just doing something right, but doing the right thing. It’s entirely possible to produce a product that is very usable, but is not one that your users want to use because it doesn’t do what they want to do. Being able to actually influence what is built in addition to how it is built is where we can have the most impact. And, to do that we need to be talking to our users. Early. Often. Continuously. And, three methods that are the most useful in discount usability are:
• Rapid usability testing using qualitative methods
• Quick-and-dirty prototypes to get things in front of users rapidly – paper is very good here
• Heuristic evaluation by your own team – you can catch a lot of things yourself

Now, the one thing missing from this list above is basic user research (e.g., task analysis, contextual inquiry, observation, interviews). As Hurst says, without talking to your users and knowing the direction to set for the discount methods, it’s a matter of “Ready-Fire-Aim” or, doing good things for the wrong reason. (3) User research has traditionally taken a lot of up-front time and does not fit in well with rapid iterations. But what if you start combining the methods, or at least combining their use with the same users in a single session?

While methodological purists may cringe (and even when I teach, I teach them separately), over years of experience, I’ve been blurring the lines more and more between doing user research and doing user testing. Recently, I’ve noticed others have been going in the same direction, so my assumption is that it has a lot to do with our evolving role and how we do our work.

In a recent article, Chisnell talks about using usability testing as more of a formative tool than how we usually think about it as a more summative tool. She asserts that usability testing should be done “wherever and whenever users normally do the task they’re trying to do…” (4) While I do believe that usability testing is a powerful tool for us to have in our UX toolbox, I’ve thought for years that testing in a lab is an artificial environment. You have to ask yourself how accurate the data is for everyday use of a product. Will those things that come up during normal use come up during your lab test using your scenario? Is it even less true for more consumer-type products? And, for that reason I really like trying to do more of this kind of evaluation on site with users in their own work environment.

Let’s take an example. Suppose you have an existing product that you need to do some major re-design for. In order to do that, you really need to find out what is critical to keep and what can be discarded – critical to what the user needs to do, that is. So, how might you go about that? Well, one way might be to do some site visits with your current users. Watch them use the current product for awhile. Then begin asking them questions about what they are doing, why they doing that, what they cannot do that they would like to, and the like. Then, moving from more of a user research stance to a testing stance, you might put a few alternative designs in front of them and ask if any of these might help them with that task or make it easier. Engage them in a bit of participatory design as well as a bit of evaluation of what you are proposing. Does it make it better? What else might they suggest? One of the really cool things about having a more open set of alternatives is that the users are generally more willing to engage in a conversation about their needs and wants as opposed to being presented with one design which they tend to say “yes” or “no” to.

Further down the road a bit, once you have something that is actually mocked up or coded, having them try to use it in their own environment with a task they were just doing also tends to tease out a bit more of the things they would encounter day-to-day rather than testing something rather more disjointed in the lab. One of the things I discovered, for example, is how much interruption one of my user sets was encountering. So, when they finally came back to the product to continue what they were doing, they could not recall where they were or what they had selected to get there. This highlighted quickly and clearly the need for more onscreen noting of these sorts of things so they could remain “grounded” in their task, something that had never come up in the lab. And users tend to tell you lots of stories about things like the last time Y happened to them. The stories are really powerful collateral for the design work.

Roughly 10 years ago, I started using more and more user stories and storytelling in my work. (5) The words and experiences of the actual users have a power to help us understand their needs and activities more deeply, and to more effectively be able to relate to them, and to communicate those experiences with others on our teams. Simply telling a developer to add Feature A is not nearly as compelling as telling them the story about how User X is currently doing their task, what frustrations they are going through, and what happened the last time they tried to Task B. It makes it more real.

How do you get user stories? From the users of course! In doing user research, you can prompt for them during contextual inquiry or interviews, and, you can also prompt for them during evaluations as I mentioned earlier.

Stories influence user scenarios and use cases, and can fit nicely into our development processes. But, then development processes for many teams changed as they adopted agile development methods.

How and Why Does Agile Change Things?
Agile software development processes vary, but generally they have in common the following factors:
• Customer input on an ongoing basis
• Rapid iterations
• Delivering work value quickly

UCD/UX designers, while they certainly favor customer input on an ongoing basis, also tend to work with a lot of up-front design and user research, hopefully well before development begins. So, when agile development mixes analysis, design, development, and delivery throughout the process, it means that the UX person’s work will necessarily need to adapt to this new model.

Now while there are some folks who believe that UX and agile development are at odds with each other, I look at it as a marvelous opportunity to have the kind of input and focus we’ve been wanting for years. How many times have you found something that is highly desired by the users but you are told by the development team that it will need to wait for the next version?

With agile development and doing re-prioritizing and planning for each iteration, it is much easier to get those important items considered and included. It also lowers our risk of delivering a bad user interface as we have early user input and several iterations to make substantial improvements. Using the concept of parallel UX and development tracks makes this whole process much easier. And, a similar process can work for UX consultants who are not part of the team as they can work on items in a separate-but-linked manner.

Working as I have been doing on an agile team has almost forced combining different activities in the same time slot with the same user. When we do a usability test in our lab, for example, we might do a number of things with each user while they are there. We might get their input on some design alternatives for features for the next iteration. These are usually done in lower fidelity to encourage discussion. And, we might get their input on some of the features for the current iteration – perhaps we have a couple of questions about some implementation details. And, we might have them test some coded tasks from the previous iteration to evaluate if it meets their needs and our goals.

The use of stories fits in nicely as we are supposed to be developing things that the user actually needs, in priority order. And, stories do one more thing really well: they help the team to look at the whole user experience for coherence instead of just looking at a single feature or iteration.

And those discount methods we talked about earlier? They actually work very well with the agile methods because you can test with a small number of users once or more per iteration, and, with many iterations, you end up running a lot of tests but refining and evolving your designs as you go. And, in agile development, as with the earlier waterfall method, using discount methods are a way to assist the UX person in their design work quickly and at more economical costs.

References
1. Nielsen, Jakob (2000). Why you only need to test with 5 users. Alertbox March 19, useit.com

2. Nielsen, Jakob (2006). Quantitative Studies: How many users to test? Alertbox June 26, useit.com

3. Hurst, Mark (2009). A lesson in strategy, taught by a Cat. Good Experience, September 24, goodexperience.com

4. Chisnell, Dana (2009). Testing in the Wild, Seizing Opportunity. In UIEtips, August 12, www.uie.com

5. Daniel Gruen; Thyra Rauch; Sarah Redpath; Stefan Reuettinger (2002). “The Use of Stories in User Experience Design” The International Journal of Human-Computer Interaction.

October, 2009

Перепечатка статьи или ее части без согласования с Software People Team запрещена