Connect with us

Дизайн и прототипирование

User Story: план действий для разработчика

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

Джаред Барол

Опубликовано

/

     
     

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

Процесс разработки мобильного приложения состоит из нескольких последовательных этапов. Первоначальным и в итоге во многом определяющим конечный результат является написание User Story.

Что такое User Story?

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

Три довода в пользу User Story по сравнению с спецификациями при разработке мобильного приложения:

  1. Во время создания пользовательской истории разработчики продумывают, как решать ряд задач еще до стадии начала процесс разработки. User Story отлично помогает взглянуть на всю систему целиком.
  2. Пользовательские истории являются результатом работы команды, в отличие от спецификаций. Обычно последние пишутся одним или несколькими людьми в команде. Как предмет коллективной работы, пользовательские истории помогают выявить все слабые стороны продукта и решить все проблемы в реализации идеи до разработки в формате живого общения.
  3. User Stories создаются в том числе для тестировщиков. Они содержат пользовательские сценарии, которые станут основой тестирования после сдачи проекта.

Как было сказано выше, правильно написанная пользовательская история позволяет избежать множества распространенных проблем, главная из которых — неправильное представление конечного продукта разработчиком. Ситуация, кстати, достаточно распространенная. И в интересах издателя, чтобы результат разработки мобильного приложения полностью соответствовал требованиям и ожиданиям пользователя, а значит, созданию User Story следует уделить особое внимание.

Какие требования выдвигаются к написанию пользовательских историй?

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

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

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

В качестве… (описание представителя ЦА, его роль в приложении), он получает… (действия в приложении) для… (цели его действий в приложении).

better-user-story

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

Окончательная формулировка истории должна быть лаконичной и точной. Если сформулированная заказчиком история содержит сложные расплывчатые понятия, ее следует переписать. В идеале User Story должна быть:

  1. Внутренне независимой;
  2. Структурно изменчивой;
  3. Ценностно ориентированной;
  4. Учитывающей критерии оценки каждого этапа;
  5. Оптимизированной по времени (рассчитаннной на 1 неделю);
  6. Проверяемой (легко оценимой в результате)

dilbert-userstories

Рекомендации для написания правильных пользовательских историй

  • Написание пользовательской истории – это своеобразный «мозговой штурм», который следует использовать с максимальной выгодой для продукта. Во время ее написания должны быть заданы все вопросы и получены все ответы. Менять что-то на стадии разработки и тем более после сдачи проекта крайне сложно и затратно.
  • Вместо одной большой пользовательской истории лучше написать несколько более мелких и точных. Т.е. крупные и громоздкие истории необходимо фрагментировать с учетом конкретики задач, разбивать на более детализированные и мелкие.
  • Оптимальный размер User Story (следует ли ее разбивать на под-этапы или же объединять несколько в одну) определяется просто: на разработку должно уходить от 0,5 до 4 «идеального дня». Если уходит больше четырех, то имеет смысл фрагментировать. Если меньше – надо объединять.
  • Обязательно прописывайте в истории критерии приемки, поскольку при их наличии тестировать соответствие готового продукта и истории намного легче.
  • Хотя в большинстве случаев формат пользовательской истории должен соответствовать основным требованиям, но в некоторых случаях, если, к примеру, речь идет о дизайне, можно ограничиться более свободным форматом в виде скетчей или набросков.
  • Следующий совет может кого-то и удивит, но его практическая польза подтверждалась неоднократно. В процессе работы над созданием User Story желательно использовать небольшие бумажные карточки. При командной работе этот метод просто незаменим, поскольку способствует динамике процесса. Готовую пользовательскую историю также не следует убирать с глаз долой в недра ноутбука или письменного стола. Повесьте их на стену, это будет очередной мотиватор для выполнения поставленной задачи.

Что делать не стоит?

  • Чрезмерно детализировать. Из-за слишком подробной, описанной в деталях User Story, процесс ее обсуждения командой может быть сведен к минимуму, что не всегда хорошо для поиска оптимального решения поставленной задачи. Всегда нужно оставлять место для творчества, а формальный подход с ним, как известно, несовместим.
  • При всех соблазнах сделать это пропускать обсуждение ни в коем случае не стоит. Даже если, на первый взгляд, все совершенно очевидно. Именно в процессе обсуждения можно, как говорится, расставить все точки над і.
  • Формат User Story не предполагает наличие технических задач.

