Main

Stoloto
DevRel Helper
Step app
Gazpromneft
Finance app

Столото

«Столото» — 20 лотерей с онлайн и офлайн игроками. Играть можно как онлайн, так и офлайн. В этом задании рассматривается опыт офлайн игроков.

«Столото» устроили тендер для поиска подрядчика на долгосрочное сотрудничество. Прислали 3 задания, чтобы выбрать победителя с лучшим концептом. Важно учесть, что минимум нужно было выполнить 2 задания: одно для веба, другое для мобильного приложения.

Figma

Видео презентация

Цель

За неделю проработать концепты 2 задания для участия в тендере.

Моя роль в команде

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

Задача

Нужно предложить концепт мобильного сервиса проверки билетов для офлайн игроков. Требования:

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

Исследование проблемы

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

Что удалось выявить

1. Нет возможности переключится между режимами ввода без потери введённых данных. Можно проверить билеты только одного тиража выбранной лотереи.
2. При сканировании QR результат показывается сразу, нельзя добавить несколько билетов как в ручном режиме.
3. После проверки нужно переключаться между каждым билетом для просмотра выигрыша.
1
2
3
4. Сканирование QR кода возможно только у билета, купоны нужно проверять вручную.
Билет с qr кодом
Купон без qr кода

Гипотезы

1. Игроку важно быстро проверить 100 билетов, которые у него в руках, а не тратить время на проверку билетов только по одному тиражу.
2. Должно быть переключение между режимами сканированием и ручным вводом с сохранением ранее добавленных билетов в одном из режимов.
3. Показывать общий выигрыш по всем введенным/отсканированных билетам за одну сессию проверки.

Поиск решения

Сперва сделал User Flow, в котором учёл переключение между ручным режимом ввода, сканированием qr и экран с общей суммой выигрыша. Затем приступил к проработке ручного ввода.
User Flow

Ручной ввод

Количество билетов может быть 100 и список должен легко просматриваться без сложной группировки. Остановился на 3 варианте. В web версии расположение инпутов оказалось компактным, поэтому взял эту компоновку за основу, добавив третий инпут – номер билета.
Варианты 1
Варианты 2
Вариант 3
Web версия
Перенёс кнопку сканирования вниз: сейчас нужно тянуться пальцем до верха экрана. При ручном вводе появляется кнопка действия, а смена режима ужимается до миниатюры.
Как в приложении сейчас
Пока не добавлен ни один билет
Когда есть добавленные билеты
Билеты и купоны разных тиражей и лотерей, должны иметь визуальное отличие. Сейчас в приложении нет иконки лотереи, в веб версии она повторяется у каждого билета и не несет никакого смысла. В моем варианте она показывает принадлежность билета к конкретной лотерее.
Как в приложении сейчас
Мобильная версия сайта
Мой вариант

Сканированием QR

В режим сканирования коллега тоже учла список уже добавленных билетов, чтобы после каждого нового скана билет добавлялся в список. Сейчас в приложении сразу после сканирования открывается страница с результатом проверки. Также сохранена логика кнопки действия и переключения к ручному вводу.
Сейчас сразу после считывания QR показывается результат.
Сканировать билеты можно подряд. Они добавляются списком.
Шторку со списком можно раскрыть. Сохранена логика переключения на ручной ввод.

Экран выигрыша

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

Итог

1. Сейчас можно проверить билеты вручную только одного тиража и сканированием каждого отдельно, мы предлагаем более общий сценарий проверки одновременно большого количества билетов из разных лотерей.
2. Выбор способа добавления билета или купона: ручной и быстрый по QR, уменьшает вероятность возникновения ошибки, если не получилось отсканировать, можно ввести вручную. Также, этот комбинированный способ позволяет проверять как билеты (на которых есть qr), так и купоны (нет qr, только ручной ввод) за одну сессию.
3. Главное отличие финального экрана – сумма выигрыша, сейчас нужно просматривать выигрыш переключаясь между билетами, что крайне неудобно, для получения быстрого результата проверки.
В результате сделали последовательные сценарии проверки билетов с комментариями в узких и спорных местах.

DevRel Helper

Сервис для поиска самых активных пользователей сообщества был разработан на хакатоне Codenrock DevRel Hack.

Задача

Вам необходимо создать систему, анализирующую состав сообщества в github, которая способна ответить на следующие вопросы:

  • Из каких специалистов и с каким опытом состоит сообщество;
  • Интересы участников сообщества;
  • Градация участников сообщества в зависимости от их активности внутри и за пределами сообщества;
  • И другие метрики, характеризующие качество сообщества.

Результатом должен быть веб-сервис, который позволяет просматривать и анализировать информацию о сообществе, делать выборки по разным параметрам. Определение наиболее значимых параметров также является частью задачи. В качестве источника данных можно использовать NPM https://github.com/npm/cli или любое другое сообщество, сформировавшееся вокруг какого-либо популярного opensource продукта. Также приветствуется использование других источников данных об аудитории, например, Stackoverflow, тематические Slack сообщества и все остальное, на что хватит опыта и фантазии

Команда

UX/UI/Product designer (я), Project manager, Backend developer.

Исследование

