Продукт = интерфейс

Эта тема будет больше интересна программистам, но и к бизнесу она имеет непосредственное отношение, так как значительно облегчает и ускоряет его автоматизацию.

Если брать опыт в программировании, то я свои пресловутые 10,000 часов отработал еще лет 10 назад, так что советы давать имею право :)

Увлеченные программисты знают, как прикольно иногда бывает «занырнуть» в какую-нибудь мелкую задачу и сделать ее просто мега-круто. И ничего, что это займет несколько дней в ущерб срокам проекта :)

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

Тут, правда, стоит учесть один важный аспект, который должен направлять не только основной проект, но и твою «второстепенную» работу: продукт является интерфейсом. Никакой внутренний функционал ничего не стоит, если он не влияет позитивно на тот самый интерфейс. Еще хуже, когда дополнительная работа выливается в его усложнение, замедление или утяжеление.

Когда я говорю «интерфейс», я не имею в виду только конечного пользователя продукта. Разрабатывая библиотеку, в первую очередь стоит сделать ее использование максимально простым и удобным с помощью заглушек и лишь потом заниматься «внутренностями».

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

Купите себе планшет. Не электронный, а бумажный, под формат A4, пачку бумаги и механический карандаш с мягким грифелем (удобнее писать лежа, обычные ручки перестают писать в таком положении).

Возьмите себе за правило перед написанием любого мало-мальского «серьезного» кода на этом самом планшете набросать отнюдь не структуру кода, а интерфейсы. В случае с веб-мордой — пользовательские сценарии и грубый набросок внешнего вида, «поиграйтесь» с ним на бумаге. В случае с библиотекой — API и опять же «поиграйтесь» в вызовы, прорабатывая детально форматы запросов и ответов.

Вот серьезно: подобной работы там — максимум на полчаса-час, но экономит целые дни, а иногда и недели! Бумажку всегда можно просто почеркать и выкинуть, а вот в связном коде, особенно разделенном на отдельные библиотеки начинаются такие танцы с бубном…

Тут есть еще важный ньюанс: при проектировании на бумаге интерфейс менять легко, поэтому ты спокойно сможешь его перерисовывать и черкать, благо это занимает пару секунд. Если же код уже написан, тебе будет реально лениво заставить себя что-то упростить или переделать. В итоге «бумажный» интерфейс получается гораздо легче и удобнее, нежели когда ты «пляшешь» от кода.

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

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

В общем, планшет, пачка бумаги и механический карандаш — наше все :)

VN:F [1.9.20_1166]
0 голосов
8 комментариев
старее
новее большинство голосов
Межтекстовые Отзывы
Посмотреть все комментарии
CGVictor

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

Лучше (хоть сразу после) найти профессионала, который покажет хотя бы самые очевидные грабли прототипа; потому что у него-то 10к часов по этому самому взаимодействию, а у тебя по написанию кода.

Думаю, идея понятна.

CGVictor

Фишка как раз в том, что с позиции «ну я тут функционал пишу» ты никогда (say never) не сможешь оценить, насколько человеку «понятно и удобно». Они сами тебе этого не скажут в любом случае.

Да, можно смотреть на количественные метрики: «покупают значит удобно». Расскажи это пользователям SAP и 1С.

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

Специалист нужен именно затем, чтобы сэкономить тебе гуляние по граблям, по которым уже прошел легион. И не наебнуть, например, выход на рынок из-за какой-то недоработки.

++ Очень занимательно кстати в этом отношении смотрится подход RDE у Московица, применительно к программному продукту: о том, что пользователь тебе в принципе никогда не скажет, что/как он действительно хочет, и как не страдать уйней, выкатывая «нужные фичи».

burnis

в точку! лучшее всегда получалось после рисования на бумаге.

Вот только когда много повторяющихся элементов или какой-то драг-ндроп или когда некоторые элементы меняются на разных страницах рисовать крайне выбешивает быстрее уже становится такие вещи набросать хотя бы в ворде а порой и быстрее накидать в бутстрапе -)

burnis

еще довольно активно практиковал интерфейс словами.
Когда просто сидишь и долго нужно выписывать все возможное что может быть словами, потом группируешь в какие-то абастрактные блоки и постепенно получается вполне конфетка. Тогда уже и нарсиовать не проблема на планшете листочном

burnis

всегда рад )
особенно хорошо когда есть живые клиенты. Когда они все набрасывают эти самые слова, потом их группируешь в сценарии поведения или как-то еще

тогда выходит просто шикарно. Так как действительно сам многие вещи даже в голове придумать не придумаешь что они оказывается могут быть нужны и удобны -)