Smashing Podcast Episode 9 со Стефани Уолтер: как я могу работать с UI-фреймворками?

Мне, как разработчику, нравится то, что фреймворки пользовательского интерфейса часто поставляются со стилями по умолчанию, но должны ли мы полагаться на это в проектах? Просто использовать стиль по умолчанию и верить, что тот, кто создал фреймворк, проделал действительно хорошую работу по разработке этих компонентов? Присоединяйтесь ко мне в сегодняшнем эпизоде ​​подкаста, где я говорю с UX-дизайнером Стефани Уолтер о вещах, которые мы должны учитывать при создании UI-фреймворка.

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

• сайт Стефани
• Стефани в Твиттере

Еженедельное обновление

• «Как создать игру на сопоставление карт с использованием Angular и RxJS» , Анна Прензел
• «Как создать безголовый сайт WordPress на JAMstack» , Сара Драснер
• «Волшебные флип-карты: решение общей проблемы с размером» , Дэн Холлидей
• «Основные моменты Django: пользовательские модели и аутентификация (часть 1)» , Филип Кили
• «Как создавать карты с помощью React и Leaflet» , Шаджиа Абиди

Стенограмма

Дрю Маклеллан: Она дизайнер, ориентированный на пользователя, и эксперт по мобильному опыту, который объединил восхитительные продукты и интерфейсы с особым акцентом на производительность. Она работала над проектами для таких клиентов, как Люксембургский университет, Европейский инвестиционный банк, BMW и Microsoft, и она помогает этим клиентам представлять успешные проекты своей аудитории на всем пути от стратегии до конечного продукта. Она эксперт Google Developer в области дизайна продуктов и страстный преподаватель, делящийся своими знаниями в многочисленных сообщениях в блогах, статьях, семинарах и презентациях на конференциях. Итак, мы знаем, что она опытный дизайнер пользовательского опыта, но знаете ли вы, что когда-то у нее была работа по подгонке ковров у сэра Элтона Джона? Мои друзья из Smashing, пожалуйста, поприветствуйте Стефани Уолтер. Привет Стефани, как дела?

Стефани Уолтер: Привет, я в восторге, и мне понравилось вступление.

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

Стефани: Да, это то, что я часто видела, особенно в последние несколько лет, потому что я начала работать с агентством, а теперь работаю в компании. Итак, в этих супер-больших командах ИТ-технологий, и да, на данный момент есть много интерфейсов фреймворка, таких как тот, который я видел больше всего, это Material-UI, в основном Material Design — это своего рода рекомендации Google по дизайну и тому подобное, и Material -UI — это команда из Angular, а также команда из React. Они создали свою собственную структуру, используя внешний вид Material Design от Google. Но это больше не имеет ничего общего с Google. Это так же, как они, я не знаю, я думаю, им понравился внешний вид. Итак, на данный момент это два основных UI-фреймворка, с которыми я работаю. А еще есть кое-что под названием Ant Design, которое стало довольно популярным.

Стефани: Это фреймворк React. Я не знаю, есть ли у них Angular. Я думаю, что это было сделано командой в Китае. И это интересно, потому что он не только предоставляет компоненты, все в React, но если вы зайдете на их веб-сайт, вы также получите файлы с нуля, что на самом деле довольно интересно, потому что это как бы мотивирует или помогает дизайнеру создавать или формировать интерфейс в компоненты пользовательского интерфейса, используемые этой структурой. Так что да, это то, что я часто видел, особенно в крупных ИТ-командах, потому что в большинстве случаев у них нет дизайнера. На данный момент я в основном UX-команда из небольшой команды в европейском инвестиционном банке. Итак, это я как UX-дизайнер. Я работаю с командой разработчиков, бизнес-аналитиков, всех хороших людей, но все равно один дизайнер на весь проект.

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

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

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

Стефани: Я на это надеюсь. Я надеюсь на это, потому что иначе я создаю непригодные для использования интерфейсы. Так что этот ответ полностью предвзят, но да, я думаю, что это так, но это также зависит от уровня компромисса, на который вы готовы пойти, и есть компромиссы с обеих сторон. На данный момент я, например, компрометирую множество кнопок, потому что у вас есть несколько очень специфических кнопок в Material-UI, и мне не очень нравится волновой эффект на кнопке. Я думаю, что это отлично работает на мобильных устройствах, потому что на мобильных устройствах вам нужна своего рода большая обратная связь, когда пользователь нажимает или касается кнопки. Но тогда шаги — это своего рода эффект ряби, который идет по всей кнопке. Это немного перебор, особенно когда много кнопок. Но все же мы собираемся сохранить этот волновой эффект, потому что было бы очень сложно удалить его, потому что он был встроен во фреймворк React. И еще один эффект при наведении на эту кнопку, что-то более тонкое, что не будет здесь таким свистящим. Это было бы суперсложно.

