Русский
Русский
English
Статистика
Реклама

Ui/ux дизайн

Figma делаем дизайн компонентов, пригодный для экспорта в код

15.02.2021 08:08:38 | Автор: admin

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

Начнём с простого

Нарисуем лист вью с иконкой, и сгенерируем вёрстку.

Так выглядит примерная структура нашего элемента списка - слева иконка, и далее текст.

Такую структуру будет иметь наш компонент - вертикальный набор элементов, который мы придумали выше.

Так, со структурой разобрались, поняли что нам примерно нужно сделать, теперь приступаем непосредственно к дизайну. Для этого мы возьмём один элемент, и сделаем его на основе компонентов Фигмы и применим к нему Auto layout. Сначала объединим текст и иконку, добавим отступы, сделаем выравнивание по высоте в середине, и по левому краю. Получится так

Далее нам нужно создать два элемента, расположить их друг под другом по высоте, и объединить их Auto layout. В целом всё кажется готовым, но на самом деле, если вы поменяете длинну текста, то элементы не будут гибко подстраиваться друг под друга.

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

В результате у нас должен получиться такой вот список.

Запускаем генератор кода.

Открывается плагин с генерацией кода. где мы можем выбрать необходимую нам технологию. Я буду использовать Tailwind 2. Далее выберем нужный нам элемент дизайна, и плагин выдаст нам готовую вёрстку.

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

Так, всё работает, кроме иконок, которые нам нужно копировать как SVG и вставить в наш код. Делается это вот так

Заменяем наши иконки в вёрстке (я вставил прям в разметку, но вы можете и так как вам удобно - по url на пример.).

Получаем результат, который идентичен нашему в Фигме.

Подробнее про Auto layout тут.

Результат тут.

Сложнее. Рисуем карточку товара.

Нашей целью будет сделать так, чтобы при генерации кода, наша карточка была выполнена на основе display: flex; - CSS модели, для построения гибких контейнеров.

Я нарисовал макет, как в прошлом примере, сделал дизайн, распределил блоки, и при помощи Auto layout выровнял всё так, как мне нужно. Сгенерировал код, подправил некоторые нюансы с картинками и иконками, в результате получил готовую карточку товара. Подробнее про Flexbox тут.

Моя сгенерированная разметка доступна по ссылке ниже. Вы можете посмотреть и попробовать сами.https://play.tailwindcss.com/2VhmQJIJDl

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

Подробнее..

Sign in with Apple дедлайн уже 30 июня

17.06.2020 10:12:43 | Автор: admin

Как мы уже писали в прошлой статье, к 30 июня 2020 все новые аппстор приложения и апдейты должны поддерживать функцию Sign in with Apple.



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


Все надо делать по ГОСТу


Гайдлайны по дизайну кнопок от эппла нельзя нарушать ни в коем случае. Но не факт, что вы узнаете об этом сразу. Сначала мы отправили на ревью билд вот с такой кнопкой для Sign in with Apple.



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


Your app uses Sign in with Apple as a login option but does not use the appropriate Sign in with Apple button design, branding, and/or user interface elements as described in the Sign in With Apple Human Interface Guidelines. Specifically:
-The Sign in with Apple says Apple but should use the following version: Sign in with Apple.
-The custom Sign in with Apple button in your app does not follow Apple button design, branding and/or user interface elements.
Next Steps
To resolve this issue, revise the Sign in with Apple button design, branding and/or user interface elements in your app so that it follows all the Sign in With Apple Human Interface Guidelines.

Мы оперативно собрали штаб, прочитали гайдлайны, поменяли пару стилей и получилось примерно так:



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


Приватные имейл адреса


При логине с айфончика, пользователь может выбрать опцию Hide my email. В этом случае вы получите его прокси имейл, созданный эпплом вида random_chars@privaterelay.appleid.com. Документация утверждает, что по умолчанию на такие адреса нельзя ничего отправить, не сделав дополнительных телодвижений.


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


Но на деле все оказалось несколько иначе:


  • Мне удавалось отправить письмо с личного ящика на прокси имейл, хотя домен моей почты не был прописан в эппловской админке.
  • Некоторые прокси имейлы переставали получать нашу рассылку с ошибкой reason: 550 5.1.1 Relay not allowed; type: bounce. При отправке с личной почты, приходило уведомление Undeliverable. XXX was not found on privaterelay.appleid.com

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


Кстати, большинство пользователей скрывают свои имейлы с помощью этой функции.


Люди не хотят аутентифицироваться каждый раз


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


User interaction is required any time a new identity token is requested. User sessions are long-lived on device, so calling for a new identity token on every launch, or more frequently than once a day, can result in your request failing due to throttling.

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


Вместо вывода


Sign in with Apple оказалась не такой простой в реализации фичей, как думалось вначале, но довольно удобной для конечных пользователей. Получить настоящий имейл пользователя теперь будет гораздо сложнее, что явно скажется на маркетинге и методах привлечения пользователей. А эппл, как всегда, хочет замкнуть все провода на себя)


Пока что мы добавили данную функцию только для устройств Apple, но далее планируем добавить ее для Android и веб приложения (док). Основная мотивация скорее унифицировать страницу логина для всех платформ, чем прирост DAU.


Если вы нашли еще какие-то интересные особенности Sign in with Apple добро пожаловать в комментарии!


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


Alconost занимается локализацией игр, приложений и сайтов на более 70 языков. Мы также делаем рекламные и обучающие видеоролики.
Подробнее

Подробнее..

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