Необходимо отметить, что User Story не является чем-то нерушимым и не приемлющим каких-либо изменений. В принципе, при необходимости заказчик может добавлять новые пользовательские истории, менять приоритеты и т.д. Это вполне допустимо. При этом разработчик со своей стороны обязан объяснить заказчику, чем чревато будет предложенное изменение или добавление. Живое общение на этой стадии — залог успеха в будущем. Ведь создание успешного мобильного приложения – это блестящая идея + не менее блестящее ее воплощение. А для последнего значение правильно написанной User Story вряд ли можно переоценить.

Мы посоветовались с экспертами в области мобильной разработки и выяснили, как с их точки зрения лучше работать с историей.

Анна Минникова, Гиперболоид, сертифицированный Scrum Professional, работала продакт и проджект менеджером в крупнейших геомобильных приложениях СНГ, сейчас занимается lean коучингом.

1. Как правильно написать User Story?

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

Обязательно формулируйте персоны вашего продукта до начала работы над user story. Это поможет вам лучше прочувствовать пользовательские нужды/боли/желания и лучше понять, для кого вы проектируете ваш продукт.

Ваша идеальная история должна быть написана по такому образцу:

Как, <роль пользователя>, я <что-то хочу получить>, <с такой-то целью>

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

Вот как в укороченном виде выглядела пользовательская история в одном из моих проектов:

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

Критерии приемки:

  1. Как водитель с загоревшейся лампочкой я могу просмотреть все ближайшие заправки.
  2. Как … я могу выбрать заправки подходящих мне брендов АЗС.
  3. Как … я могу видеть ближайшие заправки выбраннах брендов списком.
  4. Как … я могу видеть ближайшие заправки выбранных на карте.

Обработка ошибок:

1. При выключенной геолокации пользователя необходимо дать ему информацию о том, где ее включить.

Технические заметки:

1. Заправки в списке должны обновляться при изменении местоположения пользователя на 100 метров.

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

Вот как выглядели экраны, относящиеся к этой истории, в итоговом приложении:

2. Как объективно оценить ее полезность и востребованность?

Пользовательские истории полезны, если вы понимаете, что с написанием пользовательской истории для самого простого проекта вы ступили на тяжелый путь сомнений: «зачем мы делаем наш продукт»?, «точно ли нужна эта фича в продукте?», «да пользователей с такими потребностями днем с огнем не сыщешь», «кто будет пользоваться тем, что мы делаем?». Эти вопросы не очень приятны, но честные ответы на них помогут вам спроектировать лучший продукт.

3. Чего делать не стоит при работе с User Story?

Писать их в гордом одиночестве или поручать написать пользовательские истории, к примеру, менеджеру проекта. Если, конечно, вы не являетесь конечным core пользователем продукта, который вы разрабатываете :)

Также не очень здорово писать объемные, большие истории. Если ваша история не вмещается в стандартную итерацию вашей команды (я надеюсь, что это максимум 4 недели:), то она слишком велика и стоит задуматься, как можно ее поделить на несколько.

И самые главные грабли – писать пользовательские истории, которые пойдут в разработку, до того, как вы прошли через процесс customer development. Хорошо сделать это для общего понимания того, что пользователь, по вашему мнению, будет делать с продуктом.

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

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

  • считают ли они проблему, которую решает ваш продукт, достаточно серьезной (к примеру, все игры решают серьезную проблему – убийство времени и побег от скуки);
  • как они решают свои проблемы сейчас;
  • какие заменители или конкуренты есть у вашего продукта;
  • и еще массу важных моментов, которые стоит узнать до того, как вы написали гору кода :).

Это самый большой и объемный пункт, поэтому очень хочу порекомендовать к прочтению 2 книги:

Four Steps to the Epiphany – библия customer development, которая даст вам фундаментальное понимание об этапе создания продуктов, которые вам нужно пройти перед тем, как написать пользовательские истории.

