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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#мобильноеприложение #дизайнеры