Специфика проектирования медицинских интерфейсов
Риск «сделать фигню» есть в любых проектах, но именно в медицинских ставки чрезвычайно высоки: это здоровье и жизни людей. Интерфейс может как помогать врачам и пациентам, так и вводить их в заблуждение и даже повышать вероятность ошибки с непредсказуемыми последствиями. Как именно снизить риски и на что нужно обратить внимание при создании интерфе…
Хорошо, что вы пишите такие статьи. Они дают представление, что дизайн - это оне только про интерфейс, но и про общение и поиск решений конретных задач. При этом было бы полезно увидеть количественные сравнения "до" и "после", ведь для профессионального интерфейса и именно это важно. Например, увидеть как изменилось среднее время выполнения типичных сценариев (на реальных данных или на GOMS модели), как изменилось количество ошибок в интерфейсе на 1000 сессий, NPS и т.д.?
Количественное сравнение — это обычно история про развитие существующего продукта, про его тюнинг. В общем случае этим занимаются инхаус-команды. В полный рост в екоммерсе, например, и крайне редко в профессиональных интерфейсах.
В профинтерфейсах (и в медицинских в частности) решают две задачи.
1. Сделать с нуля.
2. Переделать то, что однозначно устарело.
Даже пример есть. Пока еще секретный проект, в начале которого декларировалась цель — ускорить работу оператора. В процессе аналитики выяснили (и заказчик подтвердил), что такой проблемы нет, и скорость оператора больше зависит от его общения по телефону, чем от работы с интерфейсом. И наша дизайн-задача трансформировалась в создание обновленного интерфейса, который бы:
1. Учитывал изменения в бизнес-процессах.
2. Был более гибким в настройках под конечного клиента.
3. Позволял заказчику самостоятельно развивать интерфейс (добавлять новые процессы).
4. Давал конкурентное преимущество при продаже.
Т.е. результат работы дизайн-команды в нашем случае — это всегда довольно сложные бизнесовые показатели. Более того, мы не можем влиять на них на все, мы вносим свой вклад.
ХЗ, может этот комментарий выглядит как отмазка. Но реальность такова, что мы бы сами с радостью поработали над проектом, где есть четкие метрики, которые нужно улучшить. Просто как челлендж! Но нет таких задач.