Course User interface — Lesson 11

Двигать пиксели, или
решать проблемы?
• Ты либо берешь на себя ответственность за
продукт и решаешь дизайном проблемы
бизнеса. Либо остаешься рисователем
страниц в Фотошопе или серых
прямоугольников в Axure.  
 
Не ждешь, пока тебя попросят — предлагаешь
изменения сам, рекомендуешь решения,
инициируешь процессы.

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

• В таком активном подходе есть уйма
ограничений и придется с ними столкнуться —
на сам дизайн будет уходить меньше времени,
придется идти на компромиссы.
• Eсли подходить к запускам ответственно — от
дизайна до релиза проходит приличное
количество времени.

• Зная это вы сможете строить свои
взаимоотношения так, чтобы быть
услышанными и понятыми. И иметь
полномочия на гораздо больший спектр
действий, чем просто определение
визуального стиля.
• Надоело слушать экспертов “моя жена
попросила добавить…” или “наш секретарь
думает, что лучше…”?

• Привлечение (Acquisition) — доля клиентов
(потенциальных), привлеченных через маркетинговые
каналы, и обнаруживших заинтересованность в продукте
(не сразу покинувших сайт).
• Активация (Activation) — доля клиентов, получивших
положительный опыт использования продукта.
• Удержание (Retention) — доля клиентов, повторно
использующих продукт.
• Доход (Revenue) — доля клиентов, которые платят за
продукт.
• Рекомендация (Referral) — доля клиентов, которые
рекомендуют продукт (делятся ссылкой, высылают
приглашения).

• Важно решать проблемы бизнеса — тогда вы
будете на одной волне с ним и сможете
внедрять настолько глубокие изменения своим
дизайном, о которых раньше и не мечтали.

Процес разработки
.gif

Waterfall
• Каскадная модель (англ. waterfall model,
иногда переводят, как модель "Водопад") —
модель процесса разработки программного
обеспечения, в которой процесс разработки
выглядит как поток, последовательно
проходящий фазы анализа требований,
проектирования, реализации, тестирования,
интеграции и поддержки.

Waterfall
• Управление проектом, условно, можно
разделить на две составляющие — на
планирование и управление ходом.
• С этой точки зрения для waterfall всё ясно —
составили пошаговый (аналитика-разработка-
тестирование) календарный план задач по
оценкам сроков, распределили задачи и
вперед реализовывать.
http://habrahabr.ru/post/226323/

Waterﬂow
• Преимущества:
• Последовательное выполнение этапов проекта в строгом
фиксированном порядке
• Позволяет оценивать качество продукта на каждом этапе
• Недостатки:
• Отсутствие обратных связей между этапами
• Не соответствует реальным условиям разработки
программного продукта

Прописать все требования в начале?
.gif

Agile
• Гибкая методология разработки (англ. Agile
software development, agile-методы) — серия
подходов к разработке программного
обеспечения, ориентированных на
использование итеративной разработки,
динамическое формирование требований и
обеспечение их реализации в результате
постоянного взаимодействия внутри
самоорганизующихся рабочих групп, состоящих
из специалистов различного профиля

Agile
• В феврале 2001 в штате Юта США был
выпущен «Манифест гибкой методологии
разработки программного обеспечения».
Он являлся альтернативой управляемым
документацией, «тяжеловесным» практикам
разработки программного обеспечения, таким
как «метод водопада», являвшимся золотым
стандартом разработки в то время.

Agile
• Основные идеи:
• люди и взаимодействие важнее процессов и
инструментов;
• работающий продукт важнее исчерпывающей
документации;
• сотрудничество с заказчиком важнее согласования
условий контракта;
• готовность к изменениям важнее следования
первоначальному плану.

Agile
• Принципы, которые разъясняет Agile Manifesto[2]:
• удовлетворение клиента за счёт ранней и бесперебойной
поставки ценного программного обеспечения;
• приветствие изменений требований даже в конце разработки
(это может повысить конкурентоспособность полученного
продукта);
• частая поставка рабочего программного обеспечения (каждый
месяц или неделю или ещё чаще);
• тесное, ежедневное общение заказчика с разработчиками на
протяжении всего проекта;

