Записки о работе, Проектирование, 31 октября 2014
Эту неделю посвятил проектированию небольшой CRM системы, которая должна решить локальные задачи клиента по обработки около 120 000 контактов силами отдела из 30 сотрудников.
Честно говоря, вначале я попробовал найти уже готовое решение. Готовое решение всегда проще: его не надо программировать, его не надо тестировать и т.д. Всегда можно сослаться на то, что это делал не ты. Но главный аргумент это все-таки то, что можно сэкономить свои нервы и силы на разработке. Ведь я прекрасно понимал, что после проектирования придется еще и проконтролировать, чтобы все сделали как надо, а потом еще и запустить систему в эксплуатацию. А это может оказаться очень непросто.
Посмотрел несколько бесплатных CRM и сожалением должен был признаться, что донастройка готовой системы окажется не менее трудоемким процессом ,чем разработка с нуля.
Нужна «лопата», но все предлагают «экскаватор»
В итоге я начал просматривать интерфейсы хорошо документированных систем, чтобы найти в них идеи или подсмотреть решения. Вот итоговый список, на котором я сконцентрировался:
Самой полезной оказалась Zurmo, но даже идеи, которые я подсмотрел там, в итоге пришлось отсеять. И так я подошел к решению делать все (точнее проектировать) с нуля, т.е. со своих сценариев взаимодействия системы и пользователей.
«За» и «против» разработки CRM с нуля
Самый существенный аргумент «против» — это низкая подготовка меня как проектировщика и продукт-менеджера (в этом проекта) с точки зрения теории разработки CRM систем.
Умом я понимаю, что за всеми хорошими интерфейсами лежит методология, которая позволяет не только сделать удобный интерфейс, но и эффективно организовать работу людей. Времени на изучения теорий управления, методик менеджмента, моделей взаимодействия у меня нет, поэтому при проектировании остается опираться только на логику и здравый смысл.
В принципе, я высокого мнения о своей логике и проект небольшой, с локальными функциями (не будет интеграции во внешние системы) и очень простой иерархией ролей, поэтому я и смог за него взяться. Iceland
Существенное «За» в том, что в итоге мы будем понимать, как все работает и сможем настроить работу системы в «горячем режиме».
Начало и продолжение: коротко
Начал я с карты. Разбил на бэк, фрон (будет небольшая видимая из интернета часть) и технические функции, о которых нужно помнить, но которые могут не иметь прямой визуализации в интерфейсе.
Продолжил визуализацией сценариев. Отдельно сделал ключевой сценарий разговора с возможным ветвлением. Я исходил из того, что интерфейс должен поддерживать сценарий беседы (коль основным делом у сотрудников будут звонки) и помогать им в работе, поэтому было важно понять из чего будет состоять разговор и к чему он может привести.
В итоге разработанная карта и сценарии выли положены в основу вайрфреймов для интерфейса сотрудника и интерфейса администратора.
Сегодня отдал на прототипирование и потом попробуем собрать и заставить это все работать.
Последние статьи
Об авторе
Дмитрий Подлужный – UX дизайнер, который ищет решения на границе пользовательских потребностей, бизнес целей и технических ограничений.
