Недавно я прочитал книгу Алана Купера «Психиатрическая больница в руках пациентов».
Из него мне удалось почерпнуть ряд идей на тему «как улучшить разработку».
Ниже приведен ряд рекомендаций из книги, которые я принимаю во внимание.
Вдохновил меня Милфгард с этим постом .
Я постараюсь прочитать все книги из этого списка, которые мне интересны.
1. Персонифицированный метод
Я слышал об этом и раньше в выступлениях Дмитрия Сатина и других уважаемых товарищей, но никогда не воспринимал это как руководство к действию.Однако Алан Купер говорит, что это необходимо сделать.
Итак, суть в том, чтобы отойти от понятия «пользователь» и перейти к реальным-нереальным людям.
Те.
Мы придумываем персонажей из реальной целевой аудитории нашего продукта, но при этом они не должны быть реальными людьми.
Например, для сайта отеля это будет так:
Марина, 25 лет. Офис-менеджер небольшой компании из 30 человек.Такому человеку уже гораздо проще проектировать, чем сферическому пользователю в вакууме, и когда возникнет вопрос, нужна ли ему функция печати, мы ответим, что да, она нужна: Марина распечатает информацию о брони и пройти мимо людей, отправляющихся в командировку.Она работает днём в светлом московском офисе и ей всё нравится.
Обязанности: поддерживать хорошую атмосферу в офисе, следить за тем, чтобы все работало, готовить командировки и готовить для этого документы: бронировать номера в гостиницах и бронировать билеты.
Большинство решений принимаются самостоятельно, отдавая на подпись только окончательный счет. Хороший муж и трехлетняя дочь.
Или сохраните его в формате PDF и отправьте сотрудникам по почте.
2. Помните о своих целях
У каждого человека, который использует наш продукт, есть какие-то цели.Этот:
- личный (не чувствовать себя глупо, не совершать ошибок, выполнять достаточный объем работы, получать удовольствие);
- практичный (избегать встреч, выполнять требования клиентов, хранить историю заказов, перезванивать клиентам);
- корпоративный (увеличить прибыль, победить конкурентов, набрать персонал, открыть еще два магазина);
- ЛОЖЬ (простота обучения, экономия памяти, улучшенный внешний вид, более быстрый ввод данных).
Прежде всего личное, а потом все остальное.
Если личные цели противоречат корпоративным, в долгосрочной перспективе личные цели одержат победу.
Важно отличать цели от задач.
Для достижения одной цели мы можем выполнить множество мелких задач, однако никогда нельзя забывать о конечной цели.
3. Пишите сценарии
Хорошо сосредоточиться на сценариях работы людей.Это то, что позволяет нам поставить себя на место Марины из предыдущего примера.
Звучит это примерно так: «Мне говорят даты поездки, сотрудников, которых нужно отправить, и место, куда их нужно отправить.
Я ищу отели в этом городе через Интернет, узнаю цены, свободные номера и, если меня все устраивает, бронирую».
Существует три типа сценариев:
- Каждый день (Они самые полезные и важные.
Действия, описанные в них, выполняются чаще всего);
- Обязательный (Их можно использовать редко, но возможность их использования должна существовать.
Например, срочное бронирование с предоплатой наличными от юридического лица или отмена бронирования);
- Исключительные ситуации (Они разрабатываются в последнюю очередь и могут быть спрятаны в глубине интерфейса.
Пример: У Марины сломана клавиатура, но ей нужно срочно забронировать номер).
4. Продукт для средней аудитории
Программисты склонны предполагать, что люди открыли наш сайт/программу и знают, что делать.Но чем больше функций мы создаем, тем выше порог входа.
Будет определенный перекос в сторону подготовленной аудитории.
С другой стороны, руководители и менеджеры по продажам, наоборот, недооценивают возможности пользователей.
Они думают, что надо всё разжевать, показать и сделать максимально простым.
Наклон к неподготовленной аудитории.
Правильнее было бы полагаться на среднее значение.
Предварительно, конечно, определив, кто такие эти самые середняки.
5. Главное есть главное
Важно запомнить часто используемые функции и сделать их максимально доступными.Редко используемый функционал можно скрыть.
Microsoft пыталась реализовать этот подход в своем MS Word, начиная с версии 2007 года, хотя и за счет редкого функционала, который сейчас невозможно найти.
6. Договоритесь об общем словаре
Зачастую одни и те же понятия могут трактоваться по-разному разными участниками процесса.У клиента может быть одно, а у разработчика совсем другое.
Например: «На моем сайте должна быть возможность купить заказные исследования».
Если вы спросите клиента о возможности оплаты, он ответит, что цена на индивидуальное исследование не определена заранее и, следовательно, не может быть оплачена на сайте.
Лучше, если заявление будет отправлено по почте.
Таким образом, мы просто отказались от функционала покупки/оплаты со всеми вытекающими, просто уточнив термин «покупка».
7. Проект взаимодействия и подробная документация.
Одна из самых важных вещей — это дизайн взаимодействия.
За успех проекта должны нести ответственность дизайнеры взаимодействия, которые готовят сценарии, продумывают персонажей и т. д. При подходе «UI-дизайн → Дизайн → Программирование → Тестирование» программисты освобождаются от ответственности за общий успех продукта.
Важно, чтобы все, что спроектировали проектировщики, было тщательно задокументировано.
Потом вы всегда сможете перечитать и понять, в правильном ли направлении мы движемся.
В документации должны использоваться имена персонажей, разработанные методом persona. ПС: Мы сами еще не применили в полной мере ни один из этих принципов (но очень хотим) и будет интересно, если прочитавшие эту книгу поделятся в комментариях своим опытом реализации этих принципов.
Теги: #книги #книги #Управление проектами #бизнес #полезное #читать #Разработка сайтов #Профессиональная литература
-
Банк Международных Расчетов (Бмр)
19 Oct, 24 -
Удалить Кнопку «Пуск»
19 Oct, 24