User Stories Applied – самая лучшая и полная книга о том, как писать, оценивать, тестировать и принимать пользовательские истории.

752Евгений Плохой, CEO at CapableBits, Founder of CBLabs.mobi

Я бы сказал, что user story – это инструмент. Инструмент этот обычно используют outsourcing компании. Он позволяет начать диалог с клиентом и работать в одной карте понимания задачи. Так что чаще всего user story пишет заказчик. Сам формат user story, который выглядит так “As !WHO! I want !WHAT! so that !WHY!” предполагает, что её пишет пользователь/заказчик, который объясняет ЧТО он хочет и ЗАЧЕМ. Мы разрабатываем продукты для глобального рынка и разрабатываем продукты самостоятельно, поэтому таким инструментом, как user story мы не пользуемся. Для нас более актуальными являются сценарии использования, которые мы в том числе используем для QA продукта.

1. Как правильно написать User Story?

Хорошая User Story должна соответствовать модели INVEST.

2. Как объективно оценить ее полезность и востребованность?

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

3. Чего делать не стоит при работе с User Story?

  • Использовать историю для выполнения которой требуется более одной итерации
  • Писать громоздкие истории.
  • Использовать жаргон.
  • Сразу привязывать историю к конкретному интерфейсу.

10550845_712446808828208_1332402771215810983_nUser story от Юлии Козловой, PR & Event Manager в Touch Instinct

1. Как правильно написать User Story?

Не важно то, как она будет написана и оформлена, главное – насколько правильно и точно она описывает потребности пользователя. В Touch Instinct мы проговариваем пользовательскую историю с клиентом устно, во время переговоров. Делаем заметки. Кто пользователи, чего они хотят? Мы выясняем формализованные потребности: мгновенная покупка, удобное чтение новостей, бронирование мест, заказ билетов и т.д., из которых прорабатываем детальные требования к сценариям использования будущей программы. «Я как пользователь хочу сортировать товары по цене, чтобы выбрать лучшее из одной ценовой категории». «Я как пользователь хочу сохранять музыку в кэш, чтобы слушать без интернета». Далее на основе юз кейсов строим интерфейс, на этом этапе мы понимаем, от какого функционала стоит отказаться, например,  нужны ли комментарии к фотографиям или нет.

2. Как объективно оценить ее полезность и востребованность?

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

3. Чего делать не стоит при работе с user story?

Не стоит зацикливаться и затягивать с проработкой. Зафиксировали ключевой функционал, держите его в фокусе, перед глазами, но не воспринимайте как инструкцию. Юзер стори достаточно гибкая вещь, в которую можно вносить изменения.

natНаталия Давыдова, менеджер Heads and Hands

User Story обычно используется при гибких методологиях разработки. В нашей компании часть проектов ведется по такой методологии. Обычно мы организуем встречу с клиентом, на которой просим его описать обычным пользовательским языком пожелания к функционалу сайта или мобильного приложения. На основе этого мы составляем конечное описание работ для итерации (беклог). Правильный пользовательский сценарий, на наш взгляд, должен быть:

  • понятным для всех участников проекта (и конечного пользователя);
  • коротким, чтобы можно было оценить сроки его выполнения, но при этом с достаточно точным описанием;
  • сценарий должен совпадать по смыслу и идее с основным проектом (чтобы очередная итерация “не выпадала” из общей идеи проекта. Это как раз слабое место гибких методологий, потому что при большом количестве итераций порой забывается основная идея и смысл проекта, он обрастает дополнительным и не всегда нужным функционалом, превращаясь в громоздкого “Франкенштейна”)

Объективно можно оценить полезность в том случае, если по user story можно сформировать удобный и понятный конечному потребителю продукта интерфейс.

При написании user story нужно стараться придерживаться максимально простого описания (без ухода в технические детали), учитывать роли пользователей при работе с продуктом, стараться не увеличивать размер истории, т.к. это должно вписаться в одну итерацию, которая при гибких методологиях длится не более 2х недель.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
4 комментария