Стефани: Вот такие компромиссы вы делаете. Но в то же время я не иду на компромисс в отношении конкретных вещей, таких как пользовательские компоненты. Там, где я работал раньше, нынешний клиент туристической и авиационной компании. И у авиакомпании есть очень, очень специфические потребности. Например, календарь для авиакомпании, вы хотите указать цены, вы хотите указать… если вы не едете в этот пункт назначения в конкретную дату, вы не знаете, когда это указать, у вас есть этот вылет и прибытие и базовый календарь большинства этих фреймворков пользовательского интерфейса не предоставляет таких вещей. Так что в какой-то момент вы можете сказать: «Хорошо, мы просто воспользуемся тем календарем, который у них есть». Вот и все. Вам нужно выйти за пределы этого. Итак, большинство компромиссов в основном основаны на том, используем ли мы базовый компонент? Создадим ли мы индивидуальный, который будет соответствовать потребностям пользователя? Или мы делаем смесь из двух? В случае с календарем, например, мы используем сетку календаря, поэтому мы используем базовый компонент, а затем дополняем его настройкой. Так что для этого потребовалось много разработки React.

Стефани: И да, обычно вы идете на множество компромиссов.

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

Стефани: Обычно. Да.

Дрю: Эта настройка выходит за рамки темы?

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

Стефани: Вы немного выходите за рамки этого. Вам нужен фон с затемнением. Вам нужно активировать его по клику, в то время как обычно ваша карта уже находится в интерфейсе. Итак, мы используем этот компонент карты, потому что в нем есть много вещей, которые нам нужны, например, фон, заголовок и заголовок вверху, несколько кнопок внизу. Итак, у нас есть структура, а затем мы немного ее подправляем. Но иногда у нас возникают конфликты по поводу семантики, в том числе и HTML. Потому что, например, я хотел, чтобы кнопки не имели формы кнопок, так же, как кнопка со ссылкой, и разработчик сказал: «Хорошо, поэтому мы используем ссылку, подобную вашей ссылке href». Я сказал: «Нет, это не ссылка. Это кнопка. Когда они нажимают на нее, она не открывает новую страницу. Он очищает все, что находится в форме».

Стефани: Технически, с семантической точки зрения, это должна быть кнопка. "Да. Но его нет в рамках». Я говорю: «Ну хорошо, я знаю, что нам делать?» Итак, обычно вы начинаете обсуждать эти мелочи, и, поскольку я действительно раздражаю своих разработчиков доступностью, это еще один дополнительный уровень попытки убедиться, что у нас есть основные компоненты, с которыми они хорошо работают. Но также то, что они семантически похожи, я не хочу иметь кнопки с картинками внутри картинок внутри картинок. Иначе у нас будут проблемы в конце.

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

Стефани: Да.

Дрю: Это честно?

Стефани: Ты должен. Тебе следует. Так что да, обычно у вас могут быть все компоненты, которые вы хотите. Вам все еще нужно знать, что нужно вашим пользователям на страницах, как они будут перемещаться? Вам нужно построить поток. Так что обычно, даже прежде чем выбрать фреймворк, мы обращаемся к нашим пользователям, разговариваем с ними, пытаемся понять их потребности. Так что на данный момент мне очень повезло, потому что пользователи находятся внутри банка. Поэтому мы проводим с ними много семинаров, и вы должны представить, что это суперсложный интерфейс. Мы переходим от чего-то, что было создано, я не знаю, я думаю, 10 или даже 15 лет назад, к чему-то совершенно новому, блестящему, с использованием Material-UI React. Так что это довольно большое изменение, и вы должны понимать, что в течение этих 15 лет каждый, кто хотел что-то, мог обратиться в поддержку, а затем попросить ИТ-команду реализовать это. Итак, на данный момент мой интерфейс представляет собой около 400 страниц с таблицами, внутри таблиц, внутри таблиц, с другими таблицами и прочим, чего даже не должно быть в таблицах.

