Предлагаем вашему вниманию статью из блога дизайн-студии ZURB, которая посвящена прежде всего начинающим разработчикам приложений. В свете успеха сервиса Mac App Store, таковых на Мак-платформе будет становиться только больше, поэтому очень рекомендуем к прочтению.

Есть свой резон почитать ее и нам с вами — рядовым пользователям. Хотя бы для того, чтобы лучше понимать как это все работает. В скором времени Mac App Store заполонят разнообразные приложения и не надо сразу будет бояться того, что функционал зачастую у них будет если не ограничен, то весьма узкоспециализирован. Не забывайте, что «Москва тоже не сразу строилась».

«Это миф. Не покупайтесь на него. На ранней стадии развития продукта вам не надо добавлять в него все те функции, о которых просят пользователи. Нет, ваши клиенты не всегда правы. Нет, они не всегда знают, чего хотят. И нет, они не будут обозлены, если вы не сделаете все, о чем они просят.

Представим, что ваш пользователь просит какую-то функцию и очень хорошо обосновывает свою просьбу. Что вы делаете? Вот как обычно думают в среднестатистической компании:

1. Наши пользователи должны чувствовать себя удовлетворенными.
2. Они предлагают отличное применение для этой функции.
3. А может и другим эта функция пригодится.
4. И нам надо больше функций, чтобы мы могли просить за программу больше денег.
5. Возможно есть даже больше людей, которые хотят подобную функцию.
6. Ок, давайте добавим ее и сделаем всех наших пользователей счастливыми!

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

— В конце концов все свелось к одной гениальной идее: Dropbox изначально ограничил свой функционал. Он предлагал одну папку и эта папка всегда была синхронизирована без каких-либо проблем — это была магия какая-то. Syncplicity мог синхронизировать любую папку на вашем компьютере до тех пор, пока у пользователя была свободная квота на сервере. (К сожалению, многие использовали эту функцию для синхронизации папки Windows). Наша компания предлагала слишком много функций и это сильно запутывало пользователей. Все это привело к тому, что в итоге мы все свое время тратили на разъяснения и поддержку пользователей, а на инновации и изобретения времени не было.

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

Бизнес боится отвергать запросы пользователей. Но почему? Тут мы упираемся в несколько мифов.

Для того, чтобы пользователь был счастлив, мы должны выполнить его запрос. Верите вы в это или нет, но вам не надо делать то, что просит вас пользователь, дабы сделать его счастливым. Слушайте его, слышьте его, но говорите: «Извините, я посмотрю что с этим можно сделать, а пока вот альтернативное решение». Если вы сейчас не можете дать то, что просит пользователь, предоставьте ему альтернативные решения. Вот наглядный пример. Однажды я позвонил в обувной магазин Zappos чтобы заказать туфли для моей жены. Нужного размера у них не оказалось, поэтому человек на том конце провода залез в Google, откопал обувь нужного мне размера на сайте конкурентов и дал мне их контакт. Он сделал это несмотря на то, что цена у конкурентов оказалась даже ниже, чем у них. Как вы думаете, кому я теперь звоню, когда мне нужна новая обувь?

Пользователи взбесятся, и нас ждет скандал. Множество компаний переживает, что их пользователи настолько разочаруются, что запустят против них в Твиттере какую-нибудь акцию или начнут судачить о том, какой компания предлагает плохой продукт и отвратительную поддержку. Мы все слышали страшные сказки о том, как плохой пиар губит замечательные продукты. Хотя чаще всего такого не бывает. Всего лишь короткое замечание о том, что вы в будущем примете к сведению пожелания пользователя, и вы получаете отсрочку от недовольства, которое испытывает клиент.

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

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

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