• проектом занимаются мотивированные личности, которые
обеспечены нужными условиями работы, поддержкой и доверием;
• рекомендуемый метод передачи информации — личный разговор
(лицом к лицу);
• работающее программное обеспечение — лучший измеритель
прогресса;
• спонсоры, разработчики и пользователи должны иметь возможность
поддерживать постоянный темп на неопределённый срок;
• постоянное внимание улучшению технического мастерства и
удобному дизайну;
• простота — искусство не делать лишней работы;
• лучшие технические требования, дизайн и архитектура получаются у
самоорганизованной команды;
• постоянная адаптация к изменяющимся обстоятельствам.

• Один из повторяющихся пунктов критики: при agile-
подходе часто пренебрегают созданием плана
(«дорожной карты») развития продукта, равно как и
управлением требованиями, в процессе которого и
формируется такая «карта». Гибкий подход к
управлению требованиями не подразумевает далеко
идущих планов (по сути, управления требованиями
просто не существует в данной методологии), а
подразумевает возможность заказчика вдруг и
неожиданно в конце каждой итерации выставлять
новые требования, часто противоречащие архитектуре
уже созданного и поставляемого продукта.  
 
Такое иногда приводит к катастрофическим
«авралам» с массовым рефакторингом и
переделками практически на каждой очередной
итерации.

Agile
• Customer Development — методология
непрерывного получения обратной связи от
потребителя, параллельного процессу
разработки продукта. Методология создана
Стивом Бланком (Steve Bank), ее описание
можно найти в его последней книге «The
Startup Owner's Manual: The Step-by-Step
Guide for Building a Great Company».
Ключевая идея: «Get out of the
building.» (Steve Blank)

Agile
• Lean Startup — методология использования
коротких быстрых итераций для тестирования
гипотез. Lean Startup — синтез методологий
Customer Development, Agile Software
Development и Lean (Toyota Production
System). Методология создана Эриком Рисом
(Eric Ries), ее описание можно найти в его
книге «The Lean Startup». (В сети есть
пересказ на русском Аркадия Морейниса).

Agile
• Канбан (яп. カンバン камбан) — система
организации производства и снабжения,
позволяющая реализовать принцип «точно в
срок».

Agile
• Канбан — это система работы, которая
позволяет организовать принцип вытягивания
заказчиком.
http://getpocket.com/a/read/314309095
.gif

Agile
• Идеальное состояние дел в студии — равномерная
заполненность проектами всех канбан-ячеек. Как только
заказчик «вытянул» проект с этапа верстки (для нас это
конечная стадия разработки дизайна сайта) — есть
необходимость тут же перевести один из проектов, находящихся
в отрисовке на этап верстки, чтобы заполнить пустую ячейку.

Agile

Agile
• Канбан-доска очень наглядно показывает на
каком из этапов необходимо ускориться по
какому-либо проекту, а на каком образовался
«затор». И ещё — что пора бы задуматься о
том, что на складе уже почти ничего нет и
самое время заняться обработкой
потенциальных клиентов.

Agile
• Зеленый — по проекту все ок. Желтый — есть
вероятность, что проект задержится на данном этапе.
Красный — проект задержался на данном этапе, и
надо постараться сделать все, чтобы перенести его на
следующий этап.

Итоги
• Визуализация проектов с помощью канбан-доски
и принцип вытягивания позволяет легко оценить
необходимость обработки потенциального
клиента, переноса залежавшегося не срочного
проекта на следующий этап и т.д.
• Для оценки занятости дизайнера на ближайшие
два месяца достаточно посмотреть на доску,
посчитать количество стикеров с именем
дизайнера и понять насколько он загружен и
когда освободится.

Итоги
• Сейчас наглядно видно на каком этапе есть
проблема. Остается найти её и решить.
• Простой, но достаточно эффективный
инструмент финансового планирования. Да, он
позволяет заглянуть всего на 2-3 месяца
вперед. Но зато это очень наглядно. И на
денежный поток реально можно повлиять,
вовремя приложив все усилия к «нужным»
проектам.

Пишите письма
.gif

Деловая переписка
• Thank you letter — не позже чем 60 минут 
2 строчки благодарности за встречу.
• Follow up — не позже чем 24 часа 
Протокол встречи + развернутые документы +
атачи файлов + принятые решения, сроки,
ответственные люди.

Структура письма
• Introduction – Вступление (предмет отчета, кто его
написал и по чьему запросу)
• Background - Исходные данные (общее описание
имеющейся ситуации, проблемы)
• Findings - Полученные данные (возможные пути
развития ситуации, решения проблемы, сроки,
ответственные люди.)
• Conclusion, recommendations - Выводы и
рекомендации

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

Настоящим уведомляю,
довожу до сведения
Подобные фразы не несут пользы, а лишь
отталкивают своим официозом. Чаще всего после них
идет официальная информация с датой и событием.  
 
Дорогие коллеги! Довожу до вашего сведения, что в
связи с государственными праздниками 1–4 мая
объявляются выходными днями.
Поправим:
Дорогие коллеги! По производственному календарю  
на 2014 год 1–4 мая — выходные.

Являться
Добрый день! Я являюсь управляющим
партнером сети кафе «Горшочек, вари!».
Поправим:
Добрый день! Я управляющий партнер сети кафе
«Горшочек, вари!»

Данный
Коллеги! Помогите данному клиенту
разобраться с данным вопросом.
Поправим:
Коллеги! Помогите клиенту решить вопрос.

А именно
Я готов встретиться на следующей неделе,  
а именно 8 апреля.
Поправим:
Я готов встретиться 8 апреля.

Осуществлять,
производить
Добрый день, коллеги! В понедельник, с 16:00
до 18:00, возле ресепшена будет производиться
раздача подарков для детей сотрудников.
Поправим:
Добрый день, коллеги! Подарки для детей
сотрудников выдаем в понедельник, с 16:00 до
18:00, возле стойки администратора.

Как ответить на
агрессивное письмо?
.gif

• Sent: Tuesday, November 17, 2014 10:15 PM 
To: team@xxx.com.ua
• Subject: Да вы #@$%ли совсем! Как вернуть
деньги? Пытаюсь отправить данные
(подставьте любой кейс), а оно пересылает на
сайт! Потратил два часа! Что за $#@%?!
Пользуйтесь сами своими $#%@@ услугами/
сервисами/продуктами!
http://goo.gl/gkzsd1

Ошибки
• Затягивать время ответа: не знаю, как ответить;
пусть подождет, может, что-нибудь придумаем или
«само рассосется».
• Подавить свои эмоции. Ответить по существу, в
стиле «в Багдаде все спокойно».
• Возмутиться поведением клиента и ответить на
агрессивное письмо-претензию в стиле «Что вы
себе позволяете?» При этом переслать письмо
начальству: посмотрите, дескать, с какими хамами
приходится работать!

Ошибки
• Возмутиться некорректным поведением клиента и вообще не
отвечать: пусть вначале научится цивилизованно выражаться,
а потом будем общаться.
• Признать полную справедливость претензии, «посыпать
голову пеплом». Привести аргументы в свое оправдание.
Уверить, что такого впредь не повторится, попросить клиента
дать вам шанс все исправить.
• Ответить: «Деньги вернем». При этом вычеркнуть хама из
списка своих клиентов.
• С замиранием сердца открывать почту, опасаясь новой
«агрессивной атаки».

1. Старайтесь не затягивать с ответом. Среднее
стандартное время ответа на письмо клиента – не
более 2-3 часов. 
 
Если Вам необходимо время для того, чтобы
разобраться с ситуацией, и это может занять
времени больше, нежели 2-3 часа – сразу напишите
клиенту письмо с сообщением, что Вы получили его
письмо и ответите на его просьбу не позднее…
Кстати, это время также позволит Вам справиться
со своей первоначальной эмоциональной реакцией.

2. Любое деловое письмо содержит в себе две
составлящих: фактическую, собственно
деловую (вопросы, которые необходимо решить)
и личную (эмоциональную).  
 
Обычно как бы ни разворачивался личный
(эмоциональный) план письма, какие бы
негативные эмоции не посылал нам клиент, мы
обязаны ответить по существу заданного нам
вопроса.

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

Постарайтесь разделить содержимое письма на
«бизнес-составляющую», которую следует
решить, и «эмоциональную составляющую».
Разберитесь, где собственно факты, а где –
«эмоции по поводу».

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

Для комментария эмоций адресата и своих
эмоций воспользуйтесь постскриптумом.

Первой строкой письма обращаемся к клиенту
по имени.
Обращение по имени – признак внимания к
собеседнику, знак культуры делового общения и
инструмент, помогающий избежать безликости.
Имя клиента можно узнать из подписи или
строки адресата.

Уточняем у адресата правильность нашего
понимания его просьбы/претензии/вопроса.
Это бывает особенно необходимо, если
эмоциональное письмо клиента написано
сбивчиво, мысли в нем хаотичны, трудно понять,
где – собственно просьба, а где — мысли по
поводу. Корректно уточнить правильность
своего понимания позволяет замечательная
фраза: «Если я правильно Вас понимаю,..».

