Что официант делает с монитором?

https://javlaskitsystem.se/2012/02/whats-the-waiter-doing-with-the-computer-screen/
  • Перевод
Когда Ричард Гатарски с друзьями несколько недель назад хотели пообедать в шведском городе Норчёпинг, они забронировали столик вроде в неплохом итальянском ресторане в центре города.

По прибытии метрдотель их приветствовал и спросил, забронирован ли столик. Ричард подтвердил — и метрдотель посмотрел на экран компьютера.

— Гатарски? Хм, посмотрим… вот ваша бронь. Добро пожаловать!

Затем он взял что-то, что Ричард сначала принял за некую новую разновидность сенсорного стилуса — и провёл по экрану. Ричард — технически подкованный интернет-предприниматель, поэтому ему стало интересно, что за гаджет используют в этом ресторане. Он наклонился немного ближе…


Метрдотель отмечает прибывающих гостей на экране — обычным маркером! (нажмите для увеличения). Фото: Ричард Гатарски

… и вдруг понял, что это совершенно обычный маркер для доски. Метрдотель просто ставил крестик над бронью, прямо на экране!

«Очень интересно. Зачем вы так делаете?», — спросил Ричард

«Ну знаете, — тяжко вздохнул метрдотель. — Те ребята, которые создают такие системы… у них как бы это сказать… ну нельзя всё сделать как хочешь. Можете проверить бронирование в системе с помощью мыши, но это как минимум четыре клика от этого экрана. И непонятно, сели гости за столик или ждут в баре. Так что гораздо проще просто нарисовать на экране. (А когда вечер закончится, просто протереть экран тряпкой). Мы тут очень заняты, и это прекрасно работает».

Еда, кстати, была отличной.

* * *

Итак, о чём эта реальная история говорит нам?

  1. Компьютерные системы не всегда используются так, как предполагают разработчики.
  2. Люди творческие. Если возможно, они найдут способ упростить повседневные задачи.
  3. «Мы очень заняты». У пользователей есть много более важных дел на работе. Вместо того, чтобы тратить время на изучение вещей с неочевидной ценностью, они лучше потратят его на то, что считают более важным (например, сделать лучший соус, который когда-либо пробовал клиент).
  4. Не лишние ли расходы на электронную систему бронирования? Обычная маленькая доска, вероятно, проще и дешевле.
  5. Существует вероятность, что компьютерная система бронирования (в отличие от реальной доски) может генерировать некоторую статистику: количество посетителей в месяц, типичный профиль бронирования в течение недели, процент занятых столов за любой период… И продавцы компьютерных систем (всех видов, во многих компаниях), как правило, преподносят эти функции как большие преимущества. Но стоят ли они усилий? Во многих случаях метрдотель, вероятно, бóльшую часть действительно важной информации знает по опыту или эмпирически. Так что вероятно не стоит напрягаться с большим количеством кликов просто для генерации этих данных.
  6. И наконец, чтобы действительно понять, что важно для пользователей и как на самом деле используется система, нужно наблюдать реальных пользователей за работой.

Что это: я шведский дизайнер UX и автор, специализирующийся на системах, которые используются на работе. Этот блог — о моей последней книге, в которой рассказывается, как такие плохо спроектированные системы становятся главной причиной стресса (и приводят в итоге к проблемам со здоровьем). Можете прочитать немного больше об этом на английском языке здесь. Я в твиттере @jonas_blind_hen.


Крестики и заметки на экране. Фото: Ричард Гатарски

(Кстати, книга здесь довольно успешна; возглавляет список бестселлеров в своей категории).

Если вам понравилась история, может, вы найдёте интересным другой реальный пример из системы здравоохранения: врач, качающий мышку (24 сентября 2012 года).

