Как junior-дизайнер создавал приложение по менеджменту задач и при чем тут рисунки на полях блокнота

Доброго времени суток, vc.ru. Меня зовут Динар, я веб-дизайнер из Казани. Мне хочется показать вам концепт приложения для менеджмента задач, главной фичей которого является попытка перенести «бумажный» опыт из блокнота в мобилки для нативного контроля задач.

Проблема

Проблема заключалась в том, что хоть я и сталкивался с разными CRM-системами («Битрикс», Armo, Trello,… ), планировщиками задач (Google Task, системные заметки телефона, Google Keep), но ни один из них не смог полностью удовлетворить мою главную потребность — привести в порядок мои мысли и выразить их как конкретную задачу.

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

Как junior-дизайнер создавал приложение по менеджменту задач и при чем тут рисунки на полях блокнота

Бумага и ручка — именно они лучшего всего упорядочивали хаос в голове, выражали его в ясном виде и держали все под контролем. Но и у бумаги есть свои минусы

Поиск идеи и wireframes

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

Более опытные дизайнеры могут возразить, а почему я так быстро перешел к wireframes и пропустил другие важные этапы? Где CJM, где user flow, где анализ потребностей рынка, персоны, интервью?

Необходимо объясниться. Помимо своего концепта в голове, у меня так же были и другие мотивы. Во-первых, в то время я как раз потерял работу (спасибо глобальной пандемии), и для меня это стало толчком для развития и перехода из веб-дизайна, коим я тогда занимался, в сторону UX/UI. Хотелось быстрее выкатить этот концепт как один из примеров для отклика на вакансии.

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

Забегая вперед, примерно так выглядели уже почти финишные wireframes
Забегая вперед, примерно так выглядели уже почти финишные wireframes

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

Спойлер: нет, не смог. Я обо***лся

Первые ошибки

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

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

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

Apple раздора

Вторая проблема, это неправильный выбор платформы, для которой создавался концепт. Дело в том, что меня можно по-своему назвать адептом Google Material Design. Мне очень нравится эта система. Не столько из-за своей внешней оболочки, сколько из-за ее правил.

Видите ли, по своему образованию я инженер и привык использоваться в работе ГОСТы, СНиПы и ТУ. И MD очень на них похож. В ней четко расписаны все правила, все отступы в конкретных единицах, возможные форматы, правила адаптивности и многое другое.

Ну а что касается Human Interface Guidelines… Видите ли, меня зовут Динар. Я родом из маленькой деревушки в Татарстане. Я очень люблю крепкий чай с молоком и ни разу в жизни не пользовался ни одной продукцией Apple. Вообще ни одной. Ни iPhone, ни Mac, ни Apple Watch. Ни-че-го. Сами же гайды Apple выполнены в стиле самой компании. Они больше говорят об эмоциях, примерах использования, но очень мало конкретной информации в виде правил и чисел.

Эти два компонента из HIG стали одними из решающих доводов для смены платформы на iOS
Эти два компонента из HIG стали одними из решающих доводов для смены платформы на iOS

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

Если даже брать их обычные системные гарнитуры. Как по мне, San Francisco лучше Roboto, а Roboto Slab проигрывает New York. Есть еще неплохой Segoe от Мелкомягких, но он не про мобилки.

Давай по новой, Миша, все…

Итого, из-за этих ошибок, пришлось вернуться назад, нормально расписать сценарии, построить user flow. Также под нож пошли все UI наработки, созданные под Android.

Кусочек User Flow. Еще самое начало, все когда все выглядело симпатично, перед тем как утонуть в мешанине текста
Кусочек User Flow. Еще самое начало, все когда все выглядело симпатично, перед тем как утонуть в мешанине текста

Отрисовка макета

После того, как с UX было покончено, начал собственно отрисовку экранов макета.

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

Первые экраны

Начальные экраны банальны и похожи на любое другое приложение. Страницы авторизации, главный экран и профиль. Из необычного тут можно выделить разве что не совсем стандартные Tab Bars. Точнее, это даже Toolbar, который очень похож на Tab Bar. Небольшая жертва правил HIG в пользу стилистики. Все второстепенная информация, настройки, списки и т.д. были стыдливо спрятаны в углу под иконкой профиля.

Как junior-дизайнер создавал приложение по менеджменту задач и при чем тут рисунки на полях блокнота

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

Создание задачи

Пользователь создает какую-то общую задачу.

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

Эта страница похожа на привычные всем пользователям приложения «Заметки». Количество информации сокращено до самого минимума (название — описание — сроки/изображение по желанию).

Из особенностей здесь появляется плашка внизу, над клавиатурой. По своей сути она является каким-то гибридом Toolbars, Context Menus, Custom Keybords. Зачем она здесь нужна? Далее эта плашка станет попыткой уместить наши паттерны взаимодействия с бумагой/ручкой в мобильном телефоне.

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

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

Как junior-дизайнер создавал приложение по менеджменту задач и при чем тут рисунки на полях блокнота

В начале было Слово

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

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

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

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

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

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

Точно также вы должны поступить в приложение. Напишите себе заметку «позвонить…»

  1. Вот только прямо по ходу набора текста, приложение предложит вам строчку текста «позвонить человеку» превратить в кнопку действия. Чтобы когда через пару часов вы вернетесь к своему списку задач, вы просто нажали на иконку и созвонились.
  2. Или нажмите на основной FAB, выберите действие «Звонок» и перетащите ее в нужную часть текста
  3. Или выделите нужный вам абзац и добавьте нужное действие
Как junior-дизайнер создавал приложение по менеджменту задач и при чем тут рисунки на полях блокнота

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

Как junior-дизайнер создавал приложение по менеджменту задач и при чем тут рисунки на полях блокнота

Разумеется, возможностей редактирования будет гораздо больше. Будут поддерживаться как стандартные стили текста в iOS вроде списков, выделений жирным, курсивом; так и другие действия помимо звонка, вроде маршрута, крайнего срока, добавления файлов или изображений.

Самое важное здесь, это сохранить основной опыт пользования:

  • Появилась задача
  • Записал ее в виде текста
  • К тексту применяется интерактивная функциональность.
Как junior-дизайнер создавал приложение по менеджменту задач и при чем тут рисунки на полях блокнота

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

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

Заключение

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

Что дальше?

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

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

Надеюсь, эта статья вызвала у вас интерес. И если бы вы поддержали меня стрелкой вверх, я был бы вам очень благодарен. Если вдруг захочется что-то спросить, всегда буду рад. Telegram — @latipovdinar

2828
16 комментариев

Привет! Подскажите, в каком приложении делали карту user flow? 

3
Ответить

Привет
На этапе обдумывания накидываю все свои мысли на доску в Miro (с одной "r", не путать с Mirro). Лично для меня этот сервис удобнее всего, хоть аналогов есть приличное кол-во
А вот для презентации, например для Bh, уже перерисовываю финишный вариант в Figma. Чтобы все рамки, линии, текст совпадали с единой стилистикой. Плюс в Figma это очень легко делается компонентами: создал 2-4 основных компонента блоков, а потом просто соединяешь их как конструктор и меняешь текст

1
Ответить

Молодец, Динар! Лучше не откладывай, а добей до MVP и смотри: полетит-развивай, нет-забудь. Важны не фичи, а одна главная ценность - ее и надо заворачивать в MVP

2
Ответить

То, что описал автор, далеко не мвп. Считаю, что создание ещё одного «туду» - это просто потеря времени, пока не будет придуман действительно новый способ взаимодействия с интерфейсами, который откроет дорогу новым сервисам с уже привычными механиками. А пока это просто кручение-верчение того, что было сделано давным давно

3
Ответить

Ну вот, я зря искал название приложения, чтобы поискать его в AppStore? :)

По поводу переизобретения велосипеда: Figma переизобрели Sketch, Notion переизобрели Evernote, Facebook переизобрели MySpace и Classmates, Tesla переизобретают автомобиль и т.д. Думаю, больше примеров не надо.

Если действительно хочешь этот концепт довести до реального приложения, то, будучи продактом, не могу не посоветовать, что очень полезно будет пойти по пути, который описал Булат в соседнем комментарии (одна главная ценность -> MVP -> тест и анализ отклика аудитории -> итеративные улучшения).

Все менеджеры задач, которые я пробовал для своих личных тасков, по итогам были выкинуты за 1-2 дня. Поэтому для меня это насущная проблема. Я даже использовал одно время джиру для этого (и она справлялась для моих задач лучше, например, чем Todoist :D), а сейчас использую Notion, хотя она и не очень подходит для подобного.

2
Ответить

Комментарий недоступен

Ответить

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

2
Ответить