Comments 28
UFO just landed and posted this here
Ну у нас раньше была недельная итерация.
Смотрите, простой расчет.
1. делаем раздел резюме — 40 часов
2. доработки, цикл 1 — 40 часов
3. доработки, цикл 2 — 40 часов
4. доработки, цикл 3 — 40 часов
общее время — 160 часов
Теперь упрощаем на этапе продумывания и этапе проектирования интерфейса ВСЕ. Делаем дубово, тупо, и просто. Вообще так, чтобы нельзя было ничего выкинуть.
1. раздел резюме, продумывание, итерация концепции, интерфейса, упрощение, упрощение и снова упрощение — 4 часа
2. реализация — 8 часов
3. доработки, цикл 1 — 8 часов
4. доработки, цикл 2 — 8 часов
5. доработки, цикл 3 — 8 часов
общее время — 44 часа.
при этом 160 часов = почти 364% от 44 часов, то есть выигрыш во времени 264%.
Смотрите, простой расчет.
1. делаем раздел резюме — 40 часов
2. доработки, цикл 1 — 40 часов
3. доработки, цикл 2 — 40 часов
4. доработки, цикл 3 — 40 часов
общее время — 160 часов
Теперь упрощаем на этапе продумывания и этапе проектирования интерфейса ВСЕ. Делаем дубово, тупо, и просто. Вообще так, чтобы нельзя было ничего выкинуть.
1. раздел резюме, продумывание, итерация концепции, интерфейса, упрощение, упрощение и снова упрощение — 4 часа
2. реализация — 8 часов
3. доработки, цикл 1 — 8 часов
4. доработки, цикл 2 — 8 часов
5. доработки, цикл 3 — 8 часов
общее время — 44 часа.
при этом 160 часов = почти 364% от 44 часов, то есть выигрыш во времени 264%.
Высосаные из пальца примеры, конечно, многое доказывают
реальные цифры таковы
1. две недели делали раздел резюме, 80 часов.
2. после смены концепции, сделали за 8, при этом я продумывал и упрощал 4 часа. еще 16 на доработки.
итого 80 против 28.
вопросы есть?
просто ВЫКИНУТО было 80% ненужных и сложных элементов логики, интерфейса, самой концепции
но сам мозг настроить на упрощение было очень трудно.
1. две недели делали раздел резюме, 80 часов.
2. после смены концепции, сделали за 8, при этом я продумывал и упрощал 4 часа. еще 16 на доработки.
итого 80 против 28.
вопросы есть?
просто ВЫКИНУТО было 80% ненужных и сложных элементов логики, интерфейса, самой концепции
но сам мозг настроить на упрощение было очень трудно.
Да, конечно же, такие гибкие процессы разработки/апробирования возможны только для сайтов, которые не являются основным инструментом пользователей. Иными словами, для сайтов, от функциональности которых не зависит бизнес.
Для приложений же, которые используются в корпорациях, нужен другой подход. Фича, однажды выкаченная в продакшен, должна сразу работать правильно и в дальнейшем не изменять свое поведение кардинально. В связи с этим для корпоративных приложений и нужна длинная фаза дизайна/проектирования, с продумыванием всего, что только можно, наперед.
Для приложений же, которые используются в корпорациях, нужен другой подход. Фича, однажды выкаченная в продакшен, должна сразу работать правильно и в дальнейшем не изменять свое поведение кардинально. В связи с этим для корпоративных приложений и нужна длинная фаза дизайна/проектирования, с продумыванием всего, что только можно, наперед.
нельзя продумать наперед. ну нельзя.
мы автоматизируем набор кадров. там полный ппц сейчас.
нет аналитики, какие резюме пришли, кто из пришедших дошел до собеседования, какие сайты сколько дают тех, кто потом будет принят, и т.д.
поэтому реально работающий инструмент.
или еще пример — я делал автоматизацию договоров. в CRM. цифры — десятки менеджеров, сотни договоров в день.
делал прототип, тестил логику, и внедрял. фидбэк в тот же день. и исправления.
так что это вопрос на уровне мозга. пока вы не попытаетесь оптимизировать свои процессы под быструю разработку — ничего не выйдет. сначала нужно осознать необходимость.
нет, не спорю, если у вас уже ДОРАБОТКИ — то да, они должны идти своим чередом. никто не торопится, все четко.
речь же в основном про новый функционал. тут нужно минимум левых расходов на ненужный функционал. указанная схема решает эту задачу лучше всего.
разумеется, это все поддается расчетам — когда нужна такая схема, когда нет. управление рисками.
мы автоматизируем набор кадров. там полный ппц сейчас.
нет аналитики, какие резюме пришли, кто из пришедших дошел до собеседования, какие сайты сколько дают тех, кто потом будет принят, и т.д.
поэтому реально работающий инструмент.
или еще пример — я делал автоматизацию договоров. в CRM. цифры — десятки менеджеров, сотни договоров в день.
делал прототип, тестил логику, и внедрял. фидбэк в тот же день. и исправления.
так что это вопрос на уровне мозга. пока вы не попытаетесь оптимизировать свои процессы под быструю разработку — ничего не выйдет. сначала нужно осознать необходимость.
нет, не спорю, если у вас уже ДОРАБОТКИ — то да, они должны идти своим чередом. никто не торопится, все четко.
речь же в основном про новый функционал. тут нужно минимум левых расходов на ненужный функционал. указанная схема решает эту задачу лучше всего.
разумеется, это все поддается расчетам — когда нужна такая схема, когда нет. управление рисками.
Никто не спорит, что итеративный подход очень рационален и с ним намного проще жить. Другой вопрос в том, что иногда его очень сложно применить. Вот, к примеру, какая-нибудь версия Excel. Ее невозможно продать тысячам пользователей на дисках, а через неделю выпустить следующую версию. Здесь целый производственный процесс замешан.
Вот так MS и поняли только через пару мажорных версий, что множество людей используют Excel для простых списков, а не для сложных многомерных таблиц с зависимостями и навороченными формулами :)
Конечно, с веб-приложениями проще, но, тем не менее, есть корпоративные веб-приложения, для использования которых корпорации заключают миллионные контракты и специально обучают сотни своих пользователей для работы с такими приложениями.
При выпуске новых версий переучивание должно оставаться минимальным.
А если одну неделю фича работает так, а другую неделю — эдак, то вашим приложением будут сильно недовольны. Затраты на переучивание пользователей-мартышек немало стоят.
Единственный выход в таком случае — хороший (и большой) отдел тестирования, который, кроме всего прочего, также изучает юзабилити, в т.ч. генерируя большие объемы данных и работая с ними. Опять же, это — недешевое удовольствие и не все могут себе его позволить.
Поэтому часто приходится хотя бы пытаться продумать все, что только можно, наперед.
Повторюсь, итеративный подход превосходен и это просто отлично, если вы можете его применить. К сожалению, это не всегда возможно.
Вот так MS и поняли только через пару мажорных версий, что множество людей используют Excel для простых списков, а не для сложных многомерных таблиц с зависимостями и навороченными формулами :)
Конечно, с веб-приложениями проще, но, тем не менее, есть корпоративные веб-приложения, для использования которых корпорации заключают миллионные контракты и специально обучают сотни своих пользователей для работы с такими приложениями.
При выпуске новых версий переучивание должно оставаться минимальным.
А если одну неделю фича работает так, а другую неделю — эдак, то вашим приложением будут сильно недовольны. Затраты на переучивание пользователей-мартышек немало стоят.
Единственный выход в таком случае — хороший (и большой) отдел тестирования, который, кроме всего прочего, также изучает юзабилити, в т.ч. генерируя большие объемы данных и работая с ними. Опять же, это — недешевое удовольствие и не все могут себе его позволить.
Поэтому часто приходится хотя бы пытаться продумать все, что только можно, наперед.
Повторюсь, итеративный подход превосходен и это просто отлично, если вы можете его применить. К сожалению, это не всегда возможно.
> нельзя продумать наперед. ну нельзя.
нельзя всех судить по себе. ну нельзя :)
нельзя всех судить по себе. ну нельзя :)
UFO just landed and posted this here
Отличный совет. Для продолжения и более всестороннего раскрытия темы советую почитать Getting Real.
Извиняюсь, конечно, но повысить эффективность на 10 порядков — это в 10000000000 раз. Если бы ваш метод работал хотя бы на половину того, что заявлено, любой проект делался бы полностью наилучшим образом и почти мгновенно.
Я, возможно, глупость скажу…
но зачем проектировщику самому все делать и исследовать? Заводить аккаунты, ворочать 1000 резюме — бесполезное дело, особенно на стадии заведения всех изначальных условий, соответствующих процессам компании-заказчика. А если компания оптовая и номенклатура — более 1 000 000 позиций в 678 рубриках? Сколько времени уйдет на моделирование таких условий?
По моему опыту достаточно посадить проектировщика рядом с оператором/пользователем на полдня или день, чтобы проектировщик понаблюдал, позадавал вопросы и записал себе типичные сценарии решения задач.
В идеале на входе проектировщику должен падать документ с описанием ЦА, их потребностями и предполагаемыми сценариями использования системы.
но зачем проектировщику самому все делать и исследовать? Заводить аккаунты, ворочать 1000 резюме — бесполезное дело, особенно на стадии заведения всех изначальных условий, соответствующих процессам компании-заказчика. А если компания оптовая и номенклатура — более 1 000 000 позиций в 678 рубриках? Сколько времени уйдет на моделирование таких условий?
По моему опыту достаточно посадить проектировщика рядом с оператором/пользователем на полдня или день, чтобы проектировщик понаблюдал, позадавал вопросы и записал себе типичные сценарии решения задач.
В идеале на входе проектировщику должен падать документ с описанием ЦА, их потребностями и предполагаемыми сценариями использования системы.
Это невозможно, к сожалению. Тут нужен некий «усреднённый» пользователь. А таких не бывает. Зато бывают специалисты по интерфейсам (типа Алана Купера, см. также его книги). Правда, в реальности я ни одного такого специалиста не встречал, но какие-то идеи из «About face 3» вполне можно использовать.
Что невозможно?
Есть конкретный пример в топике — менеджер по персоналу. Почему невозможно к нему посадить проектировщика?
Если же говорить про сайты «общего» пользования вроде корп.сайтов и магазинов, то вполне достаточно оперировать существующими и работающими паттернами, чтобы получить рабочий инструмент. Процесс выбора и покупки, благо, откатан на огромном множестве проектов.
Есть конкретный пример в топике — менеджер по персоналу. Почему невозможно к нему посадить проектировщика?
Если же говорить про сайты «общего» пользования вроде корп.сайтов и магазинов, то вполне достаточно оперировать существующими и работающими паттернами, чтобы получить рабочий инструмент. Процесс выбора и покупки, благо, откатан на огромном множестве проектов.
Тут нужен любой реальный пользователь решающий типичные для него задачи.
Вообще съем количественных критериев это одна из первых вещей, которую делает проектировщик.
В целом — быстрая итерационность это хорошо и правильно, но уж явные паттерны надо еще на этапе проектирования применять.
Вообще съем количественных критериев это одна из первых вещей, которую делает проектировщик.
В целом — быстрая итерационность это хорошо и правильно, но уж явные паттерны надо еще на этапе проектирования применять.
Я занимаюсь как раз созданием чек-листа — как опыт реальных пользователей (UX) переложить в интерфейс (UI). Это не стоит называть паттерном вообще, скорее — попытка приблизиться к осознанной методологии в этой отрасли.
Хороший интерфейс-разработчик должен быть супертребовательным к себе в первую очередь. Он должен сам у себя принимать свою же работу. Если что-то в его интерфейсе не нравится, значит нужно переделать.
А вообще правильно разрабатывать интерфейсы не для пользователей (странно звучит, но это правда), а для решения проблем пользователей. Это немного разные вещи. Нужно понимать как работает человек в реальности, и строить интерфейсы под его процессы. Например, есть контент-операторы, которые добавляют потоком контент в систему. Интерфейс должен быть заточен именно под непрерывное добавление данных. На практике это значит, что после добавления контента оператору нужно его просмотреть и принять решение о работе над новой операцией или редактированием/добавлением только что добавленной информации. Работа с архивом будет редкой.
Если это интерфейс пользователя контента, то нужно дать все механизмы и инструменты по быстрому и удобному просмотру. Это может быть информационная лента, календарь, архивы и так далее.
Интерфейс должен подвергаться постоянному рефакторингу. Удачные решения должны закрепляться и переделываться, неудачные — становиться достоянием истории.
Хороший интерфейс тот, в котором пользователю не нужна помощь со стороны разработчика и не требуется прочтение тонн документации.
А вообще правильно разрабатывать интерфейсы не для пользователей (странно звучит, но это правда), а для решения проблем пользователей. Это немного разные вещи. Нужно понимать как работает человек в реальности, и строить интерфейсы под его процессы. Например, есть контент-операторы, которые добавляют потоком контент в систему. Интерфейс должен быть заточен именно под непрерывное добавление данных. На практике это значит, что после добавления контента оператору нужно его просмотреть и принять решение о работе над новой операцией или редактированием/добавлением только что добавленной информации. Работа с архивом будет редкой.
Если это интерфейс пользователя контента, то нужно дать все механизмы и инструменты по быстрому и удобному просмотру. Это может быть информационная лента, календарь, архивы и так далее.
Интерфейс должен подвергаться постоянному рефакторингу. Удачные решения должны закрепляться и переделываться, неудачные — становиться достоянием истории.
Хороший интерфейс тот, в котором пользователю не нужна помощь со стороны разработчика и не требуется прочтение тонн документации.
Я последнее время склоняюсь к такой последовательности.
1. Краткий анализ
2. Быстрое прототипирование (функциональный прототип) — выявление грубых ошибок анализа.
3. Полный анализ
4. Полное проектирование и реализация
5. Мелочи добавляются итерационно
Иначе же мы получаем вот что:
1. Быстрая реализация
2. Фичи
3. Фичи
4. Агрр, код-лапша
5. Главный разрабочик: «Фиг кто кроме меня в этом разберется, хочу зарплату NNN$$$»
1. Краткий анализ
2. Быстрое прототипирование (функциональный прототип) — выявление грубых ошибок анализа.
3. Полный анализ
4. Полное проектирование и реализация
5. Мелочи добавляются итерационно
Иначе же мы получаем вот что:
1. Быстрая реализация
2. Фичи
3. Фичи
4. Агрр, код-лапша
5. Главный разрабочик: «Фиг кто кроме меня в этом разберется, хочу зарплату NNN$$$»
По-моему, очень утопическая картина. Прототип интерфейса без реализации функций никто не будет гонять на тысячах форм реальных данных, а удобство разового ввода и удобство массового ввода две очень большие разницы.
реализация за 1 день.
Не со всем согласен. Проектирование интерфейса проходит несколько стадий. На первой, графической, определяется объем, расположение и названия элементов. Реализация функций на этом этапе не важна. Но уже можно ответить на много вопросов. Прототип может выполнять задачу первой стадии, и ничего больше.
Логичное расположение окошек и контролов, рисование прототипов — все это номер два в списке задач проектировщика интерфейса.
Номер один — прогнать у себя в голове как можно более реалистичные сценарии использования будущей системы, поставить себя на место пользователя, выявить юзкейсы (use cases). Выявив юзкейс разбора сотен резюме, можно было легко понять, что автопереключение вкладок будет лишним.
Номер один — прогнать у себя в голове как можно более реалистичные сценарии использования будущей системы, поставить себя на место пользователя, выявить юзкейсы (use cases). Выявив юзкейс разбора сотен резюме, можно было легко понять, что автопереключение вкладок будет лишним.
Sign up to leave a comment.
Модели реальности в проектировании интерфейсов, или как поднять эффективность процесса в несколько раз