Кредит фотографии: Ѕolo
Когда вы в последний раз использовали функцию ссылок в Microsoft Word?
Или действительно нужно больше, чем около четверти фильтров в Photoshop?
Когда мы говорим о расширении возможностей приложений, мы часто думаем о программном обеспечении Microsoft или Adobe и о статистике, согласно которой большинство пользователей используют только около 20% своих наборов функций.
Хотя многие поставщики работают гораздо лучше, чем раньше, то же самое можно сказать и о многих программных решениях.
С другой стороны, когда вы в последний раз ругались на экране, пытаясь выполнить, казалось бы, простую задачу, которая наверняка должна сработать (кто угодно форматирует списки в Word)?
Мы все использовали чрезмерно раздутые программы, накапливая множество функций, которые, как нам кажется, могут нам когда-нибудь понадобиться.
«Будь я проклят, если я не найду место, где можно использовать этот диффузный, биполярный, логический фильтр мозаики до моей смерти!» ты думаешь про себя.
Целью большинства поставщиков программного обеспечения, конечно же, является смена подразделений и создание клиентской базы. Сложно убедить потребителей покупать статистику, например, «теперь можно использовать на 50%!» в отличие от «100 новых функций».
На самом деле, трудно себе представить, что, скажем, твой папа или стоматолог из этой первой цитаты будут делать?
Итак, что это значит для мобильных и веб-разработчиков и дизайнеров?
Эти миры, по необходимости, были отстранены и освещены. Но по мере увеличения пропускной способности, снижения затрат на серверы и увеличения ожиданий пользователей у нас возникает соблазн добавлять все больше и больше в наши веб-приложения, в то же время становясь ленивее при выполнении.
Сейчас мы испытываем ту же самую «ржавчину» в нашем секторе, через которую разработчики приложений уже прошли, и вновь появляются.
Сейчас я работаю в основном с готовыми инструментами систем управления контентом с открытым исходным кодом (CMS) и инструментами управления взаимоотношениями с клиентами (CRM). Оба прославились репутацией крутых кривых обучения и ошеломляющих сложностей.
Эти системы очень хорошо вписываются в клише в нашем первом параграфе. Они пытаются быть всем для всех пользователей, что часто может привести к разочарованию или компромиссу со стороны разработчиков и конечных пользователей.
Они также представляют соблазн предоставить функции, которые никогда не запрашивались и не были необходимы. Готовые системы предлагают фантастические, экономящие время устройства для ваших проектов, но также могут отвлечь вас и ваших пользователей от того, что действительно важно.
Помните, что выключить вещи так же легко, как и включить их.
Эта статья является чем-то вроде первоначального обсуждения, посвященного установлению приоритетов лучшего удобства использования по сравнению с функциями в нашей работе, но если бы мне хотелось больше всего рассказать об одном моменте, было бы сделать наши инструменты создания (CMS, Frameworks, Languages) более удобными в использовании. и доступный.
Это становится все более актуальным в связи с недавними усилиями, побуждающими всех учиться кодировать .
Итак, почему функциональность ползучесть подавляющее удобство использования?
Разработчики — дефицитный ресурс
В мире открытого исходного кода мы часто видим проблемы и очереди ошибок в течение многих лет, при этом основные области функциональности остаются нефиксированными, поскольку разработчик ушел (физически, умственно или по времени).
В то же время мы видим огромные усилия, прилагаемые к новым функциям, дополнениям и ветвям проектов из-за разногласий или дублирования и репликации аналогичных инструментов.
Одной из областей, которой постоянно не хватает, является тщательная документация. К сожалению, это именно та область, с которой новички сталкиваются больше всего, и всегда выдвигаются как нуждающиеся участники. Но давайте посмотрим правде в глаза: написание документов никогда не будет таким очаровательным, как написание какой-то новой сексуальной функции.
Разработчики часто предпочитают большие идеи последним штрихам
В мире открытого исходного кода мы должны помнить, что большинство проектов выполняются на добровольных началах. Руководители проектов и разработчики, скорее всего, всегда будут работать над тем, что их интересует больше всего. К сожалению, небольшие итеративные улучшения юзабилити не всегда так высоки в их списке исправлений.
На самом деле, зачастую естественный менталитет разработчиков заключается в том, чтобы хотеть сделать что-то технически удивительное, и это неизменно фокусируется на структурном уровне или уровне кода — не обязательно уровне, который будет иметь смысл для большинства конечных пользователей.
Молчаливое большинство … ну .. тихо
Сообщества, которые формируются вокруг продуктов, как правило, полны воинственных меньшинств, все лоббируют их убивающую особенность, которая будет добавлена. Хотя большинство пользователей, вероятно, не заинтересованы в этой функции, мало кто будет активно протестовать против ее добавления.
Я имею в виду, что никто не хочет быть убийцей, верно?
Достаточно сказать, активно выяснять мнения молчаливого большинства и дипломатично напоминать себе, что те, кто кричит громче всех, не всегда могут быть правы (даже если вы не говорите им об этом прямо).
Так что делать?
Большинство небольших агентств по развитию цитируют свои проекты, основанные на особенностях. Действительно, у клиента часто есть контрольный список того, что он хочет от своего сайта, и цитирование следует следующим образом.
В идеальном мире мы все следовали бы принципам, ориентированным на пользователя и гибким, но часто концепция отказа от предложения фиксированной цены все еще слишком «чужая» и пугающая — как для разработчиков, так и для клиентов.
Однако, безусловно, можно разбить вашу цитату на различные наборы функций или этапов, основанных на приоритете клиента.
Затем вы можете помочь клиенту пройти через процесс принятия решения о том, какие из них следует выполнить в порядке приоритета, и постепенно познакомить их с представлением о своих клиентах как о конечном пользователе и о том, как эти функции будут (или не будут) решать их проблемы. ,
Не поддавайтесь искушению разрабатывать, кодировать или цитировать функции, которые вам нравятся. Мы все любим испытания, и очень заманчиво отвести глаза от мысли о героическом решении проблемы дизайна, которая преследует ваше творческое сообщество на протяжении десятилетий.
Еще в студенческие годы мы освещали тему, которую я всегда стремился выделить в продуктах, которые успешно с ней справляются: концепция « абстракции », или создание чего-то сложного, выглядят потрясающе простыми.
При проектировании и разработке внешних интерфейсов имейте это в виду и уберите лишнее, о котором пользователю просто не нужно знать или получать доступ для достижения успешного результата.
Печальный факт заключается в том, что люди в основном ленивы (или, возможно, обращают на себя внимание), и им на самом деле не безразличны ваши усилия по созданию какой-то фантастической серии событий. Все, что их действительно волнует, — это нажатие кнопки, благодаря которой происходит все, что они хотят (даже если они еще не знают, что это такое).
Независимо от того, насколько инновационные и изменяющие игру вещи могут быть скрыты, если слишком сложно понять, как их использовать, люди будут тяготеть в другом месте. Дорога к удивительности усеяна намного более блестящими отключениями (и все говорят о них).
Помните, что ограничения и ограничения часто могут привести к гораздо более высокому творческому результату. Это относится как к используемым вами инструментам, так и к функциям, которые вы предоставляете своим конечным пользователям.
Попытка создать удивительную, гибкую систему — тяжелая работа, которая создаст больше проблем, чем вы, возможно, пытаетесь решить в первую очередь.
Привлечь пользователей к тщательно отобранному и хорошо выполненному базовому набору функций гораздо проще, и, вероятно, вы получите больше сторонников в долгосрочной перспективе.
Безусловно, можно «продать» сокращенный набор функций — сконцентрируйтесь на времени, которое вы экономите людям, на более приятном и продуктивном опыте.
Будьте резкими и осуждающими с вашими интерфейсами, опытом и наборами функций, и всегда имейте в виду классическую поговорку: «Если сомневаетесь, оставьте это».
«Если сомневаешься, оставь это».
К сожалению, слишком легко добавлять функции в программное обеспечение. Им не требуются физические части, логистика и дорогостоящие процессы, необходимые для добавления функциональных возможностей в кирпичи-н-растворные продукты. Это не сделает коробку больше для отправки, верно?
Растущая тенденция к выпуску программного обеспечения стала еще проще. Просто добавьте это в ближайшие недели.
Вы бы заплатили за обновление, которое сократило возможности?
Это был подход, предпринятый Apple с их последними обновлениями OS X. В то время как они добавили некоторые новые функции, они также лишили своих базовых приложений всего, что считается посторонним или неиспользованным.
Можно предположить, что эти решения были основаны на статистике и исследованиях. Хотя эти решения вызвали некоторую шумную реакцию , мне хотелось бы знать, не было ли больше того, чтобы люди хотели иметь StairMaster, а не когда-либо хотели его использовать .
Я подозреваю, что в гаражах много StairMasters.
Это не все плохо. Некоторые компании в нашем секторе делают большую работу по упрощению. Dropbox — отличный пример. У них есть одна отличная идея, и они смело сопротивляются искушению добавить многоуровневую социальную интеграцию, видеочат и забавный элемент геймификации. Yay их.
Как ни странно, Стив Джобс с уважением однажды сказал им, что у них нет продукта , у них есть «особенность».
На этой неделе «особенность» Стива была оценена в 10 миллиардов долларов .
Может быть, нам нужно больше возможностей в конце концов …
- Так что ты думаешь?
- Как вы развиваете продукт, не удушая его?
- Вы бы посоветовали клиенту не добавлять функцию, даже если это будет стоить вам дохода?