Alexandr Gribenko's Infographics and Workflowy transcripts of events attended.
Цель: Публикация моих Workflowy записей различных событий, а также полезной инфографики.
Подключитесь к WorkFlowy и получите дополнительные 250 строк в месяц
UX Ukraine "Сбор требований заказчик-исполнитель"
Спасибо Ray Manson за выступление
- События UX-Ukraine
- UX-Ukraine на iforum
- серия мастерклассов по 40 минут
- условие входа - билет на iforum
- UXmayday - 2014
- майовка - россия, украина, белорусь
- на шашлыки. расслабляющее мероприятие. самоорганизация.
- в районе майских праздников.
- своя роль изначально
- есть идея совместить шашлыки с яхтой. 20+/-5 человек
- бюджет делится на человек.
- отслеживать UX Ukraine
- UX-Ukraine на iforum
- Сбор требований заказчик - исполнитель - темы дня
- как донести до заказчика, что от него зависит результат, а не только от исполнителя?
- важно понять - на каком этапе общения мы можем это донести.
- часто это происходит при прояснении бизнес целей и бизнес процессов - требует большего участия со стороны заказчика - подвигает его к мысле о его участии
- перепроверить бизнес процессы
- каким образом зафиксировать все требования (даша - bigmir)?
меня когда-то укусил злой юзабилист - Даша Волкова- транскрипты встреч
- примеры
- высылать выводы после встречи и требовать подтверждения / опровержения / вопросы
- строить mid maps общения
- mindmaster
- в письме - "жду подтверждения - только после этого перехожу к следующему этапу"
- повторять такие письма
- clients from hell
- как работать с эмоциями
как объяснить, что то, что хочет заказчик - плохо- задавить авторитетом
- есть сценарии в голове - нужно логически донести до клиента, что он в этом случае не прав.
- расскажите свой сценарий.
- метод 5 зачем? (root cause analysis - five whys)
- нужно найти несколько людей из целевой аудитории и попросить их дать реальную оценку при заказчике
- задавить авторитетом
- как рабоать с человеком, который не знает, чего он хочет?
- должен и как платить заказчик $ за понимание?
- никто не будет платить за presale
- все происходит в зависимости от рынка
- процесс сбора требований важен не только заказчику он также важен исполнителю - вы понимаете - с кем вы имеете дело - и стоит ли вообще продолжать
- как не надоесть заказчику с вопросами?
- нужно, чтобы заказчик понимал - зачем ему задают такой или иной вопрос
- этикет и адекватность
- в зависимости от типа клиента иметь паттерны вопросов + психология (что ответит в зависимости от типа человека)
- работа с ожиданиями
- если ты общаешься с человеком, которому интересно, и ты говоришь о том, что ему нужно - он сам будет готов отвечать на все вопросы.
- типы требований и приоретизация
- типы требований - requirement
- к дизайну
- к бизнес модели
- к frontend
- к backend
- к редакции
- технические
- ...продолжить.
- требования нужно классифицировать, хранить и передавать нужным участникам проекта
- может быть требование за которое мы не отвечаем - за него отвечают программисты
- требования к скорости работы - сокращение задержек между транзакциями
- как на стороне интерфейса сделать чтобы работало быстрее
- типы требований - requirement
- изменение требований
- мы переделаем это один раз, потом это будет за деньги
- документирование / согласование (отсылка к ответу - как зафиксировать требования)
- как донести до заказчика, что от него зависит результат, а не только от исполнителя?
- пример общения с заказчиком
- Саша - сервис совместных покупок
- идея - создание сервиса, собирает покупателей для выкупа
- реализовали проект - непонятно - что реализовали
- желание допилить/доделать
- делал подрядчик - компания
- роль в проекте - директор в компании.
- с партнером составляли ТЗ решали, как будет работать
- согласовываю
- утверждаю
- как это происходило?
- составили свой бриф
- отправили 15 студий
- получили предложение
- посмотрели на цену / портфолио / презентации на встрече
- выбрали подрядчика
- как ставили задачу
- встречались на каждом этапе
- мы сконцентрировались на движке, а не дизайне / UX
- когда пришло время делать дизайн - проект не вкладывался в сроки
- все решалось на быструю руку.
- как происходило определение функциональности на движке?
- мы встречались, обсуждали как должно работать.
- По модулям?
- нарисовали большую карту mindmap на каждом этапе кликаем сюда - приходим туда.
- реплика - мы работали над функционалом - это не юзабилити - юзабилити в конце
- мы встречались - потом я нарисовал карту
- мы встретились - подпилили и начали писать
- месяц они писали
- мне так и не показали несколько вариантов основных страниц без прописовки
- в период постановки задач было устное общение
- было
- говорили о том куда кликаем - куда попадаем
- небыло обсуждений - как должны быть оформлены дизайнерские блоки
- расположение на странице
- Леша - компания UFL - доставка цветов по украине/миру
- работаю с дизайнерами
- считаю - заказчиков нужно ловить - особенно в дизайне
- тендеры
- часто обращался к дизайнерам по рейтингу
- открытые тендеры на фрилансе
- сам заказываю и утверждаю
- если человек профессионал - в том числе и UX вижу, что нравится мне и видел у крутых компаний - я говорю Да
- профессионализм сразу чувствуется
- чтобы требовать предоплату нужно быть Лебедевым
- мне сложно нарисовать карту Midmap
- послушав я понял - что дизайн для меня сложная штука
- отдавал помошнику - рисовал квадратики белые дизайнерам - они рисовали как это будет выглядеть.
- мне как заказчику очень важно чтобы ко мне пришел подрядчик, спросил - опиши что ты хочешь.
- я покажу конкурентов
- расскажу - что мне еще хотелось бы
- в период постановки задач было устное общение?
- я отдаю программисту - он знает как порезать
- он напрямую общается с дизайнером и делают сайт
- Саша - сервис совместных покупок
- положительный опыт работы с заказчиком - Рей.
- Заказчик зачастую не в Украине
- Я
занимаюсь UX дизайном долгое время. Была своя студия. Работал над
разными проектами. 3-4 десятка магазинов, порталов, магазинов.
- надеяться на то, что к вам придет заказчик и все разложит - наивно
- нужно себя воспринимать в роли доктора
- люди приходят к доктору - показывают пальцами "бобо"
- доктор задает наводящие вопросы
- испольнитель выступает в этой же роли
- заказчик приходит - человек который не разбирается и приходит за экпертным мнением
- задача - вылушав сумбур - получить информацию, которая вам нужна
- если человек пришел к вам - он не дизайнер / разработчик
- "опытный больной" - уже пообщался с дизайн студиями и разработчиками и понимает - что ему нужно
- сбор требований как я вижду его "по-правильному"
- определиться с информацией, которая есть на входе
- информация разная по структуре и объему
- mindmapping - позволяет их многостраничных требований выстроить структуру
- структурирование позволяет увидеть проект в целом
- часто - является для заказчика открытием
- часто функционал есть - но он вообще не описан
- mindmapping - это только технология - молоток - без работы не решает проблемы
- анализ самой персоны заказчика
- очень важно понять - насколько человек вообще понимает - чем он собирается заниматься
- фразу "я хотел сделать украинский amazon" слышал два раза в месяц
- нужно понять - насколько люди в теме
- они в теме, если в состоянии в три часа ночи ответить - как и что будет работать
- в зависимости от уровня исполнителя заказчик в состоянии или не в состоянии заняться вопросом
- бизнес-анализ и анализ целей заказчика
- цель бизнеса, который хочет получить заказчик
- надо понять - что нужно бизнесу
- часто бизнес говорит, что хочет это - но нужно сказать, что делать не надо
- для заказчика интернет проект - это вложение
- сайт - это инструмент бизнеса
- перед тем, как делать заказ нужно оценить сайт - что он должен принести и это должна быть исчислимая величина
- при каком количестве заявок - этот сайт будет считаться эффективным?
- 1000 заказов в месяц
- сколько заказов сейчас?
- сейчас 100 заказов
- Насколько рально достичь поставленные цели?
- собирается ли меняться траффик?
- какое будет контентное наполнение?
- текущее количество заказов по какому траффику?
- важный вопрос - предполагаются ли новые источники траффика?
- вопрос - а что планируется менять в рекламной компании?
- анализ рынка
- емкость заказов на рынке есть?
- нам нужно увеличение в 10 раз.
- как зависит количество заказов от юзабилиста?
- при 100 заказах в месяц, посещаемость 10000 посетителей в день.
- какие источники траффика
- процентное соотношение orgainc и direct
- SEO по траффику
- сколько источников траффика - 10
- сколько прямого траффика - 10% - 10 заказов.
- разные каналы траффика даютс разные конверсии
- вопросы по поводу каналов/источников/таргетирования - тоже к юзабилистам
- анализ продукта (сайта)
- описать, кто является заказчиками продукта?
- какая аудитория? (часто бывает - начали с B2C - а пришли к B2B)
- какие планы клиента
- планы были развития на 5 лет
- через день они стали на 1 месяц
- целевая аудитория
- сегментировать аудиторию
- разбить на персон
- типажи людей (хотя бы групп)
- на персонажей должен быть ориентирован проект
- нужно выжимать всю воду, но чтобы живые люди остались
- если мы не можем выбросить кого-то чтобы не упала конверсия - не выпало звено - пора останавливаться
- в контексте бизнеса можешь охарактеризовать 5 категорий людей кому товар нужен больше всего
- персоны продукта
- это не возраст / секс
- персона не есть социология, а есть сценарий
- это событие / действие, которое происходит
- человек решающий какую-то задачу
- персона и сценарий идет парой - они неделимы
- какие у заказчика уже есть свои ресурсы
- придумали сайт - наделали скриншотов
- пришли к дизайнеру "надо такое", синенький цвет и девочку
- дизайнер запедалил
- текстов нет - секретарша из буклетиков текста насобирала
- верстальщик собрал
- программист на какую-то CMS повесил
- после этого приходят к SEO и далеют оптимизацию
- получаются такие франкенштейны с ботоксом
- новые ресурсы заказчика, которые потребуются
- разработка - это не только работа студии но и работа заказчика
- студия не в силах написать тексты - которые будут продавать (и ботам гугла тоже)
- нужны качественные фотографии
- нужно писать тексты
- лучший контент - часто - pdf который получают от вендора - фотографируют на iphone.
- 99% заказчиков не имеют выделенных ресурсов
- важный вопрос - если что-то должен сделать заказчик - рядом должна быть им написана фамилия исполнителя и желательно когда они (фамилии) РАЗНЫЕ
- проверка ресурсов - пришлите пожалуйста
- технические требования и ограничения
- с заказчиком нужно говорить на языке который ему понятен
- если он в состоянии описать сценарии и на основании с этим можно формировать тех требования
- можно обсуждать потом
- технические ограничения - которые существуют у заказчика
- определиться с информацией, которая есть на входе
- надеяться на то, что к вам придет заказчик и все разложит - наивно
Subscribe to:
Posts (Atom)