Где-то год назад наша компания занималась проектированием американского рекрутингового сервиса для инвестиционной компании GapZap. Сайт должен был помочь частным дантистам и клиникам в поиске персонала на временную и постоянную работу. Ну и, соответственно, наоборот — обеспечить занятость соискателям. Конечно, одним только сайтом этого добиться сложно, поэтому заказчик запланировал целую серию маркетинговых мероприятий по выводу продукта в люди.
На штатовском рынке уже действовало несколько подобных сервисов, но все они предоставляли ограниченный набор услуг. А вот GapZap должен был предоставить мощный инструмент не просто для подбора единичных кандидатов, но помочь небольшим организациям отказаться от услуг рекрутинговых агентств. До этого я уже успел поучаствовать в нескольких проектах для американского здравоохранения. Это была серия веб-приложений для страховой компании Blue Cross Blue Shield. Так что знание предметной области присутствовало.
От нас требовалось спроектировать интерфейс системы и подготовить техническое задание на ее разработку. У заказчика уже был опыт веб-разработки, который принес ему понимание бонусов предварительного проектирования. Так что лишний доказывать необходимость нашей работы не пришлось. Начав с серии предварительных вопросов и анализа предметной области, мы получили набор предварительных документов. Ключевые персонажи и их цели, структура системы и карта сайта, описание функциональности, отдельные аспекты бизнес-логики, основные объекты (сущности) и их поля (атрибуты), платежные системы и другие сторонние сервисы. Плюс серия небольших деталей о бизнесе в целом и системе в частности. В неоформленном виде это стало основной для проектирования.
Клиент хотя и выдал предпочтения по виду нескольких функций, основную часть интерфейсных решений оставил нам на усмотрение. И тут нам снова повезло — мы слышали друг друга, зажигали глаза интересными идеями и предложениями, подхватывали и удачно продолжали основные мысли заказчика. Так, например, обычный календарь стал хорошим инструментом одновременно для планирования времени, заявок на поиск сотрудников и показа их предложений на сегодня. А информация о соискателе отображает не только общую информацию о нем и его квалификации, но также совпадения его расписания с расписанием клиники, релевантность поисковому запросу и характеристику прошлого опыта сотрудничества.
По итогу концепция системы материализовалась, а затем получился и отличный пакет ее спецификации для разработчиков. Техническое задание, схемы страниц (wireframes), сценарии взаимодействия и вспомогательные документы дали нам возможность более точно сориентировать заказчика по срокам и стоимости реализации системы. А значит позволило заказчику более вдумчиво и точно выбрать разработчика. Ну и плюс ко всему, показать систему пользователям и заинтересованным лицам еще до начала девелопмента.
По прошествии времени глядя на спроектированный интерфейс GapZap видятся несколько улучшений. Например, меню пользовательских функций стоило выделить посильнее к основному. Хотя в целом проект получился более чем интересным и многие придуманные в нем решения я использую с удовольствием и сейчас. Да и само сотрудничество было очень и очень приятным. Жаль только, что разработку сервиса клиент свернул на полдороги. Хотя в инвест-проектах такое случается регулярно.
19 comments
А в чём такие красивые wireframeы делаются?
Это все MS Visio 2003 (хотя разница между 2002 и 2007 не сильно большая). Плюс хороший набор типовых элементов (stencil). Я использую вручную доработанный набор Гарретта-Димона — http://v1.garrettdimon.com/resources/templates-stencils-for-visio-omnigraffle
ээх по линуху бы )
Я думаю, тоже найдется что-нибудь 🙂 А вы сейчас чем на Linux wireframes рисуете?
про линух это сильно! респект
Ну скажем так для себя на бумаге, а потом быстро сверстать =) Но это конечно извращение не спорю).
Ну на бумаге черновики тоже полезно делать — сложные страницы я сперва набрасываю карандашом и уже только потом отрисовываю. Некоторые все сперва на бумаге рисуют, но это, по-моему, чересчур.
Очень интересная статья. Спасибо.
Может быть мой вопрос будет не в тему, но вы случайно не учавствовали в проектах где разрабатывалось бы приложение для бронирования авиабилетов. Ищу оригинальные решения этой задачи.
Может быть кто-то из читателей расскажет про такое.
http://live.gnome.org/Dia
Впринципе если бы сделать для этого дела библиотеку элементов нормальную, то вполне можно было бы юзать.
2bUg: по-моему там достаточно элементов. Скажите каких элементов Вам не хватает?
Веб элементов. Кнопки, чекбоксы и тд.
2bUg: вы не думали, что их можно заменить квадратиками и кружочками? В чём смысл проектирования? В том, чтобы нарисовать красивый чекбокс?
можно но получится не так наглядно. Да и не красиво, всётаки элементы лучше стандартные были, и выглядели как в вебе. Но собсна на досуге может сделаю такую библиотечку, если не найду готовой.
Данила,
В компании, где я до этого работал, таких проектов было много. Я участвовал на ранней стадии создания системы для авиакомпании S7 (Сибирь). Но мой бывший коллега Максим Гулевич (http://www.ui.by/) “собаку съел” на системах бронирования, так что лучше проконсультироваться у него. Возможно, он сам читает этот материал и ответит на вопрос.
bUg,
Если Dia в принципе поддерживает шаблоны либо что-то вроде стенсилов в Visio, скорее всего что-то готовое уже есть. Поищите, мне самому интересно, есть ли какие-то средства проектирования для Линукса 🙂
Просто интересно, а за проделанную работу заказчик заплатил?
Creatorre,
Естественно, мы ведь заключали договор только на проектирование интерфейса и техническое задание — эти работы и были сданы. Это если договоренности устные — тогда возможен “проброс”. Да и то видно сразу, готов ли в принципе клиент платить или нет.