30 августа 2012 года мы запустили наш сервис, и он вызвал достаточно бурное обсуждение и интерес со стороны Интернет-сообщества и СМИ. Многим запомнилась наша временная заглушка, об истории создания которой и об изображенной на ней девушке Лене мы как-нибудь расскажем отдельно:
В этот раз мы решили поделиться опытом работы с отдельной компанией, которой мы доверили вопросы дизайна и юзабилити, а также рассказать, как мы создавали данный продукт в течение целого года совместно со студией дизайна и веб-разработки Malgini (ООО «Техинформ») и что из этого в конечном итоге получилось.
По результатам попробуем ответить на вопрос: можно ли дизайн системы отдавать сторонней компании, не является ли он слишком важным для того, чтобы доверять его внешней команде?
Требования к интерфейсу
Пользовательский интерфейс — это то, что увидит каждый, кто попробует поработать в конечном продукте. Это именно та «одежка», по которой встречают. И если самое первое впечатление человек может сделать просто по внешнему виду и качеству графики, то уже через несколько минут работы фокус его внимания сместится на удобство и простоту интерфейса. Избалованные Apple и другими компаниями пользователи сегодня уже не хотят учиться, читать инструкции; они хотят, чтобы все просто работало и было удобным.
В этой связи можно выделить как минимум следующие требования к современному интерфейсу. Он должен:
1. вызывать позитивные эмоции;
2. быть удобным для работы;
3. не требовать (насколько это возможно) обучения;
4. выделять систему на фоне остальных;
5. адаптироваться под различные устройства, с которых пользователь работает — от ноутбука до смартфона.
Получается, что понятие хорошего интерфейса одновременно затрагивает внешний вид (дизайн — иллюстрации, оформление) и логику работы пользователя в системе (функциональные возможности и юзабилити).
Если бы мы рисовали буклет, то вопрос «можно ли доверить его внешней студии дизайна» имел бы простой ответ: конечно. В этом случае надо только сформулировать мысли, которые мы хотим донести до читателя буклета, и хороший дизайнер-иллюстратор сделает отлично оформленный макет с первой или со второй попытки.
А как обстоят дела с дизайном интерфейса? Как рождается та магия, которую пользователь считает «простотой и удобством»?
Методы совместной работы
Построить процесс работы с подрядчиком-дизайнером можно как минимум следующими способами:
1. Дизайнеры участвуют во всех обсуждениях новых возможностей системы, предлагают свои решения и, фактически, влияют на функционал системы самым непосредственным образом, почти сливаясь с командой. При этом они должны обладать пониманием цели создания системы, конкретных задач, их значимости и т.п. Это ведет к тому, что они тратят множество времени, мы начинаем зависеть от них (от своих подрядчиков!) и не должны принимать решения, не согласовав с ними.
2. Команда проекта придумывает новые функции и определяет ответы на вопросы «какие сценарии использовании функций пользователями», «как сделать функции простыми и понятными пользователю», «как каждая функция взаимоувязана с другими», то есть алгоритмы работы пользователей, потребности и т.п. Затем эти требования отправляются дизайнерам, которые находят решения с точки зрения юзабилити и вносят в макет системы изменения, добавляя нужные функции.
3. Команда проекта придумывает все целиком, думая и за дизайнеров, и поручает последним только вопрос оформления внешнего вида.
Каждый из этих способов может подходить для разных случаев, степени вовлеченности внешней компании, стоимости ее услуг и др. Для определения лучшего варианта мы попробовали все три варианта работы, и в нашем случае результаты получились следующие.
Как мы пробовали разные методы работы
Когда мы пытались привлечь дизайнеров, работающих во внешней компании, ко всем обсуждениям и переговорам, дизайнеры стали сдерживающим фактором развития проекта, поскольку совещания часто проводились незапланированно при выявлении проблемы, а у дизайнеров кроме нас были другие проекты и заказчики, и они не могли по первому требованию, бросив все дела, начать обсуждать с нами систему. Совещания начали откладываться, мы все — нервничать, и в итоге осадок оставался как у нас, так и у дизайн-студии. Это также вело к увеличению сроков работ.
Затем мы попробовали пойти по третьему варианту, как наиболее быстрому и эффективному с нашей точки зрения, и столкнулись с проблемой, что вместо простого и легкого интерфейса начал получаться большой неповоротливый монстр, как будто создавала его большая корпорация в 90-е годы. Да, все иконки «хотелось лизнуть», но общее впечатление от системы становилось все более и более удручающим. Более того, сами дизайнеры стали намекать на то, что использовать такую систему в своей работе они бы не хотели и, как следствие, упоминание их в числе разработчиков интерфейса — не самая лучшая идея. Как известно, у успеха много родителей, неудача — всегда сирота. Произошло это отчасти из-за того, что когда программисты создают любую систему, получается система для программистов — сложная, мощная, но непонятная обычному пользователю. Причины этого подробно разбираются в книге «Психбольница в руках пациента» авторства Алана Купера.
Тогда мы, наконец, нашли золотую середину, и построили процесс совместной работы так.
Все ключевые члены команды, которые участвовали в формировании требований и стратегии развития продукта, ознакомились с литературой, статьями и сайтами по юзабилити и дизайну, чтобы получить общее представление о принципах работы удобных систем. Особо отметим книгу Джефа Раскина «Интерфейсы: новые направления в проектировании компьютерных систем». Такая подготовка сделала процесс общения с внешней студией дизайна значительно более быстрой, мы стали разговаривать практически на одном языке.
Наша команда выписывала список тех функций, которые считала совершенно необходимыми, описывала их так детально, насколько считала нужным, и передавали описание дизайнерам. Ребята из Malgini смотрели, обсуждали внутри себя, спрашивали коллег, показывали своим соседям и друзьям — и писали список из 10-20 замечаний и предложений, что им нравится, а что, по их мнению, требует серьезной доработки. Уже после этого мы проводили запланированную встречу по Skype и, проходясь по готовому с обеих сторон списку разногласий и вопросов, быстро находили все ответы, которые удовлетворяли обе стороны. Расходились довольные, дизайнеры оформляли результат, программисты его реализовывали — и получалась новая версия интерфейса.
Для нас такой подход стал самым эффективным.
Во-первых, оказалось, что скорость мысли и глубина абстрактного мышления аналитиков принципиально отличается от таковых у дизайнеров. Если «мучить» дизайнера и вытрясать из него «на ходу» идеи, ничего хорошо, как и всегда с творчеством, не получается. А вот если четко понять конечную цель, затем дать свободу это критиковать и видоизменять — то включается творческий талант дизайнеров, и они с удвоенной силой берутся за обсуждение и доработку, предлагая подчас настолько классные идеи, что без такой «творческой паузы» мы сами бы никогда до этого не додумались.
Во-вторых, дизайнеры выступили в роли первых пользователей, которые проверяли наши идеи «на вшивость». Они помогали пропустить несколько итераций и сразу делать функции достаточно хорошо.
В-третьих, дизайнеры получили право отстаивания своих идей, и это очень сильно повлияло на конечный продукт: имея отличное понимание юзабилити и чувство вкуса, они тратили время на переубеждение (а не принимали наши требования за чистую монету), за что мы очень им благодарны.
Что еще нам удалось узнать?
1. Мы выяснили, что для создания удобного и красивого интерфейса дизайнеры должны «болеть» за проект не меньше, чем члены команды. То есть, если просто отдать дизайн на аутсорсинг, расписав требования в красивом брендбуке (что в принципе нереально для стартапа, создающего и пересоздающего свой продукт по несколько раз в году), получится «мертвый дизайн», без души. Вы сильно ограничиваете дизайнерам полет их фантазии и снижаете степень их влияния на результат — а с творческими людьми так нельзя. Результат получается печальным.
2. Работа с внешней компанией, занимающейся дизайном, оказалась очень эффективной, в том числе потому, что дизайнеры продолжали работать над проектами других заказчиков, и у них не замыливался глаз, а также потому, что они смогли выступить в роли «отбивающих» наши идеи. Если же идея рождается «за одним столом», люди психологически склонны соглашаться с общим мнением, и настолько хорошей и искренней проверки идей не происходит.
3. Попытка платить «за каждую единицу работы» вредила проекту. Оплата по часам очень напрягала нас и расслабляла дизайнеров, а оплата за каждый модуль приводила к усложнению запросов доработки уже созданного ранее. Например, за год мы раз пять перерисовали иконки внутри системы — и если бы каждый раз платили за это деньги, сейчас все выглядело бы значительно хуже. В итоге было принято решение перейти на модель оплаты «по техническому заданию на период времени», где за весь период (две недели) была фиксированная цена. Это вариант оказался для нас самым правильным и позволил создать доверительные отношения между командами.
В результате, мы все остались очень довольны полученными результатами, и при запуске системы все вместе «болели» за нее, не спав ночь. Нам не пришлось просить этого — ребята из Malgini чувствовали ответственность и причастность, и действовали как члены команды.
Так можно ли доверять дизайн внешней компании?
В завершение, давайте попробуем ответить на вопрос «можно ли дизайн системы отдавать сторонней компании, не является ли он слишком важным для того, чтобы доверять его внешней команде»?
Наш опыт показал, что такая модель работы может быть очень эффективной и приятной, если правильно построить процесс работы между компаниями, и частично вовлечь внешнюю компанию в процесс проектирования самой системы, а не только интерфейс.
Факт того, что дизайн был отдан внешней компании, имел свои неоспоримые плюсы — проверка наших гипотез, привлечение чужого опыта из других проектов, снижение издержек.
Благодаря именно такой схеме работы удалось создать принципиально новый, простой и удобный интерфейс — с использованием слоев вместо окон, единый для десктопов и планшетов, легкий и приятный. Malgini убедили нас убрать некоторые функции из системы, некоторые — наоборот, добавить, за что мы им, безусловно, очень благодарны.
Для нас осталась только одна загадка: каким образом некоторые другие компании-разработчики отдают на аутсорсинг разработку дизайна интерфейсов внешним компаниям без такого тесного взаимодействия?
Будем рады ответить на Ваши вопросы, чтобы более детально осветить наши принципы работы.
P.S. Детальное представление уникальных элементов интерфейса, которые мы нашли в ходе разработки, можно посмотреть на полуторачасовом видео презентации в РИА Новости здесь, а сама система Unicloud Business 365 доступна тут.
ссылка на оригинал статьи http://habrahabr.ru/company/unicloud/blog/157825/
Добавить комментарий