Большое спасибо Ричарду, что поделился этим! :)
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 41
  • +2
    Хорошая запись для инстаг...oh shi~
    Компьютерные системы не всегда используются так, как предполагают разработчики.
    Проблема плохого дизайнера, не заинтересованного в решении задачи.
    • +1
      Или проблема в менеджменте заведения, не выделившим бюджет на покупку сенсорного монитора.
      • +2
        Так забота «4 кликов от текущего экрана» никуда не делась бы даже с сенсорным. Если только, конечно, интерфейс не перестраивается под сенсор таким волшебным образом, что все становится ровно в одном касании экрана от любой текущей точки (спойлер — такого не будет; если бы разработчики включали голову, наблюдая за реальным использованием ПО живими людьми, а не писали UI с учетом только своих фантазий о том, как люди будут использовать их творение, то и «трех кликов» не было бы; от таких «одного касания» уже нет смысла ждать).
        • 0
          Если маркером отмечают, и всё в порядке — точно так же отмечали бы ОДНИМ касанием чекбокс.
          Но при этом была бы обратная связь в системе.
          • +3
            Только чекбокса там нет — крестик рисуют именно потому, что нет элемента, который можно щелкнуть (буквально — «в который ткнуть») мышкой.

            По уму, авторам надо бы посмотреть на это безобразие костыльное, но работающее для юзера решение, и приделать чекбокс. Но, сами знаете, переделка никогда не бывает быстрой, и не будет она быстрой и под тач-экраны.
            • +1
              Так взять маркер и отметить на экране, положить маркер — это уже три действия. Реально было бы легче коснутся четыре раза экрана.
              Тоесть все таки проблема в отсутствии тач панели.
              • +1
                было бы легче коснутся четыре раза экрана.
                Но вы ведь не знаете скорость отклика экрана, скорость загрузки 4х следующих экранных форм. Возможно, при клике на клиента там подгружается вся его история посещений, и это занимает время(которое так и бесит официантов), а может и вообще зависнуть если канал просел(скажем, там 3g, а на улице гроза).

                Поэтому было бы легче коснуться экран 1 раз, чтобы на месте клиента появился крестик.
                • +1
                  Естественно.
                  А может стоило сверху реализовать пометки от тачскрина.
                  Но тач-скрин все равно был бы быстрее без необходимости дополнительной разработки.
                  • +1
                    И возможно давал бы ложные срабатывания от маркера, поэтому его бы отключили на следующий же день. </sarcasm>
                • +2
                  Нет. Взять маркер — это не действие в понимании простого пользователя. Так же, как «крестик» — это не два действия (линия одна, линию другая), а, психологически, все же одно.
                  А вот прощелкать 4 экрана, чтобы добраться до «свойств» стола, и поставить в нем «люди пришли» — это 4 визуально разные картинки (не считая времени на ожидание рендера/анимации).
                  Т.е. для сотрудника ресторана «крестик» менее затратен. Не говоря, что ставя его, человек не меняет себе визуальный контекст, и всё время видит на экране весь зал.

                  Уточню: я не против тача, но корневая проблема не в его отсутствии, а в непродуманности UI.
                  • 0
                    Да вроде уже проводили эксперемент с тачскринами.
                    Пользователи останавливаются на большем количестве однотипных действий(разными пальцами автоматически нажимаешь за мгновения).
                    А чтоб взять маркер, его надо поискать сначала. Влом.
                    • 0
                      Речь не об этом. Речь о том, что косяки в UI резко не решить, просто заменив экран на тач-скрин. Редизайн поможет, добавление тача еще больше поможет, но сам так не серебрянная пуля.

                      А вообще, если человеку «влом», когда он в сфере обслуживание — пусть пойдет и уволится. Порой бывает впечатление, что за рубежом сотрудники кафе и ресторанов работают, а в России ищут, почему не работать. Если с этой колокольни судить, то, и правда, «маркер поднять тяжело».
                      • 0
                        А на деле — изменить интерфейс в системе, при желании это дело двух-трех дней, если это конечно не «большая сплоченная команда профессионалов, где каждый на „пять“ знает свою работу», такие обычно по пол года правят простые баги а уж эргономику вообще за баг не считают.
                      • +1
                        А чтоб взять маркер, его надо поискать сначала. Влом.

                        Только не в том случае когда заранее известно где он лежит.

              • 0
                Не факт, что проблема вообще была. Об этом рассказал гений, пишущий маркером на экране.
          • –4
            «врач, качающий мышку» => «прибор для взбалтывания крови трясёт мышку».
            Кстати, Win10, не могу отключить залочивание экрана.
            Кто-то победил?
            Скринсейвер отключил, локскрин отключил…
          • +4
            geektimes.com/post/138861 Впрочем лишний раз интересно вспомнить.
          • 0
            Ну это примерно как экран обклеенный стикерами когда на компьютере есть планировщик заданий, записная книжка и прочее
            • 0
              В сабже речь о плохом дизайне, а реализация sticky notes/блокнотов это уже особенность многозадачных ОС, где обычно сначала нужно вызвать саму программу, дождаться ее загрузки, нажать на кнопку добавления заметки и т.п. (во многих случаях бумажные записи удобнее по этой причине)
            • +1
              Одни мои знакомые, в числе прочего, время от времени, поставляют разные системы для охранных предприятий. Для АРМ оператора видеонаблюдения всегда заказывается антивандальный монитор, у которого хорошее стекло. Потому, что с плохого в какой-то момент перестаёт стираться маркер, а маркер там используется постоянно для отмечания точек в видеоизображении.

              Оператору тяжело в одном видео следить за несколькими предметами, поэтому он отмечает их кружками или стрелочками, чтобы быстро на них возвращаться.
              • 0
                Может лучше добавить функционал, который позволит делать это без маркера? А если совместить с системой распознавания образов, станет ещё удобнее.
                Но разработчику проще заказать стекло…
                • +1
                  Разработчику и поставщику однозначно проще и дешевле заказать стекло, так как за стекло заплатит клиент, стекло не потребует работы бизнес-аналитика, разработчиков, тестировщика, не накопит технический долг, и не внесёт новых багов в проект.
                  • –2
                    Если коротко, то я сказал примерно тоже самое. Проще — не значит лучше.
              • 0
                Компьютерные системы не всегда используются так, как предполагают разработчики.
                Если возможно, люди творческие найдут способ упростить повседневные задачи.

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

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

                А чему тут удивляться? Вопрос-то сводится к «шашечки, или ехать?»
                • +1
                  Я по своему опыту знаю, что разработчики часто витают в облаках и совершенно неправильно представляют себе сценарии использования их софта и те места, которые представляют наибольшую ценность для пользователя. Просто потому что сами им не пользуются. Я сам в такое попадал.
                  В итоге часто получается такой вот неудобный продукт. А разработчики оказываются и не в курсе проблем, потому что пользователям проще маркером на экране рисовать, чем пропихивать свои предложения по улучшению через несколько слоев менеджмента (сперва своего, а потом чужого) чтобы они дошли до исполнителя и что-то исправили (а скорее всего ничего не исправят, а скажут в духе «ваш отзыв очень важен для нас, идите нафиг»).

                  И поэтому полезно разработчикам об этом регулярно напоминать чтобы хоть как-то вернуть их с небес на землю и заставить их ставить себя на место пользователя.
                  • 0
                    Это обязанность разработки? Разработчики должны получать уже формализованные требования на основании аналитики и исследований юзкейсов.
                    • +2

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

                      • +1
                        что-то мне подсказывает, что требования это еще и графические сториборды (макеты, вайеры — называйте как хотите), сделанные (а лучше бы еще и протестированые на стадии прототипа) дизайнером
                        • 0
                          В теории — да. На практике встречал в лучшем случае сляпанные на коленке прототипы, никак не протестированные (опять же на ком их тестировать? Менеджерам главное чтобы красиво было, а линейному персоналу некогда, ему гостей обслуживать надо), и страдающие ровно теми же ошибками.
                          Если вам довелось получать от заказчика что-то в таком виде, как вы пишете — ну тут могу только позавидовать.
                          Сам я пытаюсь периодически пинать начальство на тему проведения юзабилити тестирования и сбора отзывов, но обычно это заканчивается ничем. Удобство рядового пользователя в b2b сегменте мало кого волнует, так как персонал там все равно подневольный, и будет пользоваться вашим софтом независимо от его удобства, так как ему сверху приказали. А «наверху» удобство, как я уже писал, тоже никого не волнует, так как менеджеры сами этим софтом не пользуются, или пользуются только его отчетно-статистической частью.
                          • 0
                            Да, это большая продлема индустрии. В инете немало статей на инглише на тему Why enterprise software sucks. Сам там на таком заводе работал, но вовремя свалил. Радует, что парадигма потихоньку сдвигается в сторону здравого смысла и не все делают софт только чтобы менеджер доволен был.
                      • 0
                        должны получать уже формализованные требования
                        Попахивает холиваром, но скорее всего вы говорите не про разрабочиков, а про людей, «которые умеют кодить». Хотя и само понятие «разработчик» нигде не формализовано.
                        • +1
                          Возможно. Если абстрагироваться и представлять разработчиков как продуктовую команду в целом, то со сказанным я согласен.)
                        • +3
                          Это если говорить о сферических разработчиках в вакууме. А в реальности это проблема всех, в том числе и разработчиков. Потому что когда делаешь какой-то продукт, то надо всё-таки немного думать и о том зачем и для кого ты его делаешь.

                          И это кстати один из параметров который в моих глазах отличает сениора/техлида от миддла/джуниора. То есть если хочешь быть сениором, то умей не только реализовать формализованные требования один к одному, но и заметить «ошибку» в этих самых требованиях. Хотя это всё конечно очень субъективно.
                    • 0
                      Почитайте про доктора, там не только мышка, там ещё и закрытие окна убрали бумажкой:
                      www.flickr.com/photos/henrikahlen/8005807308
                      • 0
                        :) Вот есть Material Design. Google призывает рисовать «материальные» интерфейсы — которые можно «потрогать».
                        Здесь мы видим новый виток эволюции.
                        • 0
                          вспоминаю одного ПМ-а в нашем офисе, который по экранам теликов маркером рисовал (при этом не вытирал за собой) и ему вечно за это хотели морду набить ))
                        • 0

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

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое