Оработе ч.2

Ещё немного про внутряк


Клиентская часть ERP - личный кабинет пользователя



Личный кабинет аналогичен по построению внутренней структуре - по ширине и основным визуальным паттернам.

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

1 уровень - Проект

2 уровень - Меню Проекта


Пока почти все ЛК будут состоять из 1 Проекта, не необходимо предусмотреть для польз-ля возможность ориентироваться в 5+ Проектах (для застройщиков и прочих клиентов с большим кол-м объектов). Если Проекты в разных городах/странах - пометки в названиях Проектов, иконки, фильтр м.б. - на подумать.





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

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


Чат/сообщения - только с личным менеджером.

Дать возможность написать директору (чат? письмо?)


Остальное - по мере появления и обработки новой информации.

February 4, 2019
by Hissing Booth
5

Конспект по дизайн-системам

Терпеть не могу сумбур, равно как терпеть не могу терять какую-то важную инфу, статьюшечки и прочее. Может так поможет.



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

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

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

Создаем перечень всего вышеописанного для верности.

Основа:

1 — Инструменты, используемые на данный момент,

2 — Нейминг папок, файлов, слоев, даже систему названий символов и стилей в Figma.

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

4 — Руководство по стилям.


Инструменты

Тут все понятно - есть команда, есть привычные инструменты. Если есть необходимость задействовать какие-то еще - идем и обсуждаем с командой. EZ.


Нейминг:

1.1 Папки

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

Приложу скрин статьи на ux пабе по теме, чтоб не забыть:

*ну не знаю, я пока в поисках своего идеального решения

1.2 Файлы

Тут тоже предпочту обсудить и решить с командой - особенно с фронтом. Если использовать Фигму и Реакт в тесной связке, то нейминг в Фигме должен быть аналогичен неймингу в коде, а значит - просто решить, что мы там используем. БЭМ или своё-другое.


Насую примеров из всё той же статьи:

Иконки: icons/interface/normal/instance_name (использование / при экспорте элементов поможет автоматически распределять по папкам).

«icons/interface/state/name of instance "

«Primary-Accent/(colourname) «

Символы:

Buttons/Btn50px/teal/icon-right/hover



Все еще немного сырая, зато моя

1.3 Документация

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

Пока, конечно, я все же считаю эталонным такой способ - как у Альфа Банка, у Мэйла, да много у кого.


Руководство по стилям

2.1 Интерфейсная сетка

К примеру, 8 dp. Она, кстати, используется в Дизайне Гос. систем РФ.

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

2.2. Шрифт


Модульный масштаб — лучший способ задать размеры типографики и даже пропорции всего макета в целом.

Сначала вы выбираете коэффициент пропорции, затем базовый размер текста, например, 16px. После этого вы умножаете базовый размер на коэффициент для получения последовательной шкалы размеров: 16px, 26px, 42px, 68px, 110px.


Шкала шрифтов Diatonic

Модульная шкала

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

2.3. Мудборды

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

2.4. Библиотека паттернов и Флоу

Атомарный дизайн

Проще некуда реализовать в Фигме. Библиотека стилей, компонентов, все это может быть сразу же перенесено в продакшн, возможность работать командой над одним продуктом в рамках одного документа. Еще бы попробовать командную работу в Фигме.. Ну да ладно, соло тоже очень даже недурно.

Для юзер флоу пока не нашла себе идеального сервиса/программы. На данный момент использую Фигму с шаблонами uxflow, буду искать дальше. Возможно проще всего действительно сделать удобный фигма-шаблон и не множить инструменты.


Продукт и все-все-все

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

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

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

  • Как мы общаемся с пользователем - письменный стиль, особенные обороты, тут можно вообще отдельно по пунктам все расписать.
  • Как мы приветствуем польз-ля, как мы прощаемся с польз-м.
  • Какие местоимения используем и как формулируем базовые интерактивные конструкции ("Благодарим за ваш отзыв! Модерация займет 24 часа").
  • Особенности изображений - тут уже не технические подробности, а смысловые. К примеру, мы не используем изображения свиней, петухов и лакрицы (потому что лакрица отвратительна).
  • Особенности движения - тайминг, скорость прокрутки, скорость анимаций и проч. интерактивные штучки.
  • Ко всему прочему можно составить список коммуникаций с пользователем и прописать правила для отдельных вещей, к примеру, имейлов. В интернет-магазинах обычно развит имейл-маркетинг, и важно не переутомлять пользователя и не надоедать ему, чтобы получать стабильную прибыль и чтоб все были довольны.


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


