Дизайн пользовательского интерфейса. Искусство мыть слона - Владислав Владимирович Головач
Шрифт:
Интервал:
Закладка:
♦ Наконец, отношение к продукту как к неготовому позволяет ещё и избежать вечной беды IT-индустрии — гонки за новыми функциями (creeping featurism). Субъективно готовый продукт незачем улучшать, поэтому он просто становится больше (за счет функций). А вот субъективно неготовый — улучшать можно и нужно, т. е. не только что-то хорошее добавлять, но и плохое исправлять.
День, когда вы только добавили что-то хорошее, но не исправили что-то плохое, — потерянный день.
Таким образом, при работе, прежде всего, нужно думать о том, как улучшить продукт, а не о том, чтобы сделать его хорошим. До конца хорошим он не станет никогда — но если вы будете относиться к нему как к неготовому, он станет достаточно хорош немного раньше, чем в противном случае.
Относитесь к своей работе пессимистично
Очевидно, что через __впишите период времени__ когда выйдет новая версия сайта или программы, над которой вы сейчас работаете, текущее состояние продукта будет казаться вам убогоньким — новая-то версия будет лучше. А раз новая версия будет лучше, текущая версия плоха.
Поэтому оптимизм в отношении своей работы явно вреден. Если вам нравится то, что вы сделали, вы явно обманываете себя, поскольку через некоторое время вам это разонравится (если же не разонравится, вы узнаете, что достигли вершины своего мастерства). Этот самообман, хоть он и очень приятен, опасен — если вы считаете что-то хорошим, у вас нет стимула пытаться сделать это ещё лучше.
Всё недостаточно хорошее — плохое. Поскольку улучшить можно всё, всё — плохо.
Поэтому пессимизм — верный и надежный двигатель профессионального роста, а значит и качества вашего дизайна. Признайте, что то, что вы сделали, вы сделали плохо, и у вас появится стимул сделать это лучше.
Самый простой способ достигнуть такого пессимизма — повесить над своим столом табличку со словами «Это можно сделать ещё лучше». Конечно, настроение она поначалу портит. Но качество работы — улучшает.
Стройте работу так, чтобы не думать о том, что именно вы могли забыть
Большая часть работы дизайнера интерфейсов, во всяком случае, по затраченному времени — это думание. Чем сильнее мы ускорим это думание, тем быстрее и производительнее начнем работать. Эта задача может показаться невыполнимой (как же, для этого нужно стать умнее, что явно невозможно), но на самом деле она вполне реалистична — для этого всего лишь нужно изъять из нашего думания непроизводительные потери.
На мой взгляд, главной такой потерей является вопрос «О чём я забыл(а)?». Хороший интерфейс — явление многофакторное, об одном факторе вовремя не вспомнишь и всё придётся переделывать. Моё главное такое «достижение» было, когда я, нарисовавши прекрасный интерфейс главной страницы сайта, выверенный до мельчайших деталей, обнаружил, что забыл оставить в нём место для поля поискового запроса. Вуаля — целый день работы насмарку. Ошибка в пятисекундном рассуждении привела к совершенно неприличному объему потерянного времени.
Самый простой способ избавиться от таких потерь — всё записывать. Если перед тем, как рисовать интерфейс, вы напишете список всех его объектов — вероятность ошибки снижается на порядок. Если вместо того, чтобы долго разглядывать свеженарисованный интерфейс в поиске ошибок, просто прогнать его по контрольному списку — скорость проверки вырастет на порядок. Если записать перед началом проектирования интерфейса его желаемые эргономические качества (такой перечень вряд ли будет больше абзаца), вы не забудете о них в процессе работы, а значит, все их и обеспечите (по мере сил).
Запись всего и вся — не единственный вариант решения. Если вы не умеете быстро писать, для вас он может оказаться неэффективным. Главное — построить свою работу так, чтобы вопрос «что забыто?» вообще не возникал. Например, через перманентные переделки.
Записывайте всё, в частности, совершенные вами ошибки. Нет лучшей гарантии, что вы их не повторите.
Переделывайте, а не думайте
Есть и другой способ ничего в интерфейсе не упустить. Можно даже и не пытаться всё учитывать — зато делать интерфейс быстро, пускай и плохим, а затем так же быстро переделывать его в хороший, а не долго думать/планировать/готовиться/изучать, стараясь сделать интерфейс хорошим с самого начала.
Результат в обоих случаях получится одинаковым. Различаться будет продолжительность работы — при хорошо поставленной технологии переделок и улучшений работа будет идти быстрее, поскольку вам не придется думать о том, что ещё вы могли упустить.
Кроме того, этот вариант предпочтительнее ещё и тем, что он более управляем. В случае долгого планирования сначала тратится много времени на думание, потом получается результат, но не факт, что достаточно хороший — и пока его ещё нет, вас (т. е. работника) нельзя перевести на другой проект, поскольку вы всё забудете. В случае перманентных переделок у вас быстро получается ужасный вариант и чуть позже приемлемый — и после этого работу над интерфейсом можно прервать или приостановить в любой момент. Работы такого вида очень любят руководители, поскольку она дает им большую гибкость в распределении сотрудников по проектам.
Наконец, работа через переделки лучше и тем, что её легче проверить. Когда вы долго ищете наилучшее интерфейсное решение, путь к нему содержится только у вас в сознании; он не воплотится в реальности, пока вы не доделаете работу до конца. Если же вы работаете через переделки, почти сразу вы получаете вариант вне своей головы (пускай только эскиз). Такой вариант можно показать коллеге или заказчику, чтобы спросить у них совета. Две головы тут лучше одной, так что включение дополнительных людей в процесс дизайна улучшает качество.
Планируйте как можно меньше, начинайте проектировать интерфейс как можно раньше, зато переделывайте почаще.
Пара примеров такого рода работы из моей практики:
♦ Когда я разрабатываю интерфейсы сайтов, я полностью меняю вид навигации по сайту в среднем четыре раза за проект (всякий раз, когда обнаруживаются проблемы в текущей версии навигации).
♦ В одном из моих проектов общая структура интерфейса была настолько сложной, что я поначалу даже не пытался о ней думать. Примерно за месяц я нарисовал все фрагменты интерфейса и только в предпоследний день проекта, когда (наконец-то!)