Стефани: Например, у нас есть много вещей, которые являются просто ключевой ценностью, ключевой ценностью, ключевой ценностью. Поэтому они строят таблицу с двумя столбцами. Я такой: «Нет, может быть, мы можем сделать что-то лучше с этим». Итак, на данный момент мы занимаемся исследованием пользователей, чтобы понять различные цели пользователей. Итак, мы определили, что то, что они делают с интерфейсом, преследует определенные цели планирования. Им нужно планировать свою работу. Итак, я хочу знать, что эта операция будет проходить на этой встрече, поэтому мне нужно, чтобы это было в этом расписании, и все такое. Они хотят следить за чем-то, они хотят сообщать данные. Таким образом, мониторинг — это то же самое, что просмотр данных и проверка того, что все в порядке. Отчетность — это возможность использовать данные, делать с ними что-то, чем они хотят поделиться, и как бы сотрудничать с коллегами, и все это мы обнаружили, обсуждая напрямую с пользователями.

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

Стефани: И затем, возможно, некоторые таблицы можно было бы отображать как визуализацию данных, а затем для этого вам нужно понимать весь бизнес, чтобы данные имели смысл. Итак, если у вас есть хороший фреймворк, и вы говорите: «Хорошо, давайте использовать эту диаграмму… Я думаю, это называется JS-фреймворк для диаграмм». У вас есть много вещей, у вас могут быть гистограммы, круговые диаграммы, графики и все такое, но в какой-то момент вам все равно понадобится дизайнер, который поможет вам принять решение. Итак, есть ли смысл в этих данных, если мы покажем их в виде графика, или лучше показать их в виде круговой диаграммы, потому что мы хотим показать часть целого, или мы хотим сравнить эволюцию для одной страны за последние 10 лет? лет, то гистограмма более интересна. Таким образом, в зависимости от того, что пользователь хочет сделать с данными, вы будете отображать их совершенно по-другому.

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

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

Стефани: Да, на самом деле, мы делали это часто, и это очень приятно, потому что тогда вы не разрабатываете что-то, пока не узнаете, что это будет полезно и удобно. Так что это зависит. Если на самом деле быстрее разработать вещь, потому что у них уже есть большинство компонентов, то я обычно делаю очень быстрое бумажное прототипирование, а затем мы разрабатываем вещь, потому что это быстро, даже без данных. Если это что-то сложное, что-то очень-очень новое, на разработку которого уйдет много времени, тогда мы говорим: «Хорошо, мы проектируем несколько экранов и проводим тестирование прямо на экране». Итак, у нас есть инструмент под названием InVision, где вы размещаете весь свой дизайн и можете создавать связи между различными частями. Дело в том, что это также зависит от того, что вы хотите протестировать. Например, если вы хотите протестировать телефоны, это кошмар для тестирования их в InVision, потому что люди не могут их по-настоящему почувствовать, особенно, например, на мобильном телефоне.

Стефани: Значит, всегда нужно быть умным. Какой самый быстрый и дешевый способ? Быстрее и дешевле тестировать только конструкции. Этого достаточно? Для форм, как правило, не совсем потому, что у вас есть автоматическое завершение всей тяжелой работы, которую вы помещаете во внешний интерфейс, который на самом деле заставляет пользователя заполнять форму, поэтому для форм, возможно, более эффективно создать форму и протестировать ее. Но для новых вещей, да, мы делаем много дизайнов. Идем к пользователям. Так что на данный момент мы либо занимаемся один на один, но мои пользователи очень занятые люди. Это европейский инвестиционный банк, поэтому у них не так много времени. Итак, что мы обычно делаем, так это то, что если мы встречаемся с пользователями один на один, мы проводим небольшие встречи, больше похожие на фокус-группы. И это также интересно, потому что иногда у вас возникает своего рода противостояние. Некоторые люди говорят: «Да, я думаю, что это работает для меня, потому что я работаю так и так», а затем найдутся другие люди, которые будут такие: «О, ты работаешь так? На самом деле нет, я делаю так и так».

Стефани: Так что также интересно собрать несколько человек в комнате и просто послушать разговор, сделать заметки и сказать: «О, может быть, тогда мы могли бы сделать это» и «Этот компонент был бы лучше, основываясь на том, что я только что слышал." И тому подобные вещи.

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

