Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:
Я работаю в компании, которая создаёт информационные системы для государственных больниц, и я получил задание разработать новую версию одной из систем с нуля. Управляет моей работой технический директор, который трудится в этой сфере больше 10 лет.
Директор предложил мне пофантазировать, как будет выглядеть интерфейс. Я ответил, что могу лишь предполагать, как используется система сотрудниками больниц, поэтому могу придумать не то, что им нужно, и попросил составить список пользовательских сценариев работы с этой системой. Директор уверил меня, что в этом нет необходимости, он сам прекрасно знает, кто и как использует систему и, если будет нужно, меня поправит. По мере разработки я стал считать, что директор отталкивается лишь от собственных представлений об облике системы; никто никогда не проводил исследования того, как предыдущая версия используется на местах и какие существуют проблемы при её применении сотрудниками.
Я боюсь, что бы двигаемся в неправильном направлении, и работа с системой станет мучением для сотрудников больниц. Как же мне сделать систему, удобную и понятную для конечного пользователя?
Николай Товеровский
Семён!
Я бывал в вашей шкуре, однажды я разработал систему для заместителей главврачей по экономике в государственных ЛПУ, основной фишкой которой был дрег-н-дроп. Я тогда работал программистом и реализовать перетаскивающиеся строчки, привязанные к базе данных, было для меня вызовом. Надо ли говорить, что система не пользовалась успехом, потому что заместителей главврачей мало волновал дрег-н-дроп, а об особенностях их работы я не догадался узнать?
Вы не создадите хороший продукт, если не станете его пользователем хотя бы на время. Не ждите сценариев от техдиректора. Разберитесь в задачах персонала больницы самостоятельно, почувствуйте их боль, услышьте замечания. Напроситесь в больницу: посидите рядом с докторами, а ещё лучше поработайте с системой в реальных условиях самостоятельно.
Если на презентации продукта пользователи скажут «наконец-то» и захлопают, значит, вы почувствовали их боль и предложили хорошее решение:
Если техдиректор сочтёт полевые исследования тратой времени, «продайте» ему важность вашего погружения. Как это сделать — зависит от настроя и отношения техдиректора. Выбирайте способ самостоятельно. Подсказки:
Объясните, что без этого вряд ли сделаете что-то стоящее.
Упомяните, что будете меньше приставать к нему с дурацкими вопросами.
Не придавайте исследованиям слишком большого визуального веса, упоминая «сценарии», «персонажей» и «юзабилити». Вы не собираетесь писать диссертацию, просто хотите поговорить с людьми.
P. S. Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.
я бы для начала поиграл в то, что техдиректор — надёжный источник информации. Спросил бы у него, что самое неприятное в текущей версии, что отнимает время, что просто бесит. Попросил бы показать, как он пользуется системой — любые выдуманные сценарии подойдут. Так или вы поймёте, что техдиректор действительно сечёт, или техдиректор отступит и поможет узнать правду.
«Объясните, что без этого вряд ли сделаете что-то стоящее» и «Упомяните, что будете меньше приставать к нему с дурацкими вопросами» — это плохие советы. Не ломитесь с объяснениями, задавайте вопросы.
Ваша ситуация типична для аутсорс-работников (хотя вы таковым не являетесь) — задаёшь вопросы, а в ответ тишина. Для дизайнера всегда проблема, если с ним взаимодействует «прослойка», а не заинтересованное лицо.
Тут есть два варианта. Первый: сделать того, с кем взаимодействуешь, союзником. Так или иначе, если его поставили на должность «контролёра дизайнера», от него ждут результатов. Свою работу нужно показывать ему через призму конечного результата для проекта в целом. Подготовительный этап — это работа. Важность этого этапа в глазах «контролёра» может быть необоснованно низкой, поскольку он не профильный специалист. Надо объяснить, как этот этап влияет на результат.
Второй вариант: импровизация. В идеальном мире проводится исследование аудитории, собирается информация о всяких ограничениях и возможностях, потом собирается прототип, тестируется и только потом делается дизайн и сборка. В реальном, первые два этапа заменяются брифом, ТЗ или пониманием задачи (хорошо, если работаешь с предпринимателем напрямую). В условиях ограниченного количества исходных данных можно и полезно применить навык эмпатии, подкреплённый собственным исследованием темы. Это не полноценное решение вашего вопроса, но судя по вашей ответственности за результат — этот подход может стать неплохой отправной точкой для хорошего интерфейса.
Поначалу работа «в полях» кажется потерей времени. Но контактируя «с тётками» на местах, закладывайте в их головы мысль о ваших возможностях. Оставляйте контакты. У многих есть родственники и знакомые, которым вы можете быть полезны. Со временем у вас наберётся критическое количество заказчиков, и вы сможете отбирать самые выгодные заказы.
