Ехала в новосибирском метро со стаканчиком кофе из одной кофейни. И думала об этом стакане: какой прекрасный пример системного анализа и промышленного дизайна.
В новосибирском метро есть правило: нельзя проходить на платформу с открытыми напитками, а также напитками в пластиковых и картонных стаканах: их можно смять, уронить и пролить горячий кофе на себя или другого пассажира.
Так вот те, кто проектировал это стакан, нашли способ обойти это правило, оставаясь в рамках правил. Да ещё и с комфортом для пользователя, это не может не восхищать!
Посмотрим на этот стакан через JTBD и сценарии. Задача пользователя примерно такая:
Когда я покупаю кофе по дороге, я хочу взять его с собой и продолжить свой маршрут, не пролив его и не создавая себе проблем с сотрудниками метро.
И если пользователь будет знать, что стаканчик этому соответствует, он с большей вероятностью будет заходить в кофейню чаще, зная, что потом с таким стаканом спокойно пойдёт в метро.
Его маршрут может выглядеть так:
кофейня → улица → метро → вагон → работа → поставить стакан на стол.
И на каждом этапе свои ограничения.
🟢На улице его нужно удобно держать одной рукой.
🟢В метро стакан не должен создавать проблем самому человеку, контролёру и окружающим.
🟢В вагоне он должен пережить толчки и движение.
🟢А приехав на работу, пользователь хочет просто поставить его на стол — и не ловить его потом по всей поверхности.
И вот дизайн решает эти ограничения свойствами самого предмета:
🟢 металл трудно смять;
🟢рельефная поверхность не даёт выскользнуть;
🟢теплоизоляция позволяет держать горячий кофе;
🟢плотная защёлка снижает риск пролива;
🟢прорезиненное дно не даёт стакану скользить.
А ещё это скидочная карта: покупаешь стакан — и кофе в нём на 20% дешевле. То есть один объект одновременно:
тара + термокружка + элемент программы лояльности + носитель бренда.
И вот это мне кажется очень системным подходом:
не как заставить пользователя соблюдать ограничения, а как спроектировать систему так, чтобы нужное поведение стало естественным.
По сути:
кто участники → какие у них JTBD → какие сценарии → какие ограничения → где конфликты → что можно изменить в самой системе.
И иногда результат этого анализа выглядит как фиолетовый металлический стакан с резиновым дном. Вот такая вот инженерия требований, которую можно потрогать руками ☺️