Стефани: Вы должны знать, кем они будут, иначе это сделает работу маркетологов еще до создания продукта. Но да, мы провели партизанское пользовательское тестирование, например. Например, вы все еще можете использовать InVision. Таким образом, вы можете создать несколько прототипов в InVision, а затем привлечь пользователей, например, через социальные сети. Я работал на продукт, который помогал, как это называется, механикам автосалонов, которые ремонтировали вещи, а затем также информировали клиента о дополнительном ремонте и тому подобном. Так что у нас уже было растущее сообщество в LinkedIn и Facebook. Итак, что вы можете сделать, так это нанять этих людей. Вы можете проводить удаленное тестирование, как если бы мы разговаривали в таком инструменте, как онлайн-инструмент. Вы можете сделать некоторые демонстрации экрана. Мы сделали это и для какого-то проекта.

Стефани: Я бы дала вам один совет: сначала протестируйте инструмент, потому что я использовала его, он назывался «appear.in». Но я думаю, что они изменили имя на Whereby или что-то в этом роде, но это действительно в браузере, который я сказал, хорошо, это хорошо, потому что тогда пользователям не нужно ничего устанавливать, но пользователи не были на реальном компьютере. Они были в виртуальной машине, в Citrix, и у них не было микрофонов, так что в итоге мы сделали то, что они использовали мой инструмент, чтобы поделиться экраном. Они нажимали на прототип, и в то же время я вел их по телефону, как по стационарному телефону, чтобы поговорить с ними напрямую. Так всегда, это было довольно дешево, потому что это был замечательный день рекрутинга, я думаю, у нас было 10 пользователей или что-то в этом роде. Да, вы можете сделать много вещей, даже если вы не можете встретиться лицом к лицу, я провел много тестов удобства использования непосредственно в Skype или подобных вещах. Так что всегда есть несколько дешевых способов сделать это.

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

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

Стефани: Но очень сложно сказать: «Да, возьмите эту структуру, у нас есть все необходимые компоненты». Или типа: «Не ходите, если у вас нет приблизительного представления о том, каким будет ваш контент, какая навигация». Поэтому я думаю, что перед выбором фреймворка у вас все равно должен быть глобальный обзор, если вы не уверены на 100%, что у вас есть все компоненты. Но у меня есть ощущение, что большую часть времени выбор фреймворка в основном основан на том, какие технологии нравятся разработчику в данный момент, был ли у них опыт работы с фреймворком до этого? Мы использовали Ant в некоторых проектах только потому, что у нескольких разработчиков был опыт работы с ним, и им это очень нравилось, и они довольно эффективно использовали Ant. То же самое и с пользовательским интерфейсом Material React. Это как потому, что разработчик уже использовал его в предыдущих проектах, поэтому они с ним эффективны.

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

Стефани: Да. У меня есть особое требование к какому-то проекту, а именно… Я нахожусь в Люксембурге, у нас есть много европейских институтов и тому подобного, поэтому у нас есть дополнительные требования доступности для некоторых из них. И обычно, когда был определен фреймворк, они особо не проверяли доступность своего фреймворка, а затем возвращались через несколько месяцев после начала проекта и говорили: «О, только что сказали нам, что есть этот новый закон, и мы должны быть доступным, но мы не знаем, как это сделать». Типа да, уже немного поздно. Так что для меня, чтобы выбрать фреймворк, вам действительно нужно знать все ограничения в начале проекта, и если доступность является одним из них, вам нужно протестировать свои компоненты и убедиться, что они будут доступны. Но я не разработчик React или Angular, но я уверен, что очень сложно превратить недоступный UI-фреймворк во что-то доступное. Я предполагаю, что может быть немного сложно перестроить все компоненты, и тому подобное.

Дрю: Если вы обнаружите, что работаете над проектом, в котором этот процесс еще не состоялся, а инфраструктура пользовательского интерфейса уже выбрана, существует ли опасность того, что на пользовательский интерфейс могут начать влиять компоненты, которые уже существуют в этой инфраструктуре, а не руководствуясь потребностями пользователя?

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

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

Стефани: Больше всего меня расстраивает, когда я знаю, что мы используем компонент исправления обрезки, а мне говорят: «О нет, не волнуйтесь». Мы исправим это позже. И я знал, что последнее, к сожалению, может никогда не случиться. Так что зависит от команды. Но через какое-то время у вас есть опыт, и вы знаете, придет ли это потом или нет? Да, речь идет о компромиссах. Когда вы работаете с такими инструментами.

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