Если мы владеем информацией по заданному
нам вопросу: предельно четко и полно
сообщаем эту информацию адресату.

И только ответив клиенту по существу, мы
можем перейти к комментариям
эмоционального аспекта. Пользуясь
постскриптумом, проговариваем свое отношение
к некорректному стилю письма. Форма может
быть разная – в зависимости от нашей позиции в
общении с клиентами и от конечной цели,
которую мы для себя определили перед
написанием письма.

Завершаем письмо обязательным блоком
контактной информации.

Course User interface — Lesson 11

Пример письма
Здравствуйте, Андрей!
Если я правильно понимаю, Вы недовольны работой
нашего сервиса и Вам хотелось бы вернуть назад деньги.  
 
Уточните пожалуйста, что именно Вы отправляете на
каком из этапов работы (уточняем детали, правильно ли
мы поняли)…
Если Вы решите вернуть деньги сообщаю, как это можно
сделать. Согласно п.2.2. Договора Оферты,…
(описываем подробно)

Пример письма
P.S. Андрей, мне так же, как и Вам, неприятна ситуация, в результате
которой Вы готовы прекратить взаимодействие с нами. Думаю, что и
мы, и Вы в этом случае оказываемся в проигрыше: мы теряем клиента,
а Вы – возможность пользования нашим сервисом (уверяю Вас,
сервисом достаточно удобным и эффективным!). Если Вы готовы
выделить время чтобы разобраться с ситуацией – напишите мне, что
произошло, что Вы обратились к нам с требованием возврата денег. Мы
разберемся в причинах и поможем Вам сделать пользование нашими
услугами максимально комфортным и результативным для Вас.
Единственная просьба: давайте общаться в нормативной лексике».
С уважением, Маша Петрова  
Со-Founder «Rога&Копыtа» 
+38 063 992 23 12,team@roga.com.ua

Три амиго: бриф, договор,
техническое задание
.gif

Бриф
• Чем занимается ваша компания?
• Бизнес-цели приложения?
• Какой тип приложения вам нужен? (здесь
стоит указать для клиентов краткое описание
типов приложений)
• Каких результатов вы хотите добиться с
помощью данного приложения?

Бриф
• Приведите примеры подобных приложений.
• Что именно вам нравится в этих примерах?
• Какие решения в подобных приложениях вам не нравятся?
• Перечислите основной функционал будущего приложения:
• Что должно уметь делать приложение?
• Какие основные функциональные блоки вы можете выделить?
• Как приложением будет пользоваться конечный
пользователь?

Бриф
• Для каких платформ должно работать приложение? (Apple iOS,
Android, Windows Phone, Blackberry)
• Для какой платформы необходимо реализовать приложение в
первую очередь?
• Как должны обновляться данные в приложении?
• Существует ли необходимость разработки сайта-приложения?
• Кто будет заниматься технической поддержкой приложения?
Необходимо ли техническое обслуживание после гарантийного
обслуживания данного приложения?
• Существует ли необходимость создания системы управления
приложением?

Сроки. Деньги.
• Z — Нужное количество часов.
• Y — сумма (рейт) $/час.
• Z x 30% (риски) x Y = $X ХХХ
• 50% предоплата каждой итерации.

Фриланс или фултайм
.gif

Фриланс или фултайм
• Фриланс — хорошее начало для юниора.
• Фриланс — свобода работать круглосуточно.
• Фултайм — хороший/плохой начальник.
• Фултайм — наставничество, рост,
стабильность, большие проекты.

Стоит ли браться  
за этот проект?
• Нейминг, копирайтинг, шрифты, картинки и
прочая “чужая” работа.
• Красивая цена, но профиль не мой.
• Хотят до завтра, ночь без сна.

Что почитать:
• http://www.slideshare.net/jvetrau/design-
weekend-2014  
 
Юрий Ветров, “Продуктовый дизайнер.
Современное понимание профессии”
• “Runnig lean”. Пересказ одной из лучших книг
о стартапах: http://habrahabr.ru/post/243263/

Alex Lisovsky 
UX/UI designer 
 
alexander.lisovsky@gmail.com 
facebook.com/alexlisovsky, pinterest.com/alexlisovsky

Course User interface — Lesson 11

More Related Content

What's hot (20)

Similar to Course User interface — Lesson 11 (20)

More from Oleksandr Lisovskyi (20)

Course User interface — Lesson 11