03.07.2020 16:05:03 | Автор: admin
Многие убеждены, что область Human Computer Interaction (HCI или человеко-компьютерное взаимодействие) сводится только к проектированию сайтов или приложений, а основная задача специалиста удовлетворить пользователей, увеличивая на несколько пикселей кнопку лайка. В посте мы хотим показать, что это совсем не так, и рассказать, что происходит в HCI на стыке с исследованиями машинного обучения и искусственного интеллекта. Возможно, это позволит читателям посмотреть на эту область с новой для себя стороны.

Для обзора мы взяли труды конференции CHI: Conference on Human Factors in Computing Systems за 10 лет, и с помощью NLP и анализа сетей социтирования посмотрели на темы и области на пересечении дисциплин.




В России особенно силен фокус на прикладных задачах проектирования UX. Многие события, которые помогали росту HCI за рубежом, у нас не произошли: не появилось iSchools, ушли из науки многие специалисты, занимавшиеся близкими аспектами инженерной психологии, и т. д. В результате профессия возникала заново, отталкиваясь от прикладных задач и исследований. Один из результатов этого виден даже сейчас это крайне низкая представленность российских работ по HCI на ключевых конференциях.

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

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

В первую очередь мы расскажем, что происходит в таких областях, как xAI и iML (eXplainable Artificial Intelligence и Interpretable Machine Learning) со стороны интерфейсов и пользователей, а также как в HCI изучают когнитивные аспекты работы специалистов data science, и приведем примеры интересных работ последних лет в каждой области.

xAI и iML


Методы машинного обучения интенсивно развиваются и что важнее с точки зрения обсуждаемой области активно внедряются в автоматизированное принятие решений. Поэтому исследователи все чаще обсуждают вопросы: как пользователи, не являющиеся специалистами в машинном обучении, взаимодействуют с системами, где подобные алгоритмы применяются? Один из важных вопросов такого взаимодействия: как сделать, чтобы пользователи доверяли решениям, принятым на основе моделей? Поэтому с каждым годом все более горячей становится тематика интерпретируемого машинного обучения (Interpretable Machine Learning iML) и объяснимого искусственного интеллекта (eXplainable Artificial Intelligence XAI).

При этом, если на таких конференциях, как NeurIPS, ICML, IJCAI, KDD, обсуждают сами алгоритмы и средства iML и XAI, на CHI в фокусе оказываются несколько тем, связанных с особенностями дизайна и опытом использования этих систем. Например, на CHI-2020 этой тематике были посвящены сразу несколько секций, включая AI/ML & seeing through the black box и Coping with AI: not agAIn!. Но и до появления отдельных секций таких работ было достаточно много. Мы выделили в них четыре направления.

Дизайн интерпретирующих систем для решения прикладных задач


Первое направление это дизайн систем на основе алгоритмов интерпретируемости в различных прикладных задачах: медицинских, социальных и т. д. Такие работы возникают в очень разных сферах. Например, работа на CHI-2020 CheXplain: Enabling Physicians to Explore and Understand Data-Driven, AI-Enabled Medical Imaging Analysis описывает систему, которая помогает врачам исследовать и объяснять результаты рентгенографии органов грудной клетки. Она предлагает дополнительные текстовые и визуальные пояснения, а также снимки с таким же и противоположным результатом (поддерживающие и противоречащие примеры). Если система предсказывает, что на рентгенографии видно заболевание, то покажет два примера. Первый, поддерживающий, пример это снимок легких другого пациента, у которого подтверждено это же заболевание. Второй, противоречащий, пример это снимок, на котором заболевания нет, то есть снимок легких здорового человека. Основная идея сократить очевидные ошибки и уменьшить число обращений к сторонним специалистам в простых случаях, чтобы ставить диагноз быстрее.


CheXpert: автоматизированное выделение областей + примеры (unlikely vs definitely)



Разработка систем для исследования моделей машинного обучения


Второе направление разработка систем, которые помогают интерактивно сравнивать или объединять несколько методов и алгоритмов. Например, в работе Silva: Interactively Assessing Machine Learning Fairness Using Causality на CHI-2020 была представлена система, которая строит на данных пользователя несколько моделей машинного обучения и предоставляет возможность их последующего анализа. Анализ включает построение причинно-следственного графа между переменными и вычисление ряда метрик, оценивающих не только точность, но и честность (fairness) модели (Statistical Parity Difference, Equal Opportunity Difference, Average Odds Difference, Disparate Impact, Theil Index), что помогает находить перекосы в предсказаниях.


Silva: граф связей между переменными + графики для сравнения метрик честности + цветовое выделение влиятельных переменных в каждой группе

Общие вопросы интерпретируемости моделей


Третье направление обсуждение подходов к задаче интерпретируемости моделей в целом. Чаще всего это обзоры, критика подходов и открытые вопросы: например, что понимать под интерпретируемостью. Здесь хотелось бы отметить обзор на CHI-2018 Trends and Trajectories for Explainable, Accountable and Intelligible Systems: An HCI Research Agenda, в котором авторы рассмотрели 289 основных работ, посвященных объяснениям в искусственном интеллекте, и 12 412 публикаций, цитирующих их. С помощью сетевого анализа и тематического моделирования они выделили четыре ключевых направления исследований 1) Intelligent and Ambient (I&A) Systems, 2) Explainable AI: Fair, Accountable, and Transparent (FAT) algorithms and Interpretable Machine Learning (iML), 3) Theories of Explanations: Causality & Cognitive Psychology, 4) Interactivity and Learnability. Кроме того, авторы описали основные тренды исследований: интерактивное обучение и взаимодействие с системой.

Пользовательские исследования


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

