1. Юрий Ветров Форматы работы команды проектирования интерфейсов с клиентом и командой разработки UI Modeling Company

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

3. Проблемы клиента Возможности команды проектирования Ключевые параметры процесса Кейсы Выводы 3

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

5. Что нужно клиенту от проекта Ключевые слова, которые важно услышать клиенту: Быстро – так, чтобы успеть внедрить придуманное. Дешево – так, чтобы не пришлось выторговывать дополнительный бюджет «наверху», а если можно – сэкономить, сделав что-то внутренними силами. Качественно – так, что не нужно будет переделывать, будет готова всеохватывающая документация, продуманные и проверенные решения. Сразу знать все затраты - так, чтобы не было ползучего бюджета, понимать что не нужно будет заказывать что-то сверху. 5

6. Проблемы клиента Возможности команды проектирования Ключевые параметры процесса Кейсы Выводы 6

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

8. Что нужно проектировщику от проекта Ключевые слова, которые хочет услышать проектировщик: Прибыльно – так, чтобы покрыть издержки, заработать на развитие и персональный виш-лист. Опыт и наработки – такие, что их можно использовать в будущих проектах. Портфолио – такой проект и клиент, наличие которого поможет получить новые заказы. Риски – такие, что не сделают проект убыточным, репутацию подмоченной, а атмосферу в команде напряженной. 8

9. Проблемы клиента Возможности команды проектирования Ключевые параметры процесса Кейсы Выводы 9

10. 10 Когда мы подключаемся до начала работ – есть возможность повлиять на общую концепцию; уже в процессе разработки – возможности более ограничены, но время есть; в ходе эксплуатации – необходимо улучшать то, что уже есть;

11. 11 Кто отвечает за концепцию клиент – основы продукта задаются «сверху»; команда проектирования – предлагает и прорабатывает ее на основе общего направления; совместная выработка концепции;

12. 12 Тип взаимоотношений подряд – прямой заказ; субподряд – общение через промежуточный контакт; собственный проект; проект в партнерстве; привлекаемый консультант – без непосредственного участия в проекте;

13. 13 Состав работ концепция продукта – общее видение, целевая аудитория, ключевые функции; документация на интерфейс – детальное проектирование, дизайн, сопроводительные документы; консалтинг – рекомендации, помощь в выстраивании процесса внутри;

14. 14 Ресурсы бюджет – какие работы можно включить в процесс; сроки – когда и какие результаты будут нужны; доступность принимающих решения лиц – будут ли решения согласовываться быстро; политические ограничения – нет ли косвенных ограничений;

15. 15 Итеративность процесса в целом по проекту – «водопадные» или гибкие методики разработки; для работ по интерфейсу – как часто мы можем показывать результаты клиенту, обсуждать их и дорабатывать;

16. 16 Цена ошибки завязан ли продукт на управление критичными ресурсами (например, деньги), жизнью человека, экологией? есть ли возможность вносить изменения после запуска продукта?

17. 17 Кто принимает решения единствои согласованность принимающих решения на стороне клиента; доступность этих людей для команды проектирования; окончательность согласованных решений и понятный процесс их корректировки;

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

19. Проблемы клиента Возможности команды проектирования Ключевые параметры процесса Кейсы Выводы 19

20. 20 Will It Blend? Зная перечисленные параметры, важно выстроить правильный процесс взаимодействия команды проектирования с клиентом и командой разработки.

21. 1. Привлекаемый ресурс в большой команде разработки 21 на первых этапах или позже, участие по мере возникновения задач (равномерно на одних этапах и кусками на других) регулярный контакт с командой разработки и руководством проекта, периодически – с клиентом четко оговоренные куски работ в большом процессе – редко больше одной задачи определяются конкретной задачей, режутся легко, доступ к стейкхолдерам минимальный труднодоступны для влияния – клиент, руководство проектом (забот хватает и без интерфейса) жестко задан сверху, все что помимо него – личная инициатива в свободное время можно сэкономить ресурсы и не мешать разработке, при том что за интерфейсом все-таки будут следить; постоянная включенность в проект – проектировщик в курсе дел; влияние на интерфейс часто косметическое – качественно улучшить можно далеко не всегда; проектировщик не особо развивается как специалист;

22. 2. Собственный продукт крупной компании 22 на ранних этапах, активное участие по ходу всего проекта единая команда в тесном контакте – продукт-менеджер, группы проектирования и разработки полный – проработка концепции, подготовка документации на интерфейс, проверка решений хватает времени, можно использовать другие внутренние ресурсы, доступ к стейкхолдерам и пользователям единая команда в тесном контакте – продукт-менеджер, группы проектирования и разработки проектирование идет на несколько шагов впереди разработки, частые обсуждения и доработка промежуточных решений обширные возможности влияния на интерфейс проекта;постоянный доступ команды разработки к специалистам по интерфейсу;накапливание знаний и наработок. в некоторые проектные фазы ресурс работает вхолостую;специалист надолго зацикливается на одном проекте.

