Rose debug info
---------------

Subscribe to this blog


telegram

RSS

json

ivan's blog

about ivan · all notes

Later Ctrl + ↑

11 star experience by airbnb

Сооснователь Airbnb Brian Chesky в каком-то интервью поделился очень интересным приёмом, который помогает делать виральные продукты. Суть в том, что обычный интерфейс, сервис, продукт — это как отель 5 звёзд. А далее мы начинаем мечтать, а какой был бы сервис на 6 звёзд? 7, 8, 9, 10, 11 звёзд?

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

Главный вопрос

Начать нужно с вопроса, и обычно он звучит так «Что можно улучшить в продукте?». Такие вопросы не работают, работают такие «Что бы мне потребовалось, чтобы создать что-то, о чем ты бы буквально рассказывал каждому человеку, с которым когда-либо сталкивался?»

Пример

Как пример сооснователь взял часть сервиса продукта Airbnb — аренда квартиры. Каким будет 5-звездочный опыт? Вы стучите в дверь, хозяева открывают дверь и впускают вас. Здорово. В этом нет ничего особенного. Такой опыт не хочется рассказывать всем друзьям. Вы можете сказать: «Я воспользовался Airbnb — это сработало».

Каким мог бы быть 6-звездочный опыт? Вы стучите в дверь, хозяин открывает и показывает вам квартиру. На столе был бы желанный подарок. Это была бы бутылка вина, может быть, немного конфет. Ты бы открыл холодильник, там есть вода. Ты идешь в ванную, там есть туалетные принадлежности. Все это великолепно. Вы бы сказали: “Вау, я люблю это больше, чем отель. Я определенно собираюсь снова воспользоваться Airbnb. Это сработало, лучше, чем я ожидал».

Что такое 7-звездочный опыт? Ты стучишь в дверь. Хозяин открывает дверь. Ты входишь. Хозяин говорит «Добро пожаловать. Вот моя полностью оборудованная кухня. Я знаю, ты любишь серфинг. Там тебя ждет доска для серфинга. Кстати, вот моя машина, ты можешь воспользоваться ею. И я тоже хочу тебя удивить. Есть один лучший ресторан в городе Сан-Франциско. Я заказал тебе там столик». А ты такой: «Ого, это уже далеко за гранью».

Итак, какой будет 10-звездочная регистрация заезда? 10-звездочная регистрация была бы регистрацией The Beatles. В 1964 году. Я бы сошел с самолета, и там было бы 5000 старшеклассников, приветствующих меня. Я бы добрался до гостевого двора дома, и там была бы пресс-конференция для меня, и это был бы просто шикарный опыт.

Итак, каким будет 11-звездочный отель? Я появлялся в аэропорту, а там был бы Илон Маск. И он говорит: «Ты отправляешься в космос вместе со мной...»

– Так, стоп!

Смысл процесса в том, что, возможно, 9, 10, 11 неосуществимы (мягко говоря). Но если вы проделаете это сумасшедшее упражнение, то обнаружите некую приятную разницу между «Он появился и открыл дверь» и «Я полетел в космос». Это именно то, что нам нужно.

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

 2633   2022   дизайн-фреймворки
Spotify MVP
Начну-ка я публиковать всякие дизайн-фреймворки, чтобы самому разобраться какие бывают, как их применять и зачем они нужны
 946   2020
Design Sprint
 623   2020

Design process

на русском · in english

If you need such a poster in good quality, write to me at ivanzviahin@gmail.com

Globally, each and every designer faces three types of tasks in their daily life. The first type is just about fixing something. The second group are likely to resolve some small problem. And lastly, they happen to do a big project. Depending on the type of task, there may come a different approach.

  1. “Fix something” is by far the simplest one. There is no rocket science in here. What we do is go handle it. It might be difficult from the point of view of the process to do something wrong here.
  1. “Solve a small problem” in a large project. For instance, we may desire to add up the ability to like publications in the news feed or attach the ability to build on QR codes to your profile. To read process for a small task go straight to point five.
  1. “Do a large project”. This is something way bigger, which consists of dozens, hundreds, thousands of tasks from the second point. And  most importantly, in this approach we are to break a large project into smaller tasks. So, when it comes to the third type, then first you need to ↓

1. Understanding goals

As a rule, this is a meeting with all stakeholders. Together we describe goal and mission and  define the audience for which we the product will be made. We write out the main hypotheses that have a direct connection with the goal and mission. For each hypothesis, the success criteria are described and outlined — a set of high-level metrics and indicators.

2. Taking a birdview of product

In here we have to understand the scope of the product and what other systems the product can potentially hook. There are a few simple ways that I tap into to sort it out. It must be noted that most often is it better to make use of everything to broaden your horizons.

  1. System diagrams. The temptation for many designers is to go straight to interface development. Yet designing interactions at such an early stage can interfere with the development of the basics of your product. As part of a workshop with all stakeholders, you need to describe the project through system diagrams.
  1. User journey map. It helps tremendously to look at the product from another perspective. We go beyond the edges of the product and try to understand how the user will find the product, how he will understand the specifics of the work, etc. What are the roles, what are the stages, what are the goals and actions at these stages. As part of a workshop with all stakeholders, you need to describe the product through a user journey map. It is important to note that this is just our representation and the representation of stakeholders. In reality, everything may be different and you need to verify this card with potential users at the discovery stage.

It is a good practice at this meeting to outline a potential discovery plan.

3. Make sure we are on the right track