4 Comments

  1. karia

    26.11.2016 at 13:45

    Человек-гиперболоид это как???

  2. Hanukido Priori

    20.03.2017 at 14:30

    Интересно то, что найти в интернете готовые юзер-стори очень сложно. Это потому, что нет чёткого формата и у аналитика довольно развязаны руки?

You must be logged in to post a comment Login

Leave a Reply

Дизайн и прототипирование

Как создание эмодзи Apple изменило мою жизнь

Одна из создательниц оригинального набора эмодзи Apple Анджела Гузман рассказала, как эти символы изменили не только способы общения между людьми, но и её собственную жизнь, подарив ей несколько ценных уроков и близкого друга.

Анна Гуляева

Опубликовано

/

Когда дизайн приводит к дружбе, а дружба снова к дизайну — возникает магия. Это история стажерки и её ментора, создавших оригинальный набор эмодзи для Apple и вместе изменивших способ общения людей во всем мире. Этот проект навсегда сделал нас друзьями, что стало ключевым ингредиентом в успехе этих крохотных иконок.

Я была стажеркой, а Реймонд — это мой друг и ментор. За три месяца мы создали некоторые из самых используемых эмодзи: лицо со слезами от смеха, кучку какашек, красное сердце и хлопушку, а также ещё 460 менее используемых. Затем мне удалось сделать кое-что ещё в качестве сотрудницы Apple.

Это было лето 2008, и прошел только год с момента получения мной степени магистра графического дизайна в Школе дизайна Род-Айленда. Этим же летом я попала на стажировку в Apple и очень ждала знакомства с командой – той же самой, что была ответственна за iPhone, за это волшебное устройство, которое появилось годом ранее. Можете только представить, сколько бабочек было у меня в животе, когда я прилетела в Купертино и прибыла на 1 Infinite Loop. Я не знала, над каким проектом буду работать, размер команды, где я буду сидеть и смогу ли я действительно ездить на велосипеде на работу (я ужасно езжу на велосипеде).

Вскоре после прибытия и встречи с командой мне дали мой проект. Я пыталась понять полученную задачу, когда кто-то спросил, знаю ли я, что такое «эмодзи». Как и большая часть англоговорящих людей в то время, я ответила: «Нет». Но это изменилось, как только для iPhone выпустили клавиатуру с эмодзи и сделали их популярными во всем мире. Чуть позже я узнала, что значило это японское слово и что мне предстоит нарисовать сотни эмодзи. Пока я смотрела вниз и обдумывала, что это не работа с макетом или шрифтом, а просто рисование иллюстраций, мне назначили ментора.

Следующие три месяца мы с Реймондом делили офис и рисовали ряды лиц, мест, флагов, животных, блюд, одежды, символов, праздников, видов спорта, ну и вы, вероятно, знаете все остальное. Но до этого мне предстояло научиться создавать иконки в стиле Apple. Мы поделили задачи и урок скромности и мастерства начался.

Реймонд создал лицо со слезами радости и кучку какашек, а я нарисовала красное сердце и хлопушку.

Реймонд научил меня всему, что нужно было знать о дизайне иконок. Я не знала, что он, мой скромный наставник, был одним из лучших дизайнеров иконок в мире. Другими словами, я сидела рядом с одним из лучших создателей иконок, использовала его знания для обучения до тех пор, пока я не могла начать работать сама, и обменивалась с ним историями о взрослении в Южной Флориде и поездках в Pollo Tropical в поисках отличных подорожников. Урок скромности пройден.

Моим первым эмодзи стало обручальное кольцо, и я выбрала его из-за сложных текстур металла и граненого камня, которые было сложно нарисовать новичку. Металлическое кольцо заняло у меня целый день. Довольно скоро я могла бы сделать два таких кольца за день, потом три и так далее. Несмотря на то, что я могла бы быстро рисовать эмодзи, не слишком волнуясь о качестве, я постоянно следила за деталями: структурой древесины, крапинками на яблоках и баклажанах, жилками листьев на гибискусе, стежками кожи на мяче — деталей было бесконечно много. Я пыталась уловить каждый пиксель, потому что каждая деталь имела значение. За три месяца через мой экран прошли сотни эмодзи. В то же время у нас был первый обзор от Стива Джобса, который заставил нас напряженно ждать результата, но нашу работу утвердили. И если Стив сказал, что всё хорошо, я считаю, что урок в мастерстве тоже пройден.

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