23. 3. Заказной проект в комплексе (проектирование + разработка) 23 в самом начале, активное участие в первой половине проекта и поддержка после запуска тесный контакт с клиентом и командой разработки на первом этапе, далее интенсивность меньше полный – проработка концепции, подготовка документации на интерфейс, проверка решений достаточно времени для проработки концепции (ближе к запуску его меньше), доступ к стейхолдерам команда проектирования – соавтор концепции, клиент – владелец бюджета и бизнес-целей, разработчики – технические решения предварительная проработка концепции, затем – проектирование на шаг впереди разработки; частые обсуждения вначале широкие возможности влияния на интерфейс; есть время и возможность проверить интерфейсные решения; контакт с разработчиками помогает взаимопониманию; возможны проблемы с передачей ответственности за видение продукта;

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

25. 5. Непрямой заказной проекттолько на проектирование 25 при хорошем раскладе – договоренность заранее, хотя часто в последний момент, когда нужно «вчера» субподряд – общение через менеджера проекта или аккаунта, что затрудняет предметное обсуждение интерфейса обычно только подготовка документации на интерфейс разброс вариантов большой, хотя времени бывает достаточно, но доступа к стейкхолдерам нет на стороне изначального заказчика, промежуточный менеджер проекта часто не может или не умеет влиять на давно принятые решения длительность обычно короткая, поэтому не так важен; итеративности как правило нет быстрая оборачиваемость; решения не всегда эффективны – не хватает итеративности процесса и доступа к принимающим решения;

26. 6. Помощь команде стартапа 26 на ранних этапах, часто до начала проекта, продолжение под вопросом из-за расползания концепции тесный контакт с клиентом (он же команда разработки), активное участие в формировании и проработке концепции полный – проработка концепции, подготовка документации на интерфейс, проверка решений времени хватает, доступ к стейкхолдерам есть, хотя с бюджетом часто есть вопросы часто полная энтропия – команда стартапа тесная, влияют на концепцию все; принятые решения легко меняются через час достаточно гибок, можно договориться на удобный для всех сторон вариант можно добиться хорошего влияния на интерфейс; процесс гибок; лучше быть частью этой команды концепция не устаканилась, поэтому корректируется ежедневно; проекты часто не доживают до реализации; основатели не всегда имеют опыт работы;

27. 7. Генерация идейдля работающего или планирующегося проекта 27 соответственно, перед началом редизайна или в процессе проработки концепции тесный контакт с клиентом, можно и нужно влиять на концепцию проработка концепции, подготовка предварительной документации на интерфейс времени и доступа к стейкхолдерам хватает, бюджет компактный, но достаточный клиент в плотной связке с командой проектирования; поскольку нужны идеи, работоспособность их не так важна предварительная проработка концепции, затем – проектирование; связки с разработкой как правило нет можно опробовать интересные и свежие идеи; нет давления сроков; увлекательный процесс для обеих сторон; речь идет об идеях, поэтому не факт что они будут внедряться;

28. 8. Легкий ремонт работающего продукта 28 перед небольшим редизайном, когда проблемы в продукте серьезно мешают его развитию тесный контакт с клиентом и командой разработки, хотя влиять на концепцию уже поздно подготовка документации на обновленный интерфейс, улучшение потребительских качеств продукта времени хватает, доступ к стейкхолдерам есть, но бюджет стараются держать компактным клиент в плотной связке с командой проектирования; в сложной корпоративной иерархии могут размываться изучение проблем, проработка их решения, оценка эффективности новых решений быстрая оборачиваемость; недорогой способ, решающий конкретные проблемы; сложно сделать качественные улучшения, часто нужно ограничиваться «косметикой»;

29. 9. Причесывание продукта перед запуском 29 в последний момент, когда уже сложно что-то серьезно изменить тесный контакт с клиентом и командой разработки, хотя влиять на концепцию уже поздно подготовка документации на обновленный интерфейс, улучшение потребительских качеств продукта по остаточному принципу – в ограниченное время и бюджет сделать хоть немного лучше команда разработки при одобрении клиента – внедрение изменений зависят от ее ресурсов быстрое изучение проблем, проработка их простых решений возможность быстро и дешево сделать продукт немного лучше не усложняя жизнь команде разработки; качественно изменить что-то уже сложно;

30. Проблемы клиента Возможности команды проектирования Ключевые параметры процесса Кейсы Выводы 30

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

32. Процесс проектированияв идеале Чтобы получить хорошее решение, необходимо проработать и обосновать его. Исследования Проектирование, дизайн Внедрение Развитие продукта Проверка решений 32

33. …и на самом деле Реальный процесс неидеален, но к нему нужно приспосабливаться и уметь работать в нем. Исследования Проектирование, дизайн Внедрение Развитие продукта Обоснование сделанных решений 33

34. Спасибо! Юрий Ветров www.jvetrau.com www.uimodeling.ru