Статья на uxпабе


January 14, 2019
by Hissing Booth
8

"А почему бы не..." ч.1

Мне, как и героине Алисии Сильверстоун из фильма "Бестолковые" хочется сделать что-нибудь хорошее для мира - но чаще всего в сфере цифровых продуктов. Да, идеи могут быть нереалистичными/идиотичными/лолшто, бат энивейс.


Скипнув часть, где я ною за возраст, перейду к сути - у нас нет единой дизайн-системы для электронных ресурсов в сфере государственного здравоохранения. Есть вот такое похвальное творение - https://design.gov.ru/

Но когда я хочу сходить в поликлинику, ПНД, больничку БЕСПЛАТНО, то сперва иду гуглить (слишком стар, чтобы не болеть - слишком молод, чтобы сидеть в очередях в регистратуру). У гос. поликлиник и больниц хотя бы есть сайты, уже хорошо. Но по степени уебищности они варьируются от "ну ладно, хотя бы аккуратно" до "привет, девяностые, лучше позвоню.. стоп, а где контакты?".

Это у нас "ладно, хотя бы аккуратно"


Это видимо нечто вроде промежуточного варианта уровня пиздеца


Ну тут, в общем-то, все понятно


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

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



Вот, к примеру, сценарий. Мне необходимо узнать, где ближайший мой дядя-психотерапевт, потому как в районной поликлинике такового нет. Знакомый рассказал, что в ПНД. А если бы не рассказал? Идём гуглить или звоним в поликлинику. Дозвониться туда - тот еще квест. Нагуглили, окей. Кто мой доктор? Звоним (если дозваниваемся!) в ПНД, называем адрес, узнаем, потом запись еще, но это уже финишная прямая.

Единая дизайн-система гос. мед. учреждений помогла бы избежать путаницы и траты времени на сайте, - мы знаем, что сверху основное меню выбора типа заведения, поиск, под ним - меню выбранного учреждения, справа основная информация по рабочим дням, специалистам, справочная информация, всякое такое. Ну это для примера. Вы знаете, что будет на сайте ЛЮБОЙ поликлиники, больницы, диспансера. Вы знаете, ГДЕ искать информацию касательно графика приёма специалистов и расписания работы в праздничные дни.

Крайне классно было бы иметь возможность узнать какие гос. мед. учреждения приписаны к адресу вашего проживания: районная детская поликлиника №ХХ, районная взрослая поликлиника №ХХ, такой-то диспансер, такой-то, еще какое-то там учреждение. Ну понятно в общем.


Да, я понимаю, насколько проблемным был бы сбор и систематизация всей этой информации по каждому дому (наверное?). Что наверняка дело неоправданно затратное, но кто сказал, что у меня рождаются только самые оптимальные идеи?


У нас хотя бы есть система электронной записи, госуслуги, и на том спасибо.


И да, ЦА от этого всего не горячо и не холодно, - вряд ли моя мама пойдет гуглить, ей проще позвонить. Однако ж я постепенно приучила ее к тому, что в интернете очень много полезной информации, так что возможно гуглить она бы пошла.


Моей возрастной группе возможно было бы удобно - 50/50. Тут уж нужно собирать статистику, опрашивать людей. Пока по кругу знакомых могу сказать, что это люди, которым:

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

Последних, наверное, чуть меньше, чем первых двух.



В заключение этой немного сумбурной статьи (?) могу добавить, что очень бы удивилась и обрадовалась, узнай, что нечто такое уже в планах. Я понимаю проблемы бюджетной медицины, понимаю проблемы пользователей, пациентов и вообще всех, наверное. И, конечно, очень бы хотела помочь и сделать что-то действительно полезное, доброе и светлое, чтобы решить их все.




Поживем - увидим, хуле.

January 10, 2019
by Hissing Booth
3

Оработе ч.1

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

*Скорее всего тут не будет изображений, а только лишь скучный текст.


Лендинг или сайт?

Когда я пришла на текущее место работы, первой моей задачей был редизайн лендинга. Было очень много вопросов из разряда "Зачем? Что с текущим? Где аналитика за последний год? С кем поговорить о конверсии и продажах, каковы цели бизнеса, кто занимался исследованием ЦА?". Ответов было слишком мало, жалкие крохи, всего ничего, - у всех была посленовогодняя суматоха, и вероятно было немного не до этого.