It is time to validate the concept and search for growth points. I have a few simple ways to accomplish this.

  1. In-depth interviews. A great way to find new insights, point-by-point. However, you should not immediately take them to work, it is best to validate them with points 2 and 3.
  2. Surveys. A quantitative study that can confirm the insights from point 1 and give reasons for reflection in isolation from qualitative research.
  3. Data analysis. A quantitative study that can confirm the insights from point 1 and give reasons for reflection in isolation from qualitative research.
  4. Competitor analysis. Top-level view of the set of functions of your direct and indirect competitors. This will help find something new and check out what you already have.
  5. Analysis of the metrics used. Desk research. As a rule, we are not the first in the world to do this, and quite a lot of articles with research and best solutions have already been written about many practices. We cannot say that they will suit us, but they are worth studying.
  6. Analysis of user feedback. Work with reviews in stores and with what arrives at the support service. There are often diamonds there that can confirm your idea or hypothesis.

All these ways can change your model from point two.

4. Prioritizing it and splitting into versions

Next, we need to divide our entire concept into small user stories, prioritize them and divide them into versions.

So, a map of user stories. This is such a visualization of the solution scope, which helps us determine the minimum valuable product and its evolution. Below is a good video that explains how it works in three minutes.

To prioritize stories by importance, you can use moscow framework, and t-shirt size framework for technical complexity.

As a result, we have dozens, hundreds, thousands of user stories that are prioritized and divided into versions.

5. Approaching each story individually

In a while, we work with each story (a small task) by a similar process, but still a little different.

  1. Understanding the task
  2. Discovery
  3. Formulation of hypotheses and low-fi prototypes
  4. Scouping and high-fi prototypes
  5. Review the result and launch!
  6. Result analysis and new iterations

Learn more about the design process of a small task →

 5211   2022   about   casestudy   process
Toll service on the form · av.by
How we added a paid service on the ad submission form and increased the conversion to purchase this service by 48 %.
 878   2021
Design process · task
 991   2021

Дизайн-процесс

на русском · in english

Если вам нужен такой плакат в хорошем качестве, напишите мне на ivanzviahin@gmail.com

Глобально дизайнер сталкивается с тремя типами задач в своей повседневной жизни. Первый тип — просто что-то поправить. Второй решить какую-то маленькую задачу. Третий — сделать большой проект. В зависимости от типа задачи зависит и подход к ней.

  1. «Что-то поправить» — самый простой. Тут не нужно что-то выдумывать, нужно пойти и поправить. Будет сложно с точки зрения процесса что-то тут сделать не так.
  1. «Решить маленькую задачу» в рамках большого проекта. Например, мы хотим добавить возможность лайкать публикации в ленте новостей или добавить возможность добавлять QR-коды в свой профиль. Чтобы почитать процесс для маленькой задачи переходи сразу в пункт номер пять.
  1. «Сделать большой проект». Это что-то более крупное, что состоит из десятка, сотен, тысяч задач второго типа. И самое главное в этом подходе разбить большой проект на более мелкие задачи. Итак, если речь идет о третьем типе, то сначала нужно ↓

1. Понять цели

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

2. Посмотреть на продукт с высоты

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

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

Хорошая практика прямо на этой встрече, в виде воркшопа, набросать потенциальный план исследования.

3. Убедиться, что мы на правильном пути

Настало время валидации концепции и поиска точек роста. На это у меня есть несколько простых способов.

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

Все эти способы могут изменить вашу модель из пункта номер два.

4. Приоритезировать и разбить на версии

Далее нам нужно всю нашу концепцию разделить на маленькие пользовательские истории, приоритизировать их и разделить на версии.

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

Для приоритезации историй по важности можно использовать фреймворк moscow, а для технической сложности фреймворк t-shirt size.

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

5. Индивидуально подойти к каждой истории

Далее работаем с каждой историей (маленькой задачей) по похожему процессу, но всё же, немного другому.

  1. Понимание задачи
  2. Дискавери
  3. Формулирование гипотез и низкоуровневые прототипы
  4. Скоупинг и высокоуровневые макеты
  5. Ревью результата и запуск!
  6. Анализ результата и новые итерации

Подробнее про дизайн-процесс маленькой задачи →

 3999   2022   процесс   я
Самостоятельная проверка интерфейса
Перед каждым экраном интерфейса я задаю себе вопросы: – А есть ли в этом случае у человека какая-то привычка? Есть ли в мире какие-то привычные паттерны такого интерфейса? – Не заставляю ли я делать что-то пользователя, что может сделать компьютер? Не потерял ли я данные, которые дал мне пользователь? – Убрал ли я все лишнее с этого экрана? Есть ли возможность соединить какую-то функциональность? Могу ли я добавить какую-то полезность? – Я стараюсь представить, что я не видел ничего до попадания на конкретный экран. А понятно ли мне на этом экране всё, с учётом всего вышесказанного? – Сделал ли я всё, чтобы не использовать модальный интерфейс? Могу ли я показать все функции сразу? Могу ли я использовать квазирежим? – Легко ли мне попасть в каждый элемент? – Подумал ли я об обратной связи каждого действия? Она должна быть быстрой, постоянной и ненавязчивой. – А действительно ли мой интерфейс находится в границах ментальной модели пользователя? Могу ли я снизить сопротивление, если выхожу за границы этой модели? – Систематизирован ли мой интерфейс? Могу ли я что-то переиспользовать? Нет ли ошибок?
 4008   2020
Уровень проработки
 2362   2019
Принципы
 622   2019
Глубинное интервью
 1432   2019
Аудитория
 2436   2021
Earlier Ctrl + ↓
Do you want to discuss something? Just write to me! telegram or email
© Ivan Zviahin, 2016–2023 RSS
Powered by Aegea