Стефани: Я думаю, это действительно зависит. Например, проблема с Material-UI заключается в том, что внешний вид вашего веб-приложения будет в основном соответствовать настроенным продуктам Google. Так что, если вы на самом деле не измените шрифт, не измените несколько цветов и не привнесете своего собственного фирменного стиля и не сделаете этого, у вас будет продукт, который будет выглядеть как любой продукт Google, что может быть хорошо, потому что если ваши пользователи привыкли к продуктам Google, это может помочь им понять их. Обычно, если у вас нет дизайнера в команде, есть ли у вас выбор? Как и многие другие работы, которые я видел, они поставляются с пользовательскими темами, поэтому, по крайней мере, вы можете изменить цвета. Я думаю, что вы также можете легко изменить шрифты. Но опять же, например, если вы меняете цвета, а вы не очень хороши в дизайне или даже доступности, возможно, цвета, которые вы будете использовать, будут конфликтовать, у них могут быть проблемы с контрастом.

Стефани: Например, я люблю оранжевый, но это один из самых раздражающих цветов для работы, потому что, например, настоящий доступный оранжевый цвет в виде кнопки с белым текстом выглядит почти коричневатым. И если вы хотите, чтобы этот действительно блестящий оранжевый цвет, вам нужен темный текст поверх него, чтобы сделать его читабельным, но это делает ваш интерфейс похожим на Хэллоуин в конце дня. Да, я вижу, ты смеешься. Но это правда. Так что всегда речь идет о такого рода компромиссах и говорите, что если вы разработчик и хотите использовать фреймворк как есть, и у вас нет дизайнера, я думаю, что это все же лучше, чем ничего не иметь и создавать его с нуля и тогда это супер сложно использовать. Но дело в том, что то, что у вас есть компоненты, не означает, что вы создадите отличный интерфейс. Это как кубики Лего. Если у вас есть кубики Lego, все в порядке, но вы можете сделать действительно хороший космический корабль или сделать что-то, что не держится вместе и развалится, потому что у вас не было плана.

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

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

Дрю: Итак, если вас как дизайнера попросят изменить стиль некоторых компонентов, вы бы просто попытались изменить стиль всего? Вы бы настроили все это или есть определенные области, на которых вы бы сосредоточились?

Стефани: Цвета. Я думаю, поскольку это первое, что вы видите, цвета действительно могут придать вам индивидуальность. Если у вас есть сильная идентичность бренда, по крайней мере, наличие цветов вашего продукта на кнопках или значках и тому подобное уже помогает вам настроить структуру. Шрифты, потому что я думаю, что это легко, если структура хорошо построена, обычно вы меняете все семейство шрифтов где-то, а затем оно должно как бы каскадироваться на остальной части сайта. Итак, цвета и шрифты — это два простых способа быстро настроить фреймворк. Иконки — еще один хороший способ придать индивидуальность, но это может быть сложно, потому что из того, что я видел, большая часть фреймворка поставляется с пользовательскими иконками или Font Awesome или уже встроенной библиотекой. Поэтому, чтобы заменить их, сначала вам понадобится много значков, если вы хотите заменить их все. Так что это может быть немного сложно. Я также видел фреймворки, которые позволяют вам выбирать, какой пакет значков вы хотите использовать. как Font Awesome, Glyphicons и некоторые другие. Так что это то, что вы можете легко настроить.

Стефани: И затем это касается внешнего вида, например, заголовка, обычно у вас есть разные типы верхних и нижних колонтитулов. Как вы ориентируетесь в таких вещах. Таким образом, уже есть много небольших настроек, которые вы можете внести, чтобы он не выглядел как Material-UI, он больше был похож на ваш бренд, а затем вы можете поиграть, например, с радиусом границы. Хотите ли вы полностью закругленные кнопки, или вам нужны квадратные кнопки, или вы хотите что-то посередине, например, тени. Итак, некоторые мелочи, которые обычно легко настроить, потому что большинство этих фреймворков имеют их в переменных CSS. Это те мелочи, которые вы можете настроить без особых усилий, за исключением этих волновых эффектов. Я ненавижу это. Я собираюсь бороться с этим. Я как бы надеюсь, что они изменят это в конце концов.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. Вы знаете?

Drew: Yup.

Stephanie: It does. Хорошо. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.