Инструментов и алгоритмов интерпретации появилось очень много, поэтому возникает вопрос: как понять, какой же алгоритм выбрать? В работе Questioning the AI: Informing Design Practices for Explainable AI User Experiences как раз обсуждаются вопросы мотивации использования объясняющих алгоритмов и выделяются проблемы, которые при всем многообразии методов еще не решены в достаточной степени. Авторы приходят к неожиданному выводу: большинство существующих методов построены так, что отвечают на вопрос почему (почему у меня такой результат), в то время как пользователям для принятия решений нужен еще и ответ на вопрос почему нет (почему не другой), а иногда что сделать, чтобы результат изменился.

В работе говорится также о том, что пользователям нужно понимать, каковы границы применимости методов, какие у них есть ограничения и это нужно явно внедрять в предлагаемые инструменты. Более ярко эта проблема показана в статье Interpreting Interpretability: Understanding Data Scientists' Use of Interpretability Tools for Machine Learning. Авторы провели небольшой эксперимент со специалистами в области машинного обучения: показали им результаты работы нескольких популярных инструментов для интерпретации моделей машинного обучения и предложили ответить на вопросы, связанные с принятием решения на основе этих результатов. Оказалось, что даже специалисты слишком доверяют подобным моделям и не относятся к результатам критически. Как любой инструмент, объясняющие модели можно использовать неправильно. При разработке инструментария важно учитывать это, привлекая накопленные знания (или специалистов) в области человеко-компьютерного взаимодействия, чтобы учитывать особенности и потребности потенциальных пользователей.

Data Science, Notebooks, Visualization


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

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

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


Визуализация неопределенности одна из особенностей, которые отличают научную графику от презентационной и бизнес-визуализации. Довольно долго ключевым в последних считался принцип минималистичности и фокуса на основных трендах. Однако это приводит к чрезмерной уверенности пользователей в точечной оценке величины или прогноза, что может быть критичным, особенно, если мы должны сравнивать прогнозы с разной степенью неопределенности. Работа Uncertainty Displays Using Quantile Dotplots or CDFs Improve Transit Decision-Making анализирует, насколько способы визуализации неопределенности в предсказании для точечных графиков и кумулятивных функций распределения помогают пользователям принимать более рациональные решения на примере задачи оценки времени прибытия автобуса по данным мобильного приложения. Что особенно приятно, один из авторов поддерживает пакет ggdist для R с различными вариантами визуализации неопределенности.


