Как стать автором
Обновить
10
Карма
0
Рейтинг
Илона Саркисова @ilona_sarkisova

Senior Experience Designer

Визуализация данных в интерфейсе

Вопросы к возможностям оформления текста на Habr, но вы можете предложить свой вариант :)

Эстимирование дизайна

Единственное место, где используется слово "таск" — ваш комментарий :)

Эстимирование дизайна

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

Эстимирование дизайна

Здравствуйте! Я использую общепринятый термин, который встречается в большинстве русскоязычных источников об Agile. Но действительно стоит дать такое пояснение, благодарю!

Эстимирование дизайна

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

Тупые и умные компоненты

Дело не в инструментах, а в подходах и командной работе.
Если дизайнер будет выдавать макеты и библиотеки элементов как ему удобно, то разработчик будет тратить время на их обработку.
Но я глубоко убеждена что одна из задач дизайнера — поддержка разработчиков. У них итак дел хватает.
Мы можем работать в команде: дизайнеры могут выдавать дизайн-библиотеки так, чтобы разработчики не тратили время на их расшифровку и преобразование в удобную им форму. Один из способов — деление компонентов на умные и тупенькие))
Ну и да, в статье речь не про то, что дизайнеры разрабатывают компоненты. Они их описывают в UI-ките.

Тупые и умные компоненты

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

Тупые и умные компоненты

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

Тупые и умные компоненты

Абсолютно согласна, от проекта и от того насколько атомарны компоненты. Атомарность это ещё одна большая и болезненная тема дизайна и разработки интерфейсов в принципе.

Тупые и умные компоненты

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

Тупые и умные компоненты

Да, буквально там так и написано)) дизайнеры редко используют этот подход, к сожалению

Тупые и умные компоненты

Feel free Можете использовать любое удобное название))

Тупые и умные компоненты

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


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

Информация

В рейтинге
5,856-я
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Работает в
Зарегистрирована
Активность