Очень близкая мне статья про сторифреймы

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

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

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

Главное не забывать, что внутреннюю речь пользователя мы только предполагаем. В реальности всё не так. Её нужно проверять ю-тестами, в идеале — с реальным «мышлением вслух».

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

История сравнения двух сервисов на этом не заканчивается.

Напомню, что как в юду, так и в профиру нужно заплатить за то, чтобы твое предложение увидел заказчик (в районе 20-150 рублей).

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

А что там в юду?
Тем временем в юду я, не выходя из приложения, нажал кнопку «стать мастером» и начал свой путь воина — предоставление личных данных, знакомство с внутренними правилами, небольшой тест на усвоение этих правил. И все, можно выходить на охоту за заказами.

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

И каково же было моё удивление, когда на следующий день мне перезвонил один из заказчиков! Он попросил скинуть портфолио, после чего мы минут 20 обсуждали варианты дизайна того приложения, который он задумал.
Мягко говоря я был поражен )

Я считаю мне повезло оказаться в этих ситуациях — данные кейсы отлично проиллюстрировали разницу подходов двух сервисов.

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

Периодически обновлять фреймворк

У нас в ГдеМатериале есть хорошая практика — мы периодически проверяем актуальность зависимостей. Я говорю не о мелких обновлениях и не о фиксах безопасности (они давно автоматизированы), а об обновлении мажорных версий библиотек, скажем Django с 1.11 до 2.0.

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

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

Самое важное в обновлении фреймворка — не копить изменения. Гораздо проще 5 раз обновить джанго на соседнюю версию, чем прыгнуть с 1.8 сразу на 2.2. Маленькие обновления приносят меньше регрессий и в целом проходят легче — согласитесь, ведь всегда же лучше растянуть один пиздец на 5 маленьких пиздецочков. Даже психологически гораздо легче решиться на маленький апгрейд, чем на большой скачок.

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

Модель двойного алмаза

Если дивергентное мышление — это поиск множества решений одной проблемы, то противоположным ему будет конвергентное мышление — отсекание всего лишнего, анализ вглубь.

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

Если рассматривать этот процесс в рамках разработки продукта, то получится примерно такая история:

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

Команда это важно

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

У нас этого не произошло, и на это было две причины.

Первая, и самая большая — я не хотел делиться работой. Я поставил себе глобальную цель использовать учебу как трамплин для раскачки своих навыков (я писал об этом ранее https://t.me/bukhtiyar/152), поэтому мне было в кайф брать на себя как можно больше нагрузки, а не быть менеджером команды. В итоге ребята, увидев мой запал, вместо того, чтобы включиться в конкуренцию за работу над проектом, отступили и дали мне полный карт-бланш.

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

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

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

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

Артём Полтавцев написал о формах записи в салоны красоты

Часто салоны работают с сервисами вроде YClients и Sonline. Виджет сервиса не общается с сайтом салона, и все параметры записи пользователь выбирает через виджет: услуга, студия, мастер, время. В этом случае структуру сайта лучше максимально упростить.

Сервис GBooking можно связать с сайтом по API. Логика заказа: выбор первой услуги → выбор студии → добавление услуг → выбор мастера и времени. Выбор первой услуги ограничивает выбор студий, так как не везде может быть одинаковый набор специалистов и оборудования.

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

https://vc.ru/design/70728