Семён Калинин
5 января 2017
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Я работаю в компании, которая создаёт информационные системы для государственных больниц, и я получил задание разработать новую версию одной из систем с нуля. Управляет моей работой технический директор, который трудится в этой сфере больше 10 лет.

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

Я боюсь, что бы двигаемся в неправильном направлении, и работа с системой станет мучением для сотрудников больниц. Как же мне сделать систему, удобную и понятную для конечного пользователя?


Семён!

Я бывал в вашей шкуре, однажды я разработал систему для заместителей главврачей по экономике в государственных ЛПУ, основной фишкой которой был дрег-н-дроп. Я тогда работал программистом и реализовать перетаскивающиеся строчки, привязанные к базе данных, было для меня вызовом. Надо ли говорить, что система не пользовалась успехом, потому что заместителей главврачей мало волновал дрег-н-дроп, а об особенностях их работы я не догадался узнать?

Вы не создадите хороший продукт, если не станете его пользователем хотя бы на время. Не ждите сценариев от техдиректора. Разберитесь в задачах персонала больницы самостоятельно, почувствуйте их боль, услышьте замечания. Напроситесь в больницу: посидите рядом с докторами, а ещё лучше поработайте с системой в реальных условиях самостоятельно.

Если на презентации продукта пользователи скажут «наконец-то» и захлопают, значит, вы почувствовали их боль и предложили хорошее решение:


  • Если техдиректор сочтёт полевые исследования тратой времени, «продайте» ему важность вашего погружения. Как это сделать — зависит от настроя и отношения техдиректора. Выбирайте способ самостоятельно. Подсказки:
  • Объясните, что без этого вряд ли сделаете что-то стоящее.
  • Упомяните, что будете меньше приставать к нему с дурацкими вопросами.
  • Не придавайте исследованиям слишком большого визуального веса, упоминая «сценарии», «персонажей» и «юзабилити». Вы не собираетесь писать диссертацию, просто хотите поговорить с людьми.
P. S. Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.

P. P. S. Я веду практический курс «Управление проектами, людьми и собой». Дата следующего курса пока неизвестна.

 
Мы напишем вам, когда будет открыта запись. Без спама.

Поделиться

Комментарии

Женя Арутюнов
5 января 2017

Семён,

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

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

Николай Яковенко
6 января 2017

Семён!

Ваша ситуация типична для аутсорс-работников (хотя вы таковым не являетесь) — задаёшь вопросы, а в ответ тишина. Для дизайнера всегда проблема, если с ним взаимодействует «прослойка», а не заинтересованное лицо.

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

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


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Как флексить. Отступить от идеала 2 Как защищать ОЧЕНЬ простые дизайнерские решения? Как флексить: сделать говно Как работать с классическими компаниями. Параллельная структура




Недавно всплыло

Меня бесит, что как клиент я должна переживать больше, а менеджер забивает 1 Директору магазина не понравился мой ответ, потому что, по его мнению, я унизила магазин 2 2 2



© 2007—2017

Запрещённые слова
Пишите: mail@artgorbunov.ru