Примеры визуализации неопределенности (https://mjskay.github.io/ggdist/)

Однако часто встречаются и задачи визуализации возможных альтернатив, например, для последовательностей действий пользователя в веб-аналитике или аналитике приложений. Работа Visualizing Uncertainty and Alternatives in Event Sequence Predictions анализирует, насколько графическое представление альтернатив на основе модели Time-Aware Recurrent Neural Network (TRNN) помогает экспертам принимать решения и доверять им.

Сравнение моделей


Не менее важный, чем визуализация неопределенности, аспект работы аналитиков сравнение того, как часто скрытый выбор исследователем разных подходов к моделированию на всех его этапах может вести к различным результатам анализа. В психологии и социальных науках набирает популярность предварительная регистрация дизайна исследования и четкое разделение эксплораторных и конфирматорных исследований. Однако в задачах, где исследование в большей степени основано на данных, альтернативой могут стать инструменты, позволяющие оценить скрытые риски анализа за счет сравнения моделей. Работа Increasing the Transparency of Research Papers with Explorable Multiverse Analyses предлагает использовать интерактивную визуализацию нескольких подходов к анализу в статьях. По сути, статья превращается в интерактивное приложение, где читатель может оценить, что изменится в результатах и выводах, если будет применен другой подход. Это кажется полезной идеей и для практической аналитики.

Работа с инструментами организации и анализа данных


Последний блок работ связан с исследованием того, как аналитики работают с системами, подобными Jupyter Notebooks, которые стали популярным инструментом организации анализа данных. Статья Exploration and Explanation in Computational Notebooks анализирует противоречия между исследовательскими и объясняющими целями, изучая найденные на Github интерактивные документы, а в Managing Messes in Computational Notebooks авторы анализируют, как эволюционируют заметки, части кода и визуализации в итеративном процессе работы аналитиков, и предлагают возможные дополнения в инструменты, чтобы поддерживать этот процесс. Наконец, уже на CHI 2020 основные проблемы аналитиков на всех этапах работы, от загрузки данных до передачи модели в продакшн, а также идеи по улучшению инструментов обобщены в статье Whats Wrong with Computational Notebooks? Pain Points, Needs, and Design Opportunities.


Преобразование структуры отчетов на основе логов выполнения (https://microsoft.github.io/gather/)

Подводя итог


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

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

Нужно ли дизайнеру интерфейсов понимать вёрстку?

13.02.2021 10:18:35 | Автор: admin

Вы верно поняли, тут речь пойдёт именно о тех людях, которые делают дизайн интерфейсов. Я порой вижу вопросы на тему: Нужно ли понимать дизайнеру вёрстку? и Почему вы делите дизайнеров на Ui, UX, итд?. В этой статье я отвечу на эти вопросы. Маленькая затравка для продолжения - да, эти два вопроса отвечают друг на друга. О том, кто такие дизайнеры интерфейсов, и что они делают в рамках разработки приложений, мы разбирали в прошлой статье.

UPD: Расшифровка того, кто такой Ui/Ux дизайнер по ссылке выше.

Нужно ли уметь верстать?

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

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

Что делать дизайнеру который не понимает вёрстку? - тут ответ очевиден Нужно разбираться в том, что ты делаешь. Это вопрос компетентности, и ответственности за свои решения, которые должны иметь твердое основание.

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

Почему делят дизайнеров на Ui, Ux, продуктовых, рекламных и так далее ?

Если вы читали ответ на предыдущий вопрос, то вы примерно уже догадываетесь о том, почему дизайнеры интерфейсов, это не тоже самое, что дизайнеры печатной продукции, и другие История IT такова, что постоянно нужно развиваться и учиться новому, без этого есть большой шанс стать неактуальным. На заре зарождения веб интерфейсов дизайном занимались люди, которые сайты разрабатывали, была даже такая профессия Веб мастер. Сейчас, если делать так, как делали в начале нулевых - то дизайнер рискует остаться не у дел. Веб мастера переквалифицировались в фронтендеров, с их большим зоопарком фреймворков, технологий по типу Blazor, и и много чего еще Сейчас веб разработчику, для успешной карьеры, мало знать лишь ванильный JS и JQuery. Так и выводим, что дизайнер, который разрабатывает интерфейсы, знает помимо обязательной для всех видов дизайнеров базы - Теории дизайна, цвета, композиции еще и технические детали в виде Системного подхода, верстки, принципов работы клиент-серверных приложений, принципов работы запросов и ответов, структуры JSON объектов. Справедливо будет уточнить, что не очень нужно знать всё это на уровне профессиональной разработки, а хотя бы на уровне базовых принципов и механизмов работы. Этим собственно и делятся дизайнеры между собой - дополнительными, отраслевыми навыками.

Выводы

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

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

Подробнее..

Перевод - recovery mode 41 термин в дизайне, полезный для UX-исследователя

05.09.2020 12:21:57 | Автор: admin


Работа с UX-дизайнерами и знакомство с их словарным запасом это почти изучение нового языка. Давайте посмотрим на 41 часто используемый дизайнерский термин. Для лучшего взаимопонимания в команде.



Flat Design (Плоский дизайн)


Flat Design это минималистский стиль дизайна пользовательского интерфейса. Он характеризуется фокусированием на использовании простых двухмерных элементов с яркими цветами.


Ник Бабич (Nick Babich) из UX Planet называет flat design более сложным кузеном минимализма, поскольку все элементы пользовательского интерфейса основаны на простоте.

Отличным примером плоского дизайна является целевая страница Dropbox Basic. Как видите, элементы пользовательского интерфейса настолько минимальны, что освещают содержание страницы.




Interaction Design (Интерактивный дизайн)


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




Material Design (Материальный дизайн)


Material Design, часто называемый просто материалом, это язык дизайна, разработанный Google и используемый на устройствах Android.


Вот краткое вводное видео об этом от Google:



Iterative Design (Итеративный дизайн)


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



Design sprints (Дизайн-спринты)


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



Brand Identity (Фирменный стиль)


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




Mood board (Доска настроения)


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


Доска настроения используется всеми дизайнерами, в том числе теми, кто занимается дизайном UX, графики, моды и т.д.



Storyboard (Раскадровка)


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



User Journey Maps / UX Flow / Flowchart


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



Есть ли различия между картами пути пользователя и потоками UX? Да.

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


В то время как UX-потоки имеют более формальные правила (вероятно, из-за их происхождения в виде блок-схем).



Wireframe (Каркас)


Думайте о каркасах как о проекте экрана. Они представляют собой низкокачественное представление макета и содержания веб-сайта.




Wireflow


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


Чуть больше про Wireflow
Wireflow это не скетч. Wireframe-ы специально никак не связаны с дизайном, чтобы демонстрировать как сайт/приложение будет работать, а не выглядеть. В wireframe все выглядит схематично, но за этими чертежами стоят многие часы раздумий. Каждый небольшой блок должен быть спланирован и расположен в нужном месте. Каждая ссылка должна куда-то вести. Каждая страница должна быть доступна по ссылке с другой страницы. Каждая кнопка должна быть там, где она нужна пользователю, и не быть там, где от нее нет толку. Лишь 10% создания wireframe-ов приходится на рисование; 90% занимает процесс продумывания.



Mockup (Макет)


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




MVP


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


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




Low and High-fidelity protos


Прототипы с низкой и высокой точностью


На ранних этапах вы можете создавать бумажные прототипы (с низкой точностью Low protos) карандашом и бумагой для проверки концепций или течений. Позже, после проверки алгоритмов и концепций, вы можете перейти на программное обеспечение для проектирования, такое как Sketch, для создания прототипа с высокой точностью (High-fidelity protos). Прототипы будут выглядеть не как каракули, а как приложения на вашем мобильном устройстве, и их можно будет использовать для точной настройки деталей вашего пользовательского интерфейса.




Adaptive design (Адаптивный дизайн)


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




Responsive design (Отзывчивый веб-дизайн)


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



Про разницу Адаптивного и Отзывчивого


Affordance (Ухватистость или провоцировательность)


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



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



Picker (Сборщик)


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




Bar (Панель навигации)



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


Панель вкладок (Tab bar) в различных приложениях устройства она отображается в нижней части экрана приложения и дает возможность быстро переключаться между различными разделами приложения.




UI Element


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



UI Pattern


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


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


Widget (Виджет)


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



Pixel (Пиксель)


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



Hierarchy (Иерархия)


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




Breadcrumbs (Хлебные крошки)


Хлебные крошки это вспомогательные средства навигации, которые сообщают пользователям, где они находятся на веб-сайте. Это позволяет пользователям повторять свои шаги на многоуровневых веб-сайтах. Несмотря на свой второстепенный статус, крошки используются с 1995 года, помогая сделать дизайн более удобным для пользователя.




API


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




Onboarding (Адаптация)


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



Lorem Ipsum (Текст рыба)


Также известное как фиктивная копия, lorem ipsum это общий текст-заполнитель, используемый, когда настоящий текст недоступен. Он используется в качестве текста-заполнителя, чтобы продемонстрировать, как будет выглядеть дизайн после того, как будет добавлен реальный основной текст.




Legibility (Разборчивость)


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




Microcopy (Микрофотокопия)


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



Grid System (Сетка)


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




Scale (Масштаб)


Масштаб характеризует изменение размера объекта при сохранении его формы и пропорций. Большой масштаб может создать драму, а маленький может создать мелкие детали.



Color Theory (Теория цвета)



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



Cool Colors (Холодные цвета)




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



Warm Colors (Теплые цвета)




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



Gradient (Градиент)


Как видно на двух картинках выше, это постепенное изменение цвета от одного тона к другому.



Opacity (Прозрачность)


Степень прозрачности элемента. Чем ниже непрозрачность, тем прозрачнее элемент.



Resolution (Разрешение)


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




Contrast (Контраст)


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




Saturation (Насыщенность)


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




Ну вот и все. Это были одни из самых распространенных терминов, с которыми вы могли столкнуться при работе с UI, UX или графическими дизайнерами.

Подробнее..

Дизайн-система что это, для чего и как создать

22.10.2020 12:07:47 | Автор: admin

Всем привет!

Я рад вернуться к вам, дорогие читатели сообщества, и поделиться опытом и знаниями, полученными благодаря работе в IT-компании Omega.

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

  • Что такое дизайн-система?

  • Для чего она нужна?

  • Как её создать?

Что такое дизайн-система?

Давайте разбираться по порядку. Дизайн-система представляет собой совокупность трех сущностей:

  1. Визуальный язык то, что мы видим.

  2. Framework библиотека визуального языка, его код.

  3. Guidelines правила, как должно все выглядеть и каким образом применяться.

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

Визуальный язык

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

  • Цвета

  • Шрифты

  • Пространство

  • Формы объектов

  • Иконки

  • Изображения

  • Взаимодействия

  • Анимации

  • UI-компоненты

  • Звуки

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

Какой образ приходит вам в голову, когда слышите или видите названия таких банков, как Альфа-Банк, ВТБ, Сбербанк, Тинькофф и других? Какие эмоции вы испытываете? Визуальный язык является одним из фактором того, каким мы запомним тот или иной продукт.

Framework

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

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

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

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

Guidelines

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

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

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

  • Что это за элемент?

  • Где он используется?

  • Какие задачи решает?

Также для UI-компонентов можно описывать анатомию: обозначьте структуру и все параметры, из которых они строятся.

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

Для чего нужна дизайн-система?

Как и для любого IT-продукта, важно ответить на вопрос: для чего нужна дизайн-система? Или, как говорят некоторые коллеги по цеху чтобы что?

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

Автоматизация

Автоматизация это самая очевидная ценность. Дизайн-система позволит автоматизировать процессы и выиграть время на другие задачи.

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

Итеративность

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

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

Консистентность

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

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

Синхронизация

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

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

Больше времени на UX

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

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

Скорость прототипирования

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

Недостатки дизайн-системы

Все вышеописанное можно отнести к плюсам дизайн-систем, но у них, конечно, есть минусы.

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

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

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

Как создать дизайн-систему?

Есть множество подходов для создания дизайн-системы. Я рекомендую рассмотреть атомарную систему, главным преимуществом которой является наследуемость. Пожалуй, тема атомарной дизайн системы может потянуть на отдельную статью. Про это можно почитать в переводе статьи Брэда Фроста (Brad Frost) Atomic Web Design.

Примеры того, как сделаны дизайн системы:

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

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

Спасибо за внимание!

Подробнее..

Как мы решаем проблему отсутствия UIUX дизайна в 1С с помощью Java Script и React.js

03.07.2020 02:04:06 | Автор: admin
image

Ранее уже писал о том, что в 1С UI\UX дизайна нет. Эта статья про то, как мы с помощью таких технологий, как Java Script, React.js и Google Firebase решили сделать web-сервис, который позволит с наименьшими трудозатратами, в сравнении с 1С: Конфигуратором и уже тем более 1C:EDT, прорабатывать UI и UX дизайн будущего приложения на 1С, корректировать его на лету и передавать в работу программисту уже согласованный прототип будущего бизнес-приложения.


Для начала, расскажу о наболевшем при реализации проектов на 1С, причем на столько, что бросили 1С и начали развивать web-технологии, но, как ни странно, для исправления ситуации в 1С.

ЧАСТЬ 1 проблематика. Решаемые задачи.
1.Инструменты бизнес-аналитиков, руководителей проектов, менеджеров по продажам.
Не смотря на развитие технических инструментов экосистемы 1С (выше писал про 1C:EDT и т.д.), остается крайне скудным инструментарий для тех специалистов, которые находятся на передовой в проектах разработки и внедрения: бизнес-аналитиков, консультантов, руководителей проектов, именно они, одними из первых встречаются с Заказчиком, собирают требования, интерпретируют услышанное, формализуют в виде ТЗ и иных проектных документов. Более того, столько продвинутых инструментов для формирования ТЗ, прототипирования, дизайна, как у программистов, front-office не имеет. Чтобы показать Клиенту то, что его ожидает в результате проекта (программирования) консультанты рисуют формы в Paint, MS Excel и других, не далеких от удобства инструментах. До сих пор нет и единого мнения, стандарта в инструментах формализации бизнес-процессов, кто-то применяет Business Studio, кто-то Visio, сам вендор 1С: СППР и т.д., не говоря уже про стандартную нотацию (IDF0, ARIS и т.д.).

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

3.Коммуникации и сложность восприятия. Online внедрения 1С.
Классика: Заказчик говорит одно, подразумевает другое, аналитик третье, а программист четвертое. В текущих реалиях на это дополнительно накладываются карантинные ограничения очных встреч, начинаются внедрения по удаленке.

4.UI и UX дизайн, проработка интерфейсов решений на 1С.
Уже не первый год в сообществе 1С произносятся и обсуждаются такие термины, как UI, UX, сейчас мы о них поговорим, а ещё поговорим и про CX.
User Experience (UX) пользовательский опыт. Цель UX-дизайнера сделать так, чтобы пользователь быстро и легко получил от программы то, зачем он её использует.
User Interface (UI) пользовательский интерфейс. Цель UI-дизайнера создать эстетичный дизайн интерфейса продукта.
Наиболее яркий пример UI и UX в быту (это не только ИТ-ые термины :-), когда UI хорошо, а вот UX нет:
image
Исправляем ситуацию и подтягиваем до высокого уровня UX:
image
Грань между UI и UX очень тонкая и порой её сложно отличить, но она есть.
А знаете ли Вы, что UI и UX напрямую влияют на CX?
CX (customer experience) клиентский опыт. Ваш продукт это лицо Вашей компании или личного бренда (репутации). Хорошо спроектированное, продуманное программное решение с красивым дизайном повышает лояльность (NPS) клиентов к Вашему бренду и компании.
В итоге, корреляция этих трех составляющих следующая:
image

5.Кадровый голод.
Так было, так есть и так будет всегда и не только в ИТ индустрии. Победить эту проблему мы не сможем, но минимизировать однозначно. При этом сообщество 1С нуждается не только в программистах, как ещё говорят технарях, но и бизнес-аналитиках, РП-ах, администраторах гуманитариях. Выше я сказал, что в смежных отраслях, таких как разработка сайтов и мобильных приложений есть такие специалисты (профессии), как UI\UX (не редко их совмещают в одном лице) дизайнеры, а в 1С отрасли UI\UX дизайнер это программист. Нужно привлечь в отрасль UI и UX дизайнеров, начать их выращивать, это даст тройной эффект:
1.Высвободит время программистов, переложит часть предварительной работы на дизайнеров.
2. Повысит качество конечного продукта, через более глубокую проработку удобства и эстетики интерфейса.
3. Расширит рынок специалистов, позволит привлечь в отрасль больше гуманитариев (дизайнеров, маркетологов, переводчиков и т.д.).

Итак, коротко перечислим решаемые проблемы:
1. Отсутствие простых и удобных инструментов для бизнес-аналитиков, консультантов, руководителей проектов. Более того, каждый в своей практике встречал таких менеджеров со стороны Заказчика, которые программировать не умели, но объяснить, нарисовать, что именно хотят, более чем могли, был бы адекватный для этого инструмент.
2. Увеличение сроков проекта, бюджета, снижение лояльности в результате многократных итераций сдачи работ, вызванных порой недопониманием, которое может быть снято на ранних стадиях проекта.
3. Коммуникации и сложность восприятия, усиливающиеся удаленной работой и все большего перехода в режим online работы и внедрений проектов на 1СВнешний вид и дизайн есть доклады
4. Удобство и качество интерфейсов, ежедневно повышающиеся требования заказчиков в более глубокой проработке UI\UX дизайна решений. Конкуренция со стороны Web продуктов. Сложности в коммуникациях и понимании друг друга
5. Кадровый голод.

Часть 2 применение web-технологий для популяризации 1С-технологий 1С. Решение обозначенных проблем.
В ходе осмысления и поиска решений обозначенных проблем были сформулированы требования к будущему продукту:
1. Инструмент должен быть простым, интуитивно понятным, позволяющим начинающим бизнес-аналитикам и консультантам в кратчайшие сроки освоить механизм прототипирования решений на 1С.
2. Online, не требующий установки и лицензий 1С предприятия, доступный широкой аудитории.
3. Простота и удобство работы над UI и UX дизайном, которое позволит спроектировать оптимальный интерфейс без привлечения программиста, на этапе сбора требований.
4. Возможность совместной работы исполнителя (бизнес-аналитика) и заказчика в online режиме с целью повышения качества коммуникации и снижения негативных факторов перехода на online режим работы и взаимодействия.
5. Еще по ходу добавилось требование мультиязычного интерфейса и возможность простого, автоматического перевода интерфейс на наиболее востребованные языки.

Обзор технологий

Frontend
В основе лежит Single Page Application подход и фреймворк React.
ru.reactjs.org
Для реализации UI конструктора форм возьмем Material UI.
material-ui.com/ru
Сетка для проектирования форм и реализации колонок будет взята тоже из
Material, но потребует настройки.
material-ui.com/ru/components/grid
Примеры реализации аналогичной идеи Drag&Drop создания макета из
элементов:
github.com/chriskitson/react-drag-drop-layout-builder
github.com/kiho/react-form-builder
github.com/saravananangu/react-drag-drop-form-builde

Backend
На первом этапе достаточно использовать serverless подход и взять Google Firebase за основу.
В дальнейшем начнем разработку собственного backend-приложения на Node.js.

Архитектура:
image

Что получилось в итоге, разберем по порядку функционал:
1. Online сервис, не требующий развертывания платформы, лицензий 1С, доступный всегда и везде.
image
2. Простой и понятный конструктор прототипирования форм 1С.
image
3. Возможность поделиться ссылкой даже с тему, у кого нет аккаунта.
ПРИМЕР

4. Online отображение изменений при редактировании форм: исполнитель вносит корректировки, заказчик по ссылке видит изменения online (страницу браузера обновлять не нужно).
image
5. Создание проектной документации (ТЗ, ТП) становится на много проще, а главное они выглядят более реалистично имеют деловой стиль и стандарт.
6. Приятной неожиданностью стало то, что web-технологии открыли новые возможности, которые не планировались, а именно автоматический online перевод текстов на любой язык.
image

Часть 3 заключение.
Мы надеемся, что 1CMaker позволит решить обозначенные проблемы, снизит порог вхождения в отрасль, позволит привлечь новые кадры и даже создаст новую компетенцию в 1С сообществе UI\UX дизайнер (1С: Дизайнер). Начало положено, но это только начало и мы планируем ещё много вкусного реализовать:
1. Выгрузка формы в XML формате.
2. Адаптировать интерфейс под мобильную платформу.
3. Выгрузка спроектированных форм с описанием в формате MS Word шаблон технического задания.
4. Задач на разработку и оценка трудозатрат.
5. Связи между объектами и т.д. и т.п.

Спасибо, что дочитали до конца, удачных Вам проектов и помните: Красота спасет мир (Ф.М.Достоевский)!
Подробнее..

Онлайн-хакатон Tele2 Solutions Days

12.08.2020 16:20:14 | Автор: admin
Привет, Хабр!

21-23 сентября, мы совместно с Tele2 и Лигой Цифровой Экономики проводим хакатон, с целью поиска современных неожиданных технологических решений.

image

К участию приглашаются разработчики (frontend и backend), дизайнеры, UI/UX-дизайнеры, Product Owner/Product Manager, а также все заинтересованные в современных технологиях.

Участников ждут специальные номинации:

AR для розницы/программы лояльности;
Разработка альтернативной версии маркета Tele2;
Редизайн тариф-конструктора;
Виджеты iOS 14 и приложения для часов;
Идеи и прототипы многопользовательской игры.

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

До встречи!
Подробнее..

Recovery mode UXUI-ДИЗАЙН нельзя просто взять и нарисовать экран

25.06.2020 08:15:05 | Автор: admin
Меня зовут Вадим Рожнов, я работаю в команде, которая разрабатывает мобильное приложение сети АЗС Газпромнефть, где можно заправляться, смотреть акции или бонусную программу. Я UX/UI-дизайнер. Делаю так, чтобы клиенту было удобно, понятно и легко пользоваться нашим мобильным приложением с ежемесячной миллионной аудиторией.




Источник

Для кого: новичков в UX/UI-дизайне
Текст подготовил журналист Иван Сурвилло
Чтение займет: 15 минут



Как пошел в дизайнеры


Я дизайнер уже семь лет. Никакого специального образования нет, всему сам научился. До Петербурга жил в Бердске, маленький такой город рядом с Новосибирском.

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

Как был бизнесменом


Начал бизнес еще в колледже лет в 17. У меня был друг, которому родители подарили зеркалку. Я ему предложил: Денис, в колледже много девчонок, давай их фоткать, обрабатывать в фотошопе, потом им же продавать. Сделаем бизнес, фотостудию откроем... Никакие бизнес-планы не продумывали, такие мамкины бизнесмены. Попробовали фотографировать, вроде получилось. Начали с фотошопом разбираться, просто в Интернете находили уроки. Друг быстро охладел, а мне стало интересно, начал изучать фотошоп. Это было прозрением: я понял, что уже есть достаточно ресурсов, переведенных на русский. Заработали мы, кстати, не очень много. В самый лучший день, наверное, полторы тысячи рублей.

Потом работал в мебельном магазине продавцом-консультантом. Это было странно. Мне было 19 лет, а продавал я антикварные диваны в стиле ампир. Около года проработал, учитывая то, что у нас зарплата складывалась от процента. Считаю, что получалось довольно неплохо для того возраста, учитывая, что приходили те, кому за 40 и довольно обеспеченные.

Вообще, чтобы продать что-то, надо установить контакт, но ненавязчиво. Это просто интуиция: ты понимаешь, что сейчас человек готов с тобой общаться, и нужно именно сейчас вступать в диалог. Еще нужно не болтать много и штампами не разговаривать, чтобы ты не звучал, как говорящий рекламный буклет. Но если хочешь стать хорошим продажником, теория не очень нужна. Просто иди и продавай, но анализируй. Всегда.
СЛУЧИЛСЯ КАКОЙ-ТО УСПЕХ ПОДУМАЙ, ПОЧЕМУ ОН СЛУЧИЛСЯ. ЕСЛИ, НАОБОРОТ, НЕ СЛУЧИЛСЯ, ТО ПОДУМАЙ, ИЗ-ЗА ЧЕГО. И ТАК В ЛЮБОМ ДЕЛЕ

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

Потом устроился в типографию дизайнером: фотки обрабатывал, рекламные вывески и баннеры. Еще работал дизайнером на шоколадной фабрике, делал обертки конфет и рекламные материалы для выставок. Обычно на планерке мне говорили, что будут запускать набор ассорти конфет: Вадим, вот нам нужно, чтобы упаковка прям была яркая, вкусная, насыщенная! Дальше я смотрел референсы, как у конкурентов сделано, как у зарубежных, просто современные тенденции и потихонечку собирал макет.
МАКЕТ, ВООБЩЕ, РОЖДАЕТСЯ ИЗ НАСМОТРЕННОСТИ, ИЗ ВКУСА И ПОНИМАНИЯ, ЧТО ХОЧЕТ ЗАКАЗЧИК

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

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

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

Через несколько месяцев ушел в аутсорс-компанию, где платили больше. Здесь я уже ощущал себя уверенным профессионалом. Появился опыт работы с иностранными заказчиками. Делали сервис для ребят из Великобритании, у которых было 30 отелей, и они хотели сделать систему, которая позволит гостям забронировать конференц-комнаты в них. И мы с нуля делали мобильное приложение, веб-сервис и сервис бронирования для администраторов отелей.
МНОГИЕ МОИ ЗНАКОМЕ ДУМАЮТ, ЧТО ДИЗАЙН ЭТО РИСОВАНИЕ ЛОГОТИПОВ. НА САМОМ ДЕЛЕ ЭТО БОЛЬШЕ ПРО МШЛЕНИЕ И ВЗАИМОДЕЙСТВИЕ. НУЖНО, ЧТОБ БЛО И ГЛАЗУ ПРИЯТНО, И МОЗГУ ПОНЯТНО

Самый необычный заказчик, которого помню, ассенизатор с автопарком. Он хотел приложение вроде Яндекс.Такси: можно заказать машину, указать объем и оплатить онлайн. Клевая тема, у него бы это стрельнуло, потому что он монополистом был. Реально удобно: у человека есть коттедж, ему надо очистить туалет взял смартфон, указал, сколько, когда приехать, оплатил онлайн. Дальше идеи проект не пошел, а жаль.

О переезде в Петербург


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



О специфике UX/UI-дизайна


По трудовой я дизайнер, но на самом деле я UX/UI-дизайнер.

UX-дизайн про удобство, про логику, про продумывание клиентского пути: на этом экране будет это, тот экран поведет сюда, на нем будет это. В итоге пользователь придет к финальному действию, которое предполагала задача.

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

Например, надо сделать, чтобы пользователь мог активировать промокод. Я начинаю, как UX-дизайнер, выяснять, что за промокод, у каких он будет пользователей, можно ли любому или только зарегистрированному пользователю использовать промокод. Потом обсуждаю с разработчиками, как это будет работать на бэке; что будет на фронте; что будет на серверной части; что будет на части мобильного приложения; что думают пользователи, когда нажимают кнопки на телефоне Когда с этим все ясно, начинается отрисовка: плашечки, шрифты, кнопки Это уже UI.
ОСНОВНОЕ ОТЛИЧИЕ UX/UI-ДИЗАЙНЕРА ОТ ГРАФИЧЕСКИХ ДИЗАЙНЕРОВ КАК РАЗ ЛОГИЧЕСКАЯ ЧАСТЬ. У МЕНЯ ОЧЕНЬ МНОГО ПРОДУМВАТЕЛЬНОЙ РАБОТ, ЧТОБ КЛИЕНТСКИЙ ПУТЬ БЛ МАКСИМАЛЬНО ЛЕГКИЙ

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

О работе и гордости за нее


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

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

Я не один участвую в создании дизайна. Все, что нарисую, проходит через два фильтра: команду и пользователей. Обычно за завтраком смотрю чатик с отзывами пользователей. В день просматриваю примерно по 50100 отзывов.
АУДИТОРИЯ БСТРО ОТКЛИКАЕТСЯ: ЕСЛИ Т ЧТО-ТО СДЕЛАЛ НЕ ТАК, ТО ТЕБЕ СРАЗУ ОБЪЯСНЯТ, ГДЕ Т НЕ ПРАВ. А ЕСЛИ СДЕЛАЛ ПРИКОЛЬНО, ТО ТОЖЕ БСТРО ОТЗВАЮТСЯ

Отзывы очень полезны, потому что, когда долгое время с приложениями работаешь, появляется насмотренность. Если ты чувствуешь в процессе разработки дизайна, что есть момент, где тебе кажется, что пользователь затупит, он 100% затупит на этом месте. Потому что реальные юзеры очень быстро взаимодействуют с приложением. Плюс у нашего приложения довольно консервативная аудитория, для которой нужно стараться делать проще, понятнее. Лучше где-то добавить лишний шаг с объяснением или, наоборот, очистить экран от второстепенной информации. За годы работы понял очевидное, но важное: любой экран несет на себе функцию. Он должен быть для чего-то нужен. Нельзя просто взять и нарисовать экран. Надо в голове держать, зачем он, для чего, что здесь нужно будет показать, что на нем главное, какая мысль.

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

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

О повседневной работе


Работа у нас двухнедельными спринтами. Есть некий пул задач, утром включил компьютер, посмотрел почту, открыл джиру с задачами и начал потихоньку делать. В 12 часов созвон: говорим, что мы сделали вчера и что планируем сделать сегодня. Если есть какие-то вопросы, остаемся после общего созвона и обсуждаем. Не сказать, что это прямо рутина, потому что можно переключаться с UX на продумывание интерфейсов или клиентских путей, можно переключаться на задачу нарисовать баннер про шестой кофе в подарок, то есть на что-то чуть более творческое.

Главный кайф в работе когда что-то получается. Это подтверждение, что ты все делаешь правильно. Можно сравнить с тем, как ты головоломку собираешь: так попробовал, так попробовал, потом подумал чик, она собралась. В этот момент тебе классно.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru