Модели реальности в проектировании интерфейсов, или как поднять эффективность процесса в несколько раз

    Многие сегодня применяют прототипирование, разрабатывая в самом начале проекта прототипы интерфейсов. Хорошо известно, что исправлении ошибки на этом этапе стоит в разы дешевле, чем на более поздних этапах.

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

    Как находить ошибки этого рода, бороться с ними, и пример из реальной практики читайте внутри.

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

    Для начала нужно осознать, что сама ошибка существует. Обычно человек уверен, что он может спроектировать интерфейс именно так, как это будет в самом конце, сделать «все правильно» и «все продумать». Но думать так — заблуждение.

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

    При этом проверка верности или неверности должна проходить на конечных пользователях продукта, в продукте должны быть живые (а не тестовые) данные, все должно быть реальным.

    Во-вторых, нельзя продумать на 100% на начальном этапе. Можно принять за аксиому — если не тот редкий случай, когда проектировщик интерфейса или разработчик концепции проекта имеет глубокий опыт в сфере проекта, в 99% случаев все сложные фишки будут мимо.

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

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

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

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

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

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

    Если бы проектировщик поработал с сотней резюме, а не десятком, решая реальную задачу, он бы не допустил этой ошибки. Ее исправление стоило пары часов работы программиста, а их могло бы и не быть. Также и с фильтром по ФИО — если бы человек попробовал работать с 1000 резюме, он бы понял, что фильтр по ФИО очень необходим.

    Собственно, многие стартапы оказываются ненужными потому, что люди считают
    себя умнее своих пользователей, и создают никому не нужные интерфейсы, движки и проекты, тратя свое время и деньги (а зачастую не только свое).

    Стоит заметить, что этот подход является паттерном в широком смысле слова. Это значит, что его можно применить в любой сфере. Например, в программировании — получить ТЗ от заказчика, набросать прототип, верный с точки зрения логики, но в коде «как быстрее». Показать тут же, получить список доработок, и так до тех пор, пока основная логика не будет сделана. Дальше отрефакторить, и сделать уже точно. Такой подход позволит сэкономить от 100% до 1000% вашего времени, и времени заказчика.

    Желаю вам, чтобы в ваших проектах процент нужного функционала стремился к 100%!

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 28

    • UFO just landed and posted this here
        +1
        Ну у нас раньше была недельная итерация.

        Смотрите, простой расчет.

        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%.

          +6
          Высосаные из пальца примеры, конечно, многое доказывают
            0
            реальные цифры таковы

            1. две недели делали раздел резюме, 80 часов.
            2. после смены концепции, сделали за 8, при этом я продумывал и упрощал 4 часа. еще 16 на доработки.

            итого 80 против 28.

            вопросы есть?

            просто ВЫКИНУТО было 80% ненужных и сложных элементов логики, интерфейса, самой концепции

            но сам мозг настроить на упрощение было очень трудно.
          +1
          Да, конечно же, такие гибкие процессы разработки/апробирования возможны только для сайтов, которые не являются основным инструментом пользователей. Иными словами, для сайтов, от функциональности которых не зависит бизнес.

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

            мы автоматизируем набор кадров. там полный ппц сейчас.

            нет аналитики, какие резюме пришли, кто из пришедших дошел до собеседования, какие сайты сколько дают тех, кто потом будет принят, и т.д.

            поэтому реально работающий инструмент.

            или еще пример — я делал автоматизацию договоров. в CRM. цифры — десятки менеджеров, сотни договоров в день.

            делал прототип, тестил логику, и внедрял. фидбэк в тот же день. и исправления.

            так что это вопрос на уровне мозга. пока вы не попытаетесь оптимизировать свои процессы под быструю разработку — ничего не выйдет. сначала нужно осознать необходимость.

            нет, не спорю, если у вас уже ДОРАБОТКИ — то да, они должны идти своим чередом. никто не торопится, все четко.

            речь же в основном про новый функционал. тут нужно минимум левых расходов на ненужный функционал. указанная схема решает эту задачу лучше всего.

            разумеется, это все поддается расчетам — когда нужна такая схема, когда нет. управление рисками.
              +2
              Никто не спорит, что итеративный подход очень рационален и с ним намного проще жить. Другой вопрос в том, что иногда его очень сложно применить. Вот, к примеру, какая-нибудь версия Excel. Ее невозможно продать тысячам пользователей на дисках, а через неделю выпустить следующую версию. Здесь целый производственный процесс замешан.
              Вот так MS и поняли только через пару мажорных версий, что множество людей используют Excel для простых списков, а не для сложных многомерных таблиц с зависимостями и навороченными формулами :)

              Конечно, с веб-приложениями проще, но, тем не менее, есть корпоративные веб-приложения, для использования которых корпорации заключают миллионные контракты и специально обучают сотни своих пользователей для работы с такими приложениями.
              При выпуске новых версий переучивание должно оставаться минимальным.
              А если одну неделю фича работает так, а другую неделю — эдак, то вашим приложением будут сильно недовольны. Затраты на переучивание пользователей-мартышек немало стоят.

              Единственный выход в таком случае — хороший (и большой) отдел тестирования, который, кроме всего прочего, также изучает юзабилити, в т.ч. генерируя большие объемы данных и работая с ними. Опять же, это — недешевое удовольствие и не все могут себе его позволить.

              Поэтому часто приходится хотя бы пытаться продумать все, что только можно, наперед.
              Повторюсь, итеративный подход превосходен и это просто отлично, если вы можете его применить. К сожалению, это не всегда возможно.
                0
                Да, согласен, не всегда возможно. Я и пишу, нужно рассчитывать целесообразность применения.
                0
                > нельзя продумать наперед. ну нельзя.

                нельзя всех судить по себе. ну нельзя :)
              • UFO just landed and posted this here
              +1
              Отличный совет. Для продолжения и более всестороннего раскрытия темы советую почитать Getting Real.
                +2
                вот вот.

                я ее читал 3 года назад. но читать, знать и ПРИМЕНЯТЬ — это разные вещи.

                когда мы стали релизить каждый день (поначалу было трудно подстроить процессы), я ощутил кайф и с тех пор являюсь фанатом быстрых прототипов везде. максимально просто и быстро, и итерировать, итерировать, итерировать…
                +6
                Извиняюсь, конечно, но повысить эффективность на 10 порядков — это в 10000000000 раз. Если бы ваш метод работал хотя бы на половину того, что заявлено, любой проект делался бы полностью наилучшим образом и почти мгновенно.
                  0
                  исправил «на несколько»

                  спасибо
                    +10
                    Не боюсь показаться занудой — но «несколько порядков» тоже как-то нескромно. Это же в сотни-тысячи раз! Напишите уже в «несколько раз» и не смущайте массы :)
                  0
                  Я, возможно, глупость скажу…
                  но зачем проектировщику самому все делать и исследовать? Заводить аккаунты, ворочать 1000 резюме — бесполезное дело, особенно на стадии заведения всех изначальных условий, соответствующих процессам компании-заказчика. А если компания оптовая и номенклатура — более 1 000 000 позиций в 678 рубриках? Сколько времени уйдет на моделирование таких условий?

                  По моему опыту достаточно посадить проектировщика рядом с оператором/пользователем на полдня или день, чтобы проектировщик понаблюдал, позадавал вопросы и записал себе типичные сценарии решения задач.
                  В идеале на входе проектировщику должен падать документ с описанием ЦА, их потребностями и предполагаемыми сценариями использования системы.
                    0
                    Это невозможно, к сожалению. Тут нужен некий «усреднённый» пользователь. А таких не бывает. Зато бывают специалисты по интерфейсам (типа Алана Купера, см. также его книги). Правда, в реальности я ни одного такого специалиста не встречал, но какие-то идеи из «About face 3» вполне можно использовать.
                      0
                      Что невозможно?
                      Есть конкретный пример в топике — менеджер по персоналу. Почему невозможно к нему посадить проектировщика?

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

                        А сайты общего пользования — это отдельный пример ненависти. В большинстве своём они дико, фатально неудобны, хотя вполне рабочие. Но вот по-настоящему удобных сайтов среди них единицы.
                        0
                        Тут нужен любой реальный пользователь решающий типичные для него задачи.
                        Вообще съем количественных критериев это одна из первых вещей, которую делает проектировщик.

                        В целом — быстрая итерационность это хорошо и правильно, но уж явные паттерны надо еще на этапе проектирования применять.
                      0
                      Я занимаюсь как раз созданием чек-листа — как опыт реальных пользователей (UX) переложить в интерфейс (UI). Это не стоит называть паттерном вообще, скорее — попытка приблизиться к осознанной методологии в этой отрасли.
                        0
                        Хороший интерфейс-разработчик должен быть супертребовательным к себе в первую очередь. Он должен сам у себя принимать свою же работу. Если что-то в его интерфейсе не нравится, значит нужно переделать.

                        А вообще правильно разрабатывать интерфейсы не для пользователей (странно звучит, но это правда), а для решения проблем пользователей. Это немного разные вещи. Нужно понимать как работает человек в реальности, и строить интерфейсы под его процессы. Например, есть контент-операторы, которые добавляют потоком контент в систему. Интерфейс должен быть заточен именно под непрерывное добавление данных. На практике это значит, что после добавления контента оператору нужно его просмотреть и принять решение о работе над новой операцией или редактированием/добавлением только что добавленной информации. Работа с архивом будет редкой.

                        Если это интерфейс пользователя контента, то нужно дать все механизмы и инструменты по быстрому и удобному просмотру. Это может быть информационная лента, календарь, архивы и так далее.

                        Интерфейс должен подвергаться постоянному рефакторингу. Удачные решения должны закрепляться и переделываться, неудачные — становиться достоянием истории.

                        Хороший интерфейс тот, в котором пользователю не нужна помощь со стороны разработчика и не требуется прочтение тонн документации.
                          0
                          да, для решения проблем пользователей.
                          +2
                          Я последнее время склоняюсь к такой последовательности.

                          1. Краткий анализ
                          2. Быстрое прототипирование (функциональный прототип) — выявление грубых ошибок анализа.
                          3. Полный анализ
                          4. Полное проектирование и реализация
                          5. Мелочи добавляются итерационно

                          Иначе же мы получаем вот что:

                          1. Быстрая реализация
                          2. Фичи
                          3. Фичи
                          4. Агрр, код-лапша
                          5. Главный разрабочик: «Фиг кто кроме меня в этом разберется, хочу зарплату NNN$$$»
                            0
                            По-моему, очень утопическая картина. Прототип интерфейса без реализации функций никто не будет гонять на тысячах форм реальных данных, а удобство разового ввода и удобство массового ввода две очень большие разницы.
                              0
                              реализация за 1 день.
                                0
                                Не со всем согласен. Проектирование интерфейса проходит несколько стадий. На первой, графической, определяется объем, расположение и названия элементов. Реализация функций на этом этапе не важна. Но уже можно ответить на много вопросов. Прототип может выполнять задачу первой стадии, и ничего больше.
                                +1
                                Логичное расположение окошек и контролов, рисование прототипов — все это номер два в списке задач проектировщика интерфейса.

                                Номер один — прогнать у себя в голове как можно более реалистичные сценарии использования будущей системы, поставить себя на место пользователя, выявить юзкейсы (use cases). Выявив юзкейс разбора сотен резюме, можно было легко понять, что автопереключение вкладок будет лишним.

                                Only users with full accounts can post comments. Log in, please.