Спустя какое-то время получилось начать двигаться вперед к ответам на вышепоставленные вопросы вооружившись отделом маркетинга и главой отдела по клиентскому сервису. Самое сложное - формулировать вопросы. Для людей, которым сложно формулировать ответы - тем более. Так что для себя я выделяла основные общие вопросы (что-то типа "Что мы делаем?"), которые сужала и разбивала на меньшие и более точные. Ещё одно наблюдение - с некоторыми людьми легче было иметь диктофон. Исходя из этих открытий впредь я стала уточнять сколько времени мне может уделить тот или иной сотрудник (формулируя именно так, без надменных "Сколько продлится наша беседа?"). Особенно полезно когда внезапно забываешь зарядить телефон, и нужно рассчитывать заряд для диктофона.

Спустя еще какое-то время нам рассказали о планах и векторе развития. Это как раз затронуло один из главных на тот период вопросов - лендинг нам все-таки нужен или же полноценный сайт? Руководство собиралось выкатывать полноценный сайт с интернет-магазином, но пока лишь собиралось. Уже что-то. Я пальцы в кровь сбила описывая стратегию, возможные направления реализации, вопросы, требовавшие ответов и решений, сводила цели бизнеса и пользователей, пытаясь донести, что эти самые цели должны максимально совпадать, чтобы в итоге получить долговременный эффект. Все-таки делать что-то без подготовленной базы совершенно неправильно.

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


Сайт?

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

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

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


Надо ли приложение?

В какой-то момент был затронут и этот вопрос.

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


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


Системность

Она нужна для любого проекта. Неважно, решили мы делать сайт, еще один лендинг, сервис, приложение - пофиг. Для начала нужно понять, кто же мы такие, что же мы делаем и для кого (ну и еще куча вытекающих вопросов, понятное дело).

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


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

Подробней напишу скорее всего чуть позже, надо многое подготовить и обдумать.


...Ту би континьюед

January 9, 2019
by Hissing Booth
2

Небольшой конспект по юикс текстам

"Собака Павлова" поделилась новым кейсом по одной из моих любимых тем - интерфейсным текстам. Разработка велась для Сбербанка, мне так понравилась логика и некоторые моменты, что я аж конспект себе сохраню, чтоб не потерялось нигде.



По специальности я филоло-журналист, а по знаку зодиака грамар-н.. зануда. Так что про тексты я люблю.

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



Отталкиваться я начала от оценки типа уведомления:

  • сообщает дополнительную информацию - Подсказки
  • сообщает какой-то результат по итогам чего-то - Уведомления (которые изначально назвала общим словом "Ошибки", но вскоре поняла, что такую же логику несут в себе сообщения об успехе, так что пришлось переиграть.


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

Подсказки

  1. Всплывающие подсказки

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

Обязательные подсказки будут располагаться в паре с иконкой (? или !) в тех местах, где у 60%+ пользователей продукта возникают сложности. Остальное же будем внедрять пока к обычным ссылкам по мере тестирования. В дальнейшем такие подсказки вырастут в Подсказки по процессу.


2. Подсказка-подстрочник

Его также можно объединять с ошибками и предупреждениями ввода по принципу расположения. Возможно в итоговой документации так и будет, посмотрим.


3. Подсказка по процессу

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

Вид - пока я не включала их в дизайн систему, и можно подумать. Скорее всего - text style Body / Caption с основным темным цветом на лёгком фоне. Самое главное - не перемягчить с цветом фона: он должен быть заметен и не теряться в базовой ui-палитре. Пока оставлю на подумать синий, жёлтый.


Уведомления / Ошибки

  1. Ошибки и предупреждения ввода (подстрочник у инпута)

Используется с соответствующей иконкой


2. Ошибки и предупреждения по процессу

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

Вид - надо подумать и посмотреть в контексте всей дизайн-системы. Отличие от Подсказки по процессу в плане визуала - наличие заголовка. Все остальное же будет либо:

  • аналогично Подсказке по процессу, только фон будет ~15% opacity от основных саппорт-цветов; заголовок - 100% opacity основных саппорт-цветов
  • рамка саппорт-цвета, фулл подложка под заголовок, заголовок инверс




Страницы успеха

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

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

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

  1. Какая операция завершена?
  2. Что именно было сделано? (для польз-ля, контрагента, клиента)
  3. Требуется ли что-то прямо сейчас? (от польз-ля, контрагента, клиента)
  4. Требуется ли что-то в дальнейшем? (от польз-ля, контрагента, клиента)
  5. Возможные шаги применительно к конкретной ситуации (андер констракшн)
  6. Что дальше делать сотруднику?




Итог

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

December 25, 2018
by Hissing Booth
12
Show more