Другим примером является порядок их создания. Мы оставили самые сложные напоследок, поэтому танцовщица в красном платье возникла ближе к концу моей стажировки, и её постоянно не принимали. За это можно поблагодарить её платье в рюшах и Реймонда, который создал финальный вариант. Кроме этого, изначально я нарисовала женщину в бирюзовом платье с коричневым поясом. Оно было вдохновлено цветовой палитрой и пропорциями платья, которое создала моя сестра в реальной жизни в том году.

Забавные истории, понимание того, что наши школы находились менее чем в 30 милях друг от друга, общее прошлое и дни совместной работы привели к тому, что вместе мы постоянно смеялись до слез. Через десять лет после моей стажировки мы с Реймондом постоянно смеемся и он дает мне самые честные отзывы, и наоборот. Я верю, что эмодзи стали успешными благодаря нашей дружбе через дизайн.

Когда я заметила постоянно меняющийся камень в парке Бернал-Хайтс в Сан-Франциско, мы с Реймондом решили, что должны отдать дань волшебной кучке какашек. Фото 2016 года.

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

Стоит заметить, что хотя Реймонд и я, Анджела Гузман, являемся оригинальными создателями эмодзи, ответственными за 500 символов (на которые получили патент), конечно, в Apple есть и другие дизайнеры. Олли Вагнер создал около десятка эмодзи для оригинального набора после завершения моей стажировки и ещё больше — в следующем году. Сейчас количество эмодзи составляет примерно около 1000, и некоторые из них ещё и анимированы.

Десять лет назад мы с Реймондом работали над одним из моих самых любимых проектов, который привел меня к чувству своего икигай. Этот японский термин означает место, в котором страсть, миссия, призвание и профессия человека пересекаются; то, что можно назвать причиной просыпаться по утрам — это точно я в 2008. Я с радостью просыпалась, и если мне нужно было ехать на велосипеде, я несла его на три пролета вниз и ехала на работу с улыбкой на лице. Это магия!

Подарок от Реймонда на окончание моей стажировки — его реальная версия эмодзи. Апельсин, яблоко и баклажан были созданы мной.

Я хочу предложить любому дизайнеру, ищущему причину просыпаться по утрам, найти своего скромного ментора или стать ментором и отправиться по пути дружбы. Магия происходит, когда дизайн приводит вас к дружбе, а дружба — обратно к дизайну. С каждым эмодзи я узнавала что-то новое. С каждым эмодзи мы с Реймондом еще больше становились друзьями. Чем более близкими друзьями мы становились, тем лучше становилась я как дизайнер. В этом случае дружба и дизайн развивались с каждым созданным эмодзи. И этой историей стоит поделиться.

 

Комментарии
Продолжить чтение

Дизайн и прототипирование

Podlodka #42: Дизайн-системы

В последнее время в сообществе разработчиков все чаще упоминаются некие “дизайн-системы”.

Леонид Боголюбов

Опубликовано

/

Podlodka

С тем, что это такое и как это применимо к мобильному миру, нам помог разобраться Александр Зимин – iOS-разработчик из Badoo!

 

Комментарии
Продолжить чтение

Дизайн и прототипирование

11 советов от мастеров мобильного UX

Компания Monsoonfish поговорила с опытными UX-дизайнерами и попросила их поделиться одним советом, который они считают основным при создании хороших приложений.

Анна Гуляева

Опубликовано

/

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

Мы связались с экспертами UX, чтобы задать им этот вопрос: что вы считаете главным в создании отличного мобильного приложения?

Билл Уилсон, основатель MindSea

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

Рой Вергара, главный UX-дизайнер в Zappos

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

Уэс Лебсек, продуктовый дизайнер в Facebook

Не ожидайте, что другие члены вашей команды будут экспертами в UX, займите эту роль сами. Чтобы создать опыт, который действительно будет резонировать с вашей аудиторией, вам нужно погрузиться в изучение продукта и людей, для которых вы будете его создавать. Проживая этот опыт, вы сможете почувствовать проблемы пользователей, которые будет нельзя выразить сухими данными. Некоторые вещи становятся только лучше с настоящим опытом.

Джошуа Молдин

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

Йони де Бель, руководитель отдела дизайна в Yelp

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

Эдди Контенто, вице-президент UX в ChopDawg

Живите по принципу «Меньше — лучше». Выстраивайте UX вокруг ваших основных целей. Не перестарайтесь, ваши пользователи не хотят думать.

Гленн Хичкок, ведущий продуктовый дизайнер в Fueled

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

Френк Рауш, UX-типограф в Raureif

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

Дженнифер Уэкслер, фриланс UX-дизайнер

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

Пользователи вносят ценный вклад не только в UX, но и в сам дизайн. Зачастую я исправляла дизайн на основе того, что 3 из 5 пользователей заметили дизайнерскую ошибку, которую я не увидела. Даже лучшие дизайнеры могут упустить ошибку в интерфейсе, если работают над одним и тем же дизайном день за днем.

Пол Хершли, главный UX-дизайнер в Electronic Arts

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

Тиентам Бах, iOS-дизайнер в Surenix

Сосредоточьтесь на своих пользователях, точнее, на ваших основных пользователях. Я имею в виду, что не стоит добавлять сложных функций, которые можно активировать при помощи скрытых жестов (хотя это может быть круто), потому что мой опыт показал, что пользователи будут чувствовать себя потерянными или сердитыми.

 

Комментарии
Продолжить чтение

Дизайн и прототипирование

Роман Чуркин (Redmadrobot): говорить с разработчиком на одном языке

С 12 января по 4 февраля Британская Высшая Школа Дизайна проводит зимние интенсивы для творческих людей. Один из них – это четырехдневный курс программирование для дизайнеров под руководством Романа Чуркина, Lead iOS инженера из Redmadrobot. Мы поговорили с ним о курсе, в котором вы можете выиграть бесплатное участие, создав дизайн приложения для роботов!

Леонид Боголюбов

Опубликовано

/

Зачем дизайнерам код?

На этом интенсиве мы будем говорить не столько про код, сколько про умение пользоваться теми же инструментами в целом, что используют разработчики. И в понятие инструмент я, конечно, вкладываю не только Xcode (приложение, в котором разработчик набирает исполняемый код), но и набор компонентов для разработки пользовательского интерфейса, передачу материалов в разработку, вёрстку, платформу iOS в общем и её отличия от Android.

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

Думаю, каждый дизайнер сталкивался с моментом, когда классная идея разбивается о разработку на этапе согласования, потому что “не успеем” или “нереализуемо на iOS/Android”. Думаю, наш интенсив позволит дизайнеру выработать внутреннее понимание таких кейсов и позволит их избегать.

Какие навыки должны быть у тех, кто пойдет на курс?

Это должны быть ребята с опытом, которые хотят расширить свои знания и зону ответственности. Если вы заряжены на мобильные платформы и у вас горят глаза – вы нам подходите. А наша задача – помочь вам прокачать новые навыки.

Что смогут делать студенты после окончания курса?

Результатом работы на интенсиве станет рабочий прототип приложения. Это будет нативный прототип, который можно запустить прямо на вашем iPhone.

За четыре дня мы разберем все необходимые инструменты и этапы создания такого прототипа.

Помимо практического умения собирать прототип, это позволит дизайнеру взаимодействовать с разработчиками более плотно, вступать с ними диалог на равных и иногда поспорить :).

Можно ли за 4 дня научиться разрабатывать приложения?

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

Цели интенсива более практичные и позволят наработать практику и увидеть векторы возможного развития.

Учат ли в Redmadrobot дизайнеров кодить и программистов рисовать?

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

Есть ли живые примеры как дизайнеры делают приложения?

Пожалуй, самый крутой пример – это ребята из Airbnb. В какой-то момент им стало недостаточно Framer и Flinto. Тогда они прошли похожий курс.

Зимние интенсивы БВШД

Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X

Спасибо!

Теперь редакторы в курсе.