Эта тема будет больше интересна программистам, но и к бизнесу она имеет непосредственное отношение, так как значительно облегчает и ускоряет его автоматизацию.
Если брать опыт в программировании, то я свои пресловутые 10,000 часов отработал еще лет 10 назад, так что советы давать имею право :)
Увлеченные программисты знают, как прикольно иногда бывает «занырнуть» в какую-нибудь мелкую задачу и сделать ее просто мега-круто. И ничего, что это займет несколько дней в ущерб срокам проекта :)
В принципе, я вообще-то не противник такого подхода: если что-то действительно хочется сделать, если ты действительно увлечен своей работой — да пожалуйста! Понятно, что при этом сроки проекта сильно увеличивать не стоит, но любой новый код или изучение чужого фреймворка в итоге где-то да пригождаются.
Тут, правда, стоит учесть один важный аспект, который должен направлять не только основной проект, но и твою «второстепенную» работу: продукт является интерфейсом. Никакой внутренний функционал ничего не стоит, если он не влияет позитивно на тот самый интерфейс. Еще хуже, когда дополнительная работа выливается в его усложнение, замедление или утяжеление.
Когда я говорю «интерфейс», я не имею в виду только конечного пользователя продукта. Разрабатывая библиотеку, в первую очередь стоит сделать ее использование максимально простым и удобным с помощью заглушек и лишь потом заниматься «внутренностями».
Тут, кстати, многих программистов догоняет лень: проектировать не интересно, гораздо прикольнее писать код тоннами. В итоге код пишется, переписывается, еще раз переписывается, потом вообще выкидывается просто потому, что красота кода ну никак не кореллирует с удобством интерфейса.
Купите себе планшет. Не электронный, а бумажный, под формат A4, пачку бумаги и механический карандаш с мягким грифелем (удобнее писать лежа, обычные ручки перестают писать в таком положении).
Возьмите себе за правило перед написанием любого мало-мальского «серьезного» кода на этом самом планшете набросать отнюдь не структуру кода, а интерфейсы. В случае с веб-мордой — пользовательские сценарии и грубый набросок внешнего вида, «поиграйтесь» с ним на бумаге. В случае с библиотекой — API и опять же «поиграйтесь» в вызовы, прорабатывая детально форматы запросов и ответов.
Вот серьезно: подобной работы там — максимум на полчаса-час, но экономит целые дни, а иногда и недели! Бумажку всегда можно просто почеркать и выкинуть, а вот в связном коде, особенно разделенном на отдельные библиотеки начинаются такие танцы с бубном…
Тут есть еще важный ньюанс: при проектировании на бумаге интерфейс менять легко, поэтому ты спокойно сможешь его перерисовывать и черкать, благо это занимает пару секунд. Если же код уже написан, тебе будет реально лениво заставить себя что-то упростить или переделать. В итоге «бумажный» интерфейс получается гораздо легче и удобнее, нежели когда ты «пляшешь» от кода.
Да и кода получается ощутимо меньше, кстати. Ты уже не работаешь с абстракцией под названием «библиотека» или «продукт», а видишь конкретную его реализацию. Соответственно, нет соблазна запихнуть туда функционал вне рамок спроектированного интерфейса. Иначе придется снова переписывать интерфейс, а это — лениво :)
При проектировании интерфейса не стоит использовать ничего, кроме бумаги. Тут ведь цель — не «сделать красиво», а просто дать себе возможность поиграться с продуктом до его реализации. Увлекшись каким-нибудь супер-модным редактором интерфейсов, тебе будет реально лениво переделывать или даже выкидывать свою работу. В итоге интерфейс получится тяжелее и неудобнее «бумажного», а лишнего кода будет написано больше — проверено.
В общем, планшет, пачка бумаги и механический карандаш — наше все :)
В целом ты пишешь верно, но применительно к интерфейсам изложенное — только первый шаг. Взять бумагу и слепить первый прототип, проверив его на себе, любимом — это сильно лучше чем ничего, я согласен, и неплохо для старта, но не самый лучший ход для действительно хорошего продукта для конечного рынка и тем более массмаркета, если вдруг.
Лучше (хоть сразу после) найти профессионала, который покажет хотя бы самые очевидные грабли прототипа; потому что у него-то 10к часов по этому самому взаимодействию, а у тебя по написанию кода.
Думаю, идея понятна.
Витя, я бы все-таки больше доверял конечному пользователю, нежели абстрактному профессионалу по интерфейсам. Если человеку понятно и удобно — значит, интерфейс хороший.
То, что я описываю — всего лишь первый шаг перед реальным использованием, вся обкатка интерфейса будет уже там идти. Если же со старта идти к профессионалам, то ты, конечно, получишь отличные «сферические интерфейсы в вакууме», но в итоге большая часть из них будет либо переделана под пожелания клиентов, либо вообще выкинута нахрен за ненадобностью.
Специалист нужен, но, мне кажется, уже тогда, когда мы убедились, что весь функционал востребован пользователями и добавили недостающий, тогда можно вызывать подобного человека чтобы просто сделать продукт удобнее. А обращаться к нему сразу — стрелять из пушки по воробьям. R&D — в первую очередь все-таки Research.
Фишка как раз в том, что с позиции «ну я тут функционал пишу» ты никогда (say never) не сможешь оценить, насколько человеку «понятно и удобно». Они сами тебе этого не скажут в любом случае.
Да, можно смотреть на количественные метрики: «покупают значит удобно». Расскажи это пользователям SAP и 1С.
Профессионал в UX тем и профессионал, что знает насколько любая модель взаимодействия подвержена изменениям. Товарищей с «сферическими» просто шлёшь нахуй и забываешь.
Специалист нужен именно затем, чтобы сэкономить тебе гуляние по граблям, по которым уже прошел легион. И не наебнуть, например, выход на рынок из-за какой-то недоработки.
++ Очень занимательно кстати в этом отношении смотрится подход RDE у Московица, применительно к программному продукту: о том, что пользователь тебе в принципе никогда не скажет, что/как он действительно хочет, и как не страдать уйней, выкатывая «нужные фичи».
в точку! лучшее всегда получалось после рисования на бумаге.
Вот только когда много повторяющихся элементов или какой-то драг-ндроп или когда некоторые элементы меняются на разных страницах рисовать крайне выбешивает быстрее уже становится такие вещи набросать хотя бы в ворде а порой и быстрее накидать в бутстрапе -)
А я специально небрежно рисую, контролы размером с четверть-листа А4. Только суть, без нутрей практически. Обвожу в рамочку, присваиваю номер.
Потом — отдельно так же прорисовываю небрежно детали, нумерую и вписываю номера в первый общий набросок. При таком подходе копипастить нужно гораздо меньше, плюс ты можешь при дизайне контрола проходить сверху вниз, а не лепить подряд все детали.
еще довольно активно практиковал интерфейс словами.
Когда просто сидишь и долго нужно выписывать все возможное что может быть словами, потом группируешь в какие-то абастрактные блоки и постепенно получается вполне конфетка. Тогда уже и нарсиовать не проблема на планшете листочном
Да, кстати, про слова — это в точку! Мысль, достойная отдельного поста на блоге, спасибо :)
Я вот тоже часто начинаю проектирование интерфейсов даже не с рисования, а с выписывания пунктов того, что там должно быть. Или даже просто с записей «мыслей на тему», можно даже сильно издалека :)
всегда рад )
особенно хорошо когда есть живые клиенты. Когда они все набрасывают эти самые слова, потом их группируешь в сценарии поведения или как-то еще
тогда выходит просто шикарно. Так как действительно сам многие вещи даже в голове придумать не придумаешь что они оказывается могут быть нужны и удобны -)