Провел 3 интервью с DevRel специалистами. Чтобы сформулировать общую проблему, которую нужно решить.

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

Проблема

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

Поиск решения

Посмотрел какие есть похожие сервисы, обычно они больше для HR специалистов, но обратили внимание, что важно показать контакты и интересы, чтобы можно было быстро связаться с кандидатом.

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

Доработал прототип и он приобрел такой общий вид.

Решение

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

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

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

Результат – 5 место из 22 команд

Был написан bekend, оформлена презентация и сделан кликабельный прототип, который демонстрировал работу сервиса.
Наше решение мы презентовали жюри, в составе которого были эксперты из HH, MyGames, Первая грузовая.

Step app

Приложение для бега с move to earn механикой, для заработка с NFT кроссовок.

Figma
Step.app (официальный сайт)

Моя роль

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

Пример задачи на проекте

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

Решение

Сначала я составил User Flow и зафиксировал функциональные возможности на каждом этапе.

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

Вопрос в реализации был в том месте, где пользователь должен увидеть фразу из 12 слов и потом ее повторить, подтвердив то, что он ее записал или сохранил в защищенном месте.

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

Газпромнефть «Стрим решения»

Сервис для планирования ресурсов отделов сотрудников Газпромнефть на следующий год.

Моя роль

Занимался ревью текущего дизайна интерфейса ГПН «Стрим решения» в составе команды: подготавливал вопросы для Custdev, конспектировал интервью, анализировал полученную информацию, подготавливал итоговый отчет с выводами и рекомендациями.

Проблема

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

Исследование – Custom Development

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

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

По интерфейсу мы составили бэклог. В нём мы отразили все проблемные места интерфейса, опираясь на интервью с пользователями.

Результат

Составили документ с болями, выводами и рекомендациями, оформили в Notion. Руководитель проекта оценил скорость нашей работы, то что мы вникли в сложный процесс и своим взглядом со стороны помогли отделу дизайна ГПН в развитии продукта.

Приложение для управления финансов

Уже давно использую приложением Coinkeeper для управления финансами. Мне очень нравится старая версия приложения оно хорошо справлялось со своей задачей, но его перестали поддерживать и доступна только новая версия. В новом приложении ухудшился UX, появилось много лишнего функционала за счет более красивого дизайна. Приходится пользоваться новой версией, также в ней есть минусы, которые перекочевали из старой версии: нельзя добавить криптовалюту более 4 знаков после запятой (привет и пока биткоин, эфир), нет стандартных сортировок по часто используемым тегам, проблема конвертации валюты, валюта доходов и расходов нельзя поменять, неудобные графики статистики.

Мы решили сделать свой продукт

Мы с братом решили запускаем свой продукт на рынок, и проверить на сколько он нужен людям. Сама концепция близка к старой версии Coinkeeper, которую мы так любим.

Цель

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

Базовые принципы

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

  • Простота. Старая версия Coinkeeper простая и понятная, новые версии усложняет пользовательский опыт. Как показывает практика, ни одно приложение не может дать точную статистику по расходам, если подключить автоматическое занесение банковских операций, поэтому все операции нужно заносить в ручную, а так как это рутина, нужно максимально упростить пользовательский опыт. Другие инструменты по типу встроенной статистики в банковском приложении не отражает всей картины: использование налички, счета в других банках, крипта.
  • Скорость. У пользователя должна быть возможность быстрого внесения траты/дохода, потому что это рутина. Не должно быть такого, что для внесения траты нужно сделать 5 кликов и заполнить сложную форму, а такие конкуренты тоже есть. Конкурентный анализ показал, что в топе AppStore те приложения, у которых занесение траты происходит в 2-3 клика. Концепция перетаскивания монетки отлично себя зарекомендовала, так как даже новая версия Coinkeeper продолжает висеть в топ 1.
  • Понятность. На самом деле у приложения две основные задачи: внесение траты/дохода и просмотр статистики. Наше предположение состоит в том, чтобы проверить, реально ли совместить эти два действия на одном экране, чтобы при открытии приложения пользователь мог либо посмотреть расходы/доходы/баланс, либо быстро занести новую операцию.

Приоритеты

Сделать быстрый MVP без сложного дизайна с анимациями.

  • MVP. Сделать MVP без сложного дополнительного функционала, которым пользуются не все. Сконцентрироваться на двух самых важных функциях, чтобы они работали отлично: занесения траты/дохода, просмотр статистики и истории.
  • UX. Не делать сложный UX, упростить все до минимального количество шагов.
  • React Native. Для упрощения разработки использовать кроссплатформенный язык программирования.

Исследование

На данный момент был проведен конкурентный анализ 16 приложений из топа AppStore по количеству оценок. На основе полученных данный был скорректирован первый вариант прототипа главного экрана в двух состояниях: просмотра статистики, занесения траты/дохода.

На что я обратил внимание: количество кликов для добавления новой траты/дохода, что важно отобразить на главном экране (расходы, доходы, баланс), в каком виде реализованы категории трат, вид графика статистики.

User flow

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

Прототип

Сейчас делаю первую версию прототипа, чтобы провести юзабилити-тестирование и выявить проблемные и непонятные места.