Что такое ресерч в дизайне
Design research & research in design
Для тех, кто читал второй номер журнала, посвященный вопросам креативных разработок, этот выпуск станет логичным продолжением темы. Действительно, если родилась оригинальная идея, имеет смысл проверить её на прочность. И дизайн-исследования в этом – лучший помощник. Авторы проекта предлагают читателям заглянуть в неизвестный, загадочный и очень интересный мир различных цифр, методик, опросов, прототипов, этапа «fuzzy front end». Ведь без них невозможно правильно выбрать путь для своей идеи, создать грамотную дизайн-стратегию, получить продукт (услугу), действительно нужный людям.
Само понятие «исследования» большинство людей вводит в священный трепет, поскольку его территория всегда загадочна и неизвестна. А если речь идет об исследованиях в дизайне, то среднестатистическое сознание просто отказывается совмещать эти два понятия – дизайн и исследования. Тем не менее, в России уже больше 10 лет существует успешная дизайн-консалтинговая компания «SmirnovDesign», на практике успешно синтерзирующая творчество и точную науку. Сергей Смирнов, успешный дизайнер и основатель компании, стал героем этого выпуска. Из интервью с ним читатели узнают не только о том, почему исследования стали одним из сервисов компании, какими методиками пользуются дизайнеры и какими навыками они обладают. Сергей делиться своими взглядами на жизнь, на перспективы развития дизайна в России, дает советы начинающим дизайн-исследователям.
Одним из основных объектов исследований в дизайне являются тренды. Нельзя создавать новые продукты и сервисы в отрыве от реальности, от того, что ждет мир и людей в ближней и дальней перспективе. Эд Коттон, директор по стратегическому развитию компании BSSP, эксперт в области брендинга, размышляет о том, зачем компаниям нужны исследовательские отделы и как они помогают им быть «в тренде». Обширный материал Веры Борисовой, креативного директора дизайн-студии «Четвёртый Рим», знакомит читателей с целым набором методик, выявляющих скрытые инсайты потребителей.
Помимо подробных материалов, имеющих методологическую ценность, в номере представлены практические кейсы от компаний IDEO и SMULE об их исследовательском опыте при разработке новых продуктов. На примере опыта компании IDEO Екатерина Храмкова доходчиво разъясняет какую ценность несет бизнесу дизайн-мышление. Статья Дэвида Ингерсолла (David Ingersoll), старшего аналитика по исследованиям компании Q Research Solutions, Inc (США) в деталях описывает практику проведения сенсорных исследований для рынка FMCG.
В разделе «Design Management» читайте «7 правил создания хорошего дизайна» от Александра Матвеева (Designet.ru), написанные аж в 1996 году и до сих пор актуальные.
Студенты Британки (БВШД) в лице Елены Котельниковой делятся впечатлениями от посещения лондонских дизайн-студий и исследовательских компаний с мировым именем.
Все авторы третьего номера — практики. Те, кто ежедневно использует дизайн-мышление, активно исследует жизнь и творчески «управляет» стратегиями и процессами. Формат журнала позволяет им быть совершенно откровенными с читателем, раскрывая тему исключительно с позиций личного опыта, знаний и навыков.
Номер доступен для свободного скачивания.
Он-лайн новости из мира дизайн-мышления, дизайн-менеджмента и дизайн-исследований читайте на нашей fb-страничке.
research design
There are always many possible ways to define a specific research problem and the research design; the way the researcher formulates the problem and design is a key part of how a research proposal is evaluated. — Всегда существует множество способов определить исследовательскую проблему и проект исследования; способ, с помощью которого исследователь формулирует проблему и проект исследования, является главной составляющей того, как проект будет оценен.
Смотреть что такое «research design» в других словарях:
research design — The strategic plan for a research project or research programme, setting out the broad outline and key features of the work to be undertaken, including the methods of data collection and analysis to be employed, and showing how the research… … Dictionary of sociology
Game Research/Design — (GR/D) was a board wargame publisher, principally concerned with the Europa series of European World War II wargames. GR/D was formed in 1985 by John Astell, one of the Europa designers, and Winston Hamilton, another WWII wargame designer. The… … Wikipedia
Design methods — is a broad area that focuses on: Divergence – Exploring possibilities and constraints of inherited situations by applying critical thinking through qualitative and quantitative research methods to create new understanding (problem space) toward… … Wikipedia
Design thinking — refers to the methods and processes for investigating ill defined problems, acquiring information, analyzing knowledge, and positing solutions in the design and planning fields. As a style of thinking, it is generally considered the ability to… … Wikipedia
Design Science (methodology) — Design Science is an outcome based information technology research methodology, which offers specific guidelines for evaluation and iteration within research projects. Design science research focuses on the development and performance of… … Wikipedia
Design Science Research — (DSR) is based on the work of Professor Joan Ernst van Aken (Technische Universiteit Eindhoven, The Netherlands). The core mission of DSR is to develop general knowledge which can be used by professionals in the field in question to design… … Wikipedia
Design management — is the business side of design. Design managers need to speak the language of the business and the language of design … Wikipedia
Design of experiments — In general usage, design of experiments (DOE) or experimental design is the design of any information gathering exercises where variation is present, whether under the full control of the experimenter or not. However, in statistics, these terms… … Wikipedia
Design — For the 1970s music group, see Design (UK band). All Saints Chapel in the Cathedral Basilica of St. Louis by Louis Comfort Tiffany. The building structure and decorations are both examples of design … Wikipedia
Design of quasi-experiments — The design of a quasi experiment relates to a particular type of experiment or other study in which one has little or no control over the allocation of the treatments or other factors being studied. The key difference in this empirical approach… … Wikipedia
Design for X — Under the label Design for X, a wide collection of specific design guidelines are summarized. Each design guideline addresses a particular issue that is caused by, or affects the characteristics of a product. The design guidelines themselves… … Wikipedia
Что такое исследовательский дизайн и как это делается?
дизайн исследования представляет собой набор методов и процедур, используемых для сбора и анализа показателей переменных, указанных в исследовании задачи исследования.
План исследования определяет тип исследования (описательная, корректирующая, полу-экспериментальная, экспериментальная, обзорная или аналитическая цель) и подтип (как случай продольного описательного исследования), исследовательская задача, гипотеза, независимые и зависимые переменные, дизайн план экспериментального и статистического анализа.
Есть много дизайнов, которые используются в исследованиях, каждый из которых имеет свои преимущества и недостатки. Выбор метода, который будет использоваться, зависит от цели исследования и от природы явления.
Основные характеристики дизайна исследования
Части дизайна исследования
Дизайн выборки
Это связано с методами выбора элементов, которые будут наблюдаться для исследования.
Наблюдательный дизайн
Это связано с состоянием, в котором будет создано наблюдение.
Статистический дизайн
Его беспокоит вопрос о том, как будет анализироваться информация и собранные данные.?
Операционный дизайн
Это связано с методами, с помощью которых процедуры собираются при отборе проб..
Как создать дизайн исследования
План исследования описывает, как будет проводиться исследование; составляет часть исследовательского предложения.
Прежде чем создавать дизайн исследования, необходимо сначала сформулировать проблему, главный вопрос и дополнительные вопросы. Поэтому сначала нужно определить проблему.
План исследования должен представлять собой обзор того, что будет использоваться для проведения исследования проекта..
Он должен описывать, где и когда будет проводиться исследование, образец, который будет использоваться, подход и методы, которые будут использоваться. Это можно сделать, ответив на следующие вопросы:
пример
Отправной точкой дизайна исследования является основная проблема исследования, которая вытекает из подхода к проблеме. Пример основного вопроса может быть следующим:
Какие факторы заставляют посетителей интернет-магазина H & M окончательно совершать покупки в традиционном магазине?
Ответы на эти вопросы:
где? По основному вопросу очевидно, что исследование должно быть сосредоточено на интернет-магазине H & M и, возможно, на традиционном магазине..
когда? Исследование должно проводиться после того, как потребитель приобрел товар в традиционном магазине. Это важно, поскольку вы выясняете, почему кто-то идет по этому пути, а не покупает продукт через Интернет..
Кто или что? В этом случае ясно, что следует учитывать потребителей, которые сделали свою покупку в традиционном магазине. Тем не менее, также может быть решено изучить потребителей, которые, если они сделали свою покупку онлайн, чтобы сравнить различных потребителей.
Как можно? На этот вопрос часто сложно ответить. Помимо прочего, вам может понадобиться учитывать количество времени, которое у вас есть на проведение исследования, и если у вас есть бюджет для сбора информации.
В этом примере могут быть подходящими как качественные, так и количественные методы. Варианты могут включать интервью, опросы и наблюдения.
Различные исследовательские проекты
Конструкции могут быть гибкими или фиксированными. В некоторых случаях эти типы совпадают с количественными и качественными планами исследований, хотя это не всегда так.
В фиксированных проектах дизайн исследования уже установлен до сбора информации; они обычно руководствуются теорией.
Гибкие конструкции предоставляют больше свободы в процессе сбора информации. Одна из причин, по которой можно использовать гибкие схемы, может заключаться в том, что интересующая переменная не может быть измерена количественно, например культура. В других случаях теория может быть недоступна в начале расследования.
Поисковое исследование
Исследовательские методы исследования определяются как формальные исследования. Основными методами являются: опрос, связанный с литературой и опрос опыта.
Опрос, связанный с литературой, является наиболее простым методом постановки задачи исследования..
В случае описательного и диагностического расследования
Это исследования, которые касаются описания характеристик человека или группы в частности. В диагностическом исследовании мы хотим определить частоту, с которой будет происходить одно и то же событие..
Исследования, которые проверяют гипотезы (экспериментальные)
Это те, в которых исследователь проверяет гипотезу случайных отношений между переменными.
Характеристики хорошего дизайна исследования
Хороший дизайн исследования должен соответствовать этой конкретной проблеме исследования; обычно включает в себя следующие характеристики:
Типы дизайн исследований, которые следует знать каждому дизайнеру
В UX дизайне исследования являются фундаментальной частью решения соответствующих проблем и/или уменьшения до “правильных” проблем, с которыми сталкиваются пользователи. Работа дизайнера заключается в том, чтобы понять своих пользователей. Это означает выход за рамки первоначальных предположений, чтобы поставить себя на место других людей, чтобы создавать продукты, которые отвечают потребностям человека.
Хорошие исследования не просто заканчиваются хорошими данными, они заканчиваются хорошим дизайном и функциональностью, которые пользователи любят, хотят и в которых они нуждаются.
Дизайнерские исследования часто упускаются из виду, поскольку дизайнеры акцентируют внимание на том, как выглядит дизайн. Это приводит к поверхностному пониманию людей, для которых он предназначен. Наличие такого мышления противоречит тому, что такое UX. Это ориентированность на пользователя.
UX дизайн сосредоточен вокруг исследований, чтобы понять потребности людей и то, каким образом продукты или услуги, которые мы создадим, помогут им.
Вот некоторые методы исследования, которые каждый дизайнер должен знать, когда начинает работу над проектом, и даже если он не занимается исследованиями, он может лучше общаться с UX исследователями.
Первичные исследования
Первичные исследования по сути сводятся к новым данным, чтобы понять, для кого вы проектируете, и что вы планируете проектировать. Это позволяет нам проверять наши идеи с помощью наших пользователей и разрабатывать для них более значимые решения. Дизайнеры обычно собирают подобные данные с помощью интервью с отдельными лицами или с небольшими группами, при помощи опросов или анкетирований.
Важно понять, что вы хотите исследовать, прежде чем прекратить поиск людей, а также вид или качество данных, которые вы хотите собрать. В статье из Университета Суррея автор обращает внимание на два важных момента, которые следует учитывать при проведении первичных исследований: обоснованность и практичность.
Обоснованность данных относится к истине, это то, что она рассказывает об изучаемом предмете или явлении. Возможно, что данные надежны, не будучи при этом обоснованными.
Практические аспекты исследования должны быть тщательно рассмотрены при разработке проекта исследования, например:
– стоимость и бюджет
– время и шкала
– размер выборки
Браймен в своей книге Методы социальных исследований (2001) определяет четыре типа обоснованности, которые могут повлиять на полученные результаты:
То есть, действительно ли статистические данные о посещаемости церкви измеряют силу религиозных убеждений?
То есть, действительно ли это безработица является причиной преступности или есть другие объяснения?
То есть, если в этом регионе будет использоваться один вид подхода к развитию сообщества, будет ли он иметь одинаковое воздействие в другом месте?
То есть, если ситуация наблюдается в ложной обстановке, как это может повлиять на поведение людей?
Вторичные исследования
Вторичные исследования используют существующие данные, такие как Интернет, книги или статьи для поддержки вашего выбора дизайна и контекста, лежащего в основе вашего дизайна. Вторичные исследования также используются как средство дальнейшего подтверждения достоверности информации из первичных исследований и создания более прочного случая для общего дизайна. Как правило, вторичные исследования уже обобщили аналитическую картину существующих исследований.
Это нормально использовать только вторичные исследования для оценки вашего дизайна, но, если у вас есть время, я бы определенно рекомендовал делать первичные исследования вместе со вторичными исследованиями, чтобы действительно понять, для кого вы разрабатываете и собираете идеи, которые более актуальны и привлекательны, чем существующие данные. Когда вы собираете данные пользователя, специфичные для вашего дизайна, это будет генерировать лучшие идеи и лучший продукт.
Оценочные исследования
Оценочные исследования описывают конкретную проблему для обеспечения удобства использования и обоснования ее потребностями и желаниями реальных людей. Одним из способов проведения оценочного исследования является использование пользователем вашего продукта и предоставление им вопросов или заданий, чтобы они рассуждали вслух, когда пытаются выполнить задачу. Существует два типа оценочных исследований: суммирующий и формирующий.
Суммирующее оценочное исследование. Суммарная оценка направлена на понимание результатов или эффектов чего-либо. Она больше подчеркивает результат, чем этот процесс.
Суммарное исследование может оценивать такие вещи, как:
Формирующее оценочное исследование. Формирующая оценка используется, чтобы помочь укрепить или улучшить человека, или предмет, который проходит тестирование.
Формирующее исследование может оценивать такие вещи, как:
Поисковые исследования
Поисковые исследования проводят вокруг темы, о которой мало или никто не знает. Цель поискового исследования состоит в том, чтобы получить глубокое понимание и знакомство с этой темой, погрузив себя в нее как можно больше, чтобы создать направление для потенциального использования этих данных в будущем.
С поисковыми исследованиями у вас есть возможность получить новые идеи и создать достойные решения для наиболее значимых проблем.
Поисковые исследования позволяют нам подтвердить наши предположения относительно темы, которую часто упускают из виду (т. е. заключенных, бездомных), предоставляя возможность генерировать новые идеи и развитие для существующих проблем или возможностей.
Основываясь на статье из Университета Линн, поисковые исследования говорят нам о том, что:
Воспроизводящие исследования
Воспроизводящие исследования касаются использования исследований, которые вы провели, и возможности использовать полученную информацию для определения того, какую проблему вы хотите решить и создать для нее решения. Эти решения, как правило, новы или улучшают существующую проблему.
Поскольку воспроизводящие исследования – это более или менее этап создания возможностей или решений, вы должны заранее понимать желания, потребности и цели своих пользователей. Воспроизводящие исследования позволяют нам наблюдать поведение пользователя в естественной среде, которое можно было больше понять через этнографию, контекстные интервью, фокус-группы и интеллектуальный анализ данных.
В чем отличие рыночных исследований от дизайн исследований?
Вы можете продавать пользователям то, что они сказали, что хотят, но исследования рынка не могут рассказать вам о решении проблем, которые клиенты не могут понять (Эрик Шмидт и Джонатан Розенберг)
Основное различие между исследованиями рынка и дизайнерскими исследованиями заключается в том, что дизайн исследования более изменчивые, интуитивные. Это означает, что данные основаны на том, как люди чувствуют и просто благодаря нашей человеческой природе соединяются с другими, чтобы прийти к пониманию, которое ведет к изменениям. Мотивом дизайнерских исследований является приближение к соединению с другим человеком, чтобы выработать значимость для их целей. Исследования рынка часто основаны на логике и необходимости компании оценить конкуренцию, но наряду с дизайн исследованиями, оба могут использоваться в сочетании для создания лучшего пользовательского опыта посредством установления контакта с пользователями и понимания их.
Вывод
Так почему дизайн исследования так важны? Дизайн исследования позволяют нам понять сложное поведение человека, достигая корня проблемы, понимая потребности, желания и цели пользователя.
Это также формирует опыт пользователя, который помогает нам решить их основные проблемные вопросы. В целом, данные, которые мы собираем с помощью проектных исследований, позволяют принимать решения. Это приводит к применению этих данных в полезных приложениях, которые позволяют нам создавать продукты, которые релевантны, доступны и пригодны для пользователей и людей, с которыми мы работаем, будь то участники проекта, продакт-менеджеры или другие дизайнеры в команде.
Если у вас есть вопросы или вы просто хотите пообщаться, свободно пишите мне в Linkedin 🙂
Если вам понравилась моя заметка, пожалуйста, поделитесь ею!
Почему нельзя делать дизайн-системы проектами
С ростом команд дизайнеров и разработчиков в компаниях возникает потребность в лучшей организации и стандартизации процессов и инструментов. Новоприбывшие начинают работать над клиентскими проектами, для чего им нужна хорошо работающая дизайн-система.
Выяснилось, что превращение дизайн-системы в еще один проект работает не очень хорошо. Но почему же? Об этом в нашей статье.
Зачем же команда вообще нужна дизайн-системе? Обычно команды в компаниях делятся по определенным направлениям: креатив, разработка и маркетинг. Каждую команду возглавляет тимлид, которому при желании помогает менеджер по планированию.
Существуют еще и проектные команды. Каждая из них состоит из нескольких дизайнеров, разработчиков и маркетологов, а возглавляет ее проджект-менеджер. Составы команд могут меняться со временем.
В итоге дизайнеры, разработчики и маркетологи должны отчитываться перед руководителем своей группы и перед руководителем проектов.
Из-за этой модели командам сложно делиться ресурсами. Мы часто не знаем, над чем работают другие люди, если только не спросим их или не услышим об этом на собрании. Это является причиной того, что одна и та же работа выполняется несколько раз.
Поэтому нам нужны более стандартизированные компоненты, чтобы команды работали эффективно. Кроме того, нам нужно иметь в этих командах больше глаз и ушей, чтобы знать, какие компоненты им нужны больше всего.
В среднем компонентов может потребоваться больше, чем то количество, которое один человек мог бы создавать и шерить самостоятельно. Чтобы создать больше компонентов, запускается проект.
Проект дизайн-системы, который мы рассматриваем в этой статье, наследует конвенцию обычных проектных групп. Для создания компонентов требуется управление проектами, исследования, дизайн и код. Итак, проект начали с менеджера, UI-исследователя, дизайнера и разработчика.
Нашей первой задачей как команды дизайн-системы было создание хедера сайта и компонента навигации. Менеджер проекта запросил у нас оценки и рассчитал окупаемость инвестиций, исходя из времени, сэкономленного в будущих проектах. Он хотел использовать этот проект как кейс, чтобы убедить высшее руководство инвестировать в большую стандартизацию.
Он понимал, что высшее руководство не позволит нам работать над большей стандартизацией пока этот проект не увенчается успехом. Получается, что мы не будем работать над другими компонентами до завершения этого проекта.
Ресерч заключается в собирании различных паттернов навигации, вхождений на сайтах конкурентов и на наших. Через неделю результаты были предоставлены команде, чтобы мы могли двигаться дальше.
После презентации результатов планировалось вместе с командой разработать гайдлайны. Идея эта понравилась не всем. Нам действительно удалось создать некоторые руководящие принципы, но было много дискуссий о том, какие варианты нового компонента будут наиболее важными. И какие будут созданы в первую очередь.
К работе приступает визуал-дизайнер. Два месяца спустя он показал отличный интерактивный прототип в Figma.
Эта разработка немного не соответствовала нашей системе. Дизайнер создал компонент навигации в новом файле с дубликатом шаблонов нашей дизайн-системы. Остальные начали задаваться вопросом, какой файл им следует использовать.
Он дал понять, что может прислушиваться ко мнению других дизайнеров, быстро внедрять фидбек и понимать, как работают системы. Было решено архивировать файлы дизайн-системы и позволить ему поддерживать ее визуальную часть. С помощью этого дизайнеры всегда знали, где можно найти нашу дизайн-систему.
Мы хотели начать разработку как можно скорее и быстро добавить компонент навигации в нашу кодовую базу. За это время мы также сменили хранилище ассетов на Webpack и оптимизировали скорость загрузки страниц Google, что также заняло некоторое время.
Два месяца спустя, через четыре месяца работы над проектом, мы до сих пор не могли найти время на разработку навигации. В конце концов, я внес свой вклад, взяв эту задачу на себя.
Компонент навигации был написан в Storybook. Его можно протестировать, пошерить своей команде и прикрутить автоматизированную документацию.
Storybook оказался проблематичным в нашем рабочем процессе. Люди не понимали всех его элементов управления. И эти же люди не привыкли тестировать компоненты изолированно.
Но что еще более важно, Storybook не поместился в наш стек кода. Мы использовали встроенные шаблоны Vue для оптимизации SEO и совместимости с нашей серверной структурой Laravel с нашей CMS. Storybook не поддерживает встроенные шаблоны Vue с Laravel, а просто запрашивает однофайловые компоненты.
Компонент навигации создавался для поддержки как отдельных файловых компонентов, так и встроенных паттернов. Но и это не помогло. Один и тот же функционал в двух разных местах нельзя было масштабировать, что было прямо костью в горле. Было решено придерживаться встроенных паттернов и с их помощью корректировать компонент навигации.
Восемь месяцев спустя после запуска проекта наш фронтенд разработчик объединил код с основной веткой нашей кодовой базы, что означало – навигация полностью готова.
Когда мы запускали наш первый проект дизайн-системы, мы рассчитывали на то, что его релиз произойдет довольно скоро. Но этого не произошло, потому что проект попросту терял приоритет. В результате чего его релиз неоднократно переносился.
Нас это не шокировало. Клиентские заказы всегда были для нас в приоритете. Чтобы оказать свои услуги надлежащим образом, необходимо действовать быстро. Ставить большие внутренние проекты выше по приоритету, чем клиентские чаще всего не вариант.
Реальной проблемой стало то, что наш проект оказался бутылочным горлышком. Мне не позволили ресерчить новые компоненты. И нашему дизайнеру пришлось ждать результатов этих самых поисков, так как нами использовался процесс, известный как Waterfall. Это происходило просто потому, что команда считала, что нам не разрешают работать над новыми компонентами.
В этом году я посетил выступление Сандера Хугендорна, коуча по Agile, спикера и писателя. Он говорил об Agile, Scrum и о том, как они ломаются в современной среде разработки ПО. По его словам, мы должны ПРЕКРАТИТЬ заниматься проектами. Этот тезис привлек мое внимание даже несмотря на то, что я работаю в агентстве, которое зарабатывает деньги, выполняя эти самые проекты.
Решением, предложенным Сандером, стало непрерывное выполнение. Это не новая концепция, и в последнее время ей уделяется все больше внимания. Особенно в DevOps, где в настоящее время циклы запуска в основном автоматизированы. При непрерывном выполнении функции разделяются на более мелкие части, которые можно релизить, когда они будут готовы.
Причина, по которой мне понравился этот метод, заключалась в том, что наш проект дизайн-системы не сдвигается с места. А у нас в это же время появляется все больше компонентов, ожидающих ресерча, проектирования и разработки.
Наши ресурсы были ограничены, а компонент навигации был слишком громоздким, что и приостанавливало разработку других элементов. Было ясно, что проектная система здесь не работает.
Когда мы собирали команду, я хотел сделать процесс разработки дизайн-системы чем-то вроде пазла. Это дало бы четкое представление о том, что мы должны получить в итоге.
Когда мы заходили в тупик, пазл был прекрасной возможностью пересмотреть наш Waterfall/ SCRUM-процесс и определить, сможем ли мы получить выгоду от непрерывного выполнения. При этом, работая одновременно над большим количеством компонентов.
Поддержки от команды я никакой не нашел. Люди не видели необходимости менять статус-кво и были уверены в своей правоте, следуя заранее утвержденному графику. Чтобы подбодрить их, я поговорил с одним из наших директоров.
Я работал с ним над нашей первой системой проектирования и знал, что он одобрит мою идею, если это поможет нам стандартизироваться. Когда я сказал ему, что наша дизайн-система становится бутылочным горлышком, он запланировал встречу с командой, чтобы обсудить создание дополнительных компонентов.
На этой же встрече я попытался объяснить, в чем заключается суть пазла. Я рассказал, как именно это работает и что может дать в итоге, предоставив все необходимые материалы. Однако решение нашлось очень быстро. Оно заключалось в отсутствии общего понимания нашего существующего процесса.
Одни не знали о о существовании цикла релизов, инициированных нашим веб-разработчиком. Другие же – как устанавливаемые пакеты в кодовой базе использовались при релизе компонентов. А третьи вообще даже понятия не имели о том, что мы отстаем от графика и что у нас уже есть стартовый набор в Figma.
В конце концов, головоломку мы решать не стали, а просто обсудили, каким образом можно сдвинуть дело с мертвой точки. Первоначальная уступка нашего проджект-менеджера была расширена добавлением ресерчей, проектированим и разработкой других компонентов. Эти самые компоненты было решено собирать в бэклог и канбан-доску.
Чтобы задокументировать эти решения, я разложил на столе пазл. Таким образом, я получил фидбек от команды без необходимости организовывать еще одну встречу.
Наш процесс начинается со стандартизации командой дизайнерских систем. У нас есть общий бэклог, содержащий список компонентов, которые мы хотим создать. Эти компоненты исследуются для выработки руководящих принципов, передовых методов или требований. После этого происходит проектирование и разработка этих элементов. После каждого пройденного этапа процесса мы делаем его обзор.
Второй этап процесса – это релиз. Во время разработки нам нужно выбрать устанавливаемый пакет Composer для каждого компонента. Затем элементы выпускаются в этих пакетах senior developer’ом.
Когда релиз компонента происходит в пакете, мы можем сделать его в Figma, как «доступный в коде». Об этом мы сообщаем нашей команде дизайнеров и разработчиков на собраниях, технических встречах или же по электронной почте.
Пока используются компоненты, мы можем понять, как они работают. Опыт дизайнеров и разработчиков можно определить, проводя опросы. Измерить время, потраченное на настройку компонентов для клиентов, можно с помощью логов. Пользовательский опыт измеряется с помощью юзабилити-тестирования, опросов или веб-аналитики.
Каждый из этих параметров может стать причиной или создания нового компонента, или обновления уже существующего. Эти запросы должны поступать в нашу команду по разработке системы.
На данный момент специально для нашей дизайн-системы эти метрики еще не настроены. Но мы уже экономим время, проводя юзабилити-тестирование и собирая аналитику. Эти показатели могут быть преобразованы в фидбек для нашей команды в будущем.
В конце концов, мы сделали доску Trello, чтобы отслеживать прогресс этих компонентов. Эта доска должна быть общедоступной для всех в нашем агентстве. Это делается для того, чтобы каждый мог делать запросы в нашем бэклоге. В будущем мы могли бы направлять эти запросы, настраивая автоматическую форму с общими вопросами, которая затем преобразовывала бы любые отправленные формы в карточки Trello.
Перейти к непрерывному и гибкому рабочему процессу не так уж и легко. Особенно, когда твои коллеги привыкли работать в темпе Waterfall. Для клиентских проектов мы используем scrum и kanban в качестве инструментов оценки задач и регистрации проблем, но дизайн и разработка часто теряют друг друга при каскадной модели.
Когда мы придумывали новые компоненты, мы присваивали каждому из них приоритет. Затем наш руководитель проекта создал новый проект, в котором мы снова и снова занимались ресерчами, проектированием и разработкой по каскадной модели.
Когда началась разработка, бэкендер набросал некоторый код, с которым мы могли бы работать. Но у его трудов не было дизайна. Мы доказали, что можем работать в гибком и непрерывном потоке, привлекая нашего дизайнера и бэкэндера.
В иных случаях приоритеты меняются, и нам приходится отказываться от заранее определенной дорожной карты. В начале этого года я сагитировал команду на использование Webpack в качестве сборщика ресурсов по умолчанию. Это было не совсем по нашему плану, но нам нужно было модернизировать кодовый стек и обеспечить совместимость со современными интерфейсными инструментами.
Несколько месяцев спустя это изменение оказалось выгодным для оценки скорости загрузки страниц на наших веб-сайтах. Мы смогли сделать апгрейды, которых не было бы без веб-пакета. Это притормозило нашу работу над дизайн-системой, но, проводя эти апгрейды, мы смогли создать более качественные компоненты.
Последний пример развития рабочих процессов – смена инструментов. Я начал использовать Storybook для создания и тестирования нескольких вариантов компонентов по отдельности. Позже я обнаружил, что Storybook не подходит для кодового стека и рабочего процесса. Но мне все еще нужно было место, где я мог бы создавать и тестировать различные варианты нашего компонента.
Вот почему я создал Storybase. Это пакет для приложений Laravel, совместимый с любым html-компонентом, включая встроенные шаблоны Vue. Storybase отображает наши компоненты на сервере, чтобы мы могли оптимизировать их для SEO во время тестирования. Это также позволяет нам имитировать данные в Laravel для каждой истории. И, наконец, каждую из них можно добавить в нашу документацию.
Когда я создавал Storybase, наш компонент навигации по сайту был уже на финальной стадии разработки. Но мы начали клиентский проект с некоторых Snowflake-компонентов, которые внесли множество вариаций. Я установил Storybase в проект, задокументировал и протестировал каждый компонент. Это очень помогло убедить моих коллег-разработчиков в ценности таких инструментов. Теперь я планирую использовать Storybase не только для разработки нашей дизайн-системы, но и для каждого клиентского проекта.
— Не создавайте свою дизайн-систему с помощью каскадной модели или scrum-спринтов. Это слишком большая задача для них. Создайте очередь с компонентами и убедитесь, что задачи для этих компонентов небольшие. Это необходимо для того, чтобы над ними можно было работать непрерывно.
— Настройте процесс со своей командой на ранней стадии, чтобы вы могли узнать на одной странице, какие шаги следует предпринять до релиза компонентов, когда создавать новые или обновлять старые.
— Используйте такой инструмент, как Storybook, для документирования и тестирования вариантов ваших компонентов. Или же создайте для этого свой собственный инструмент.
Больше интересных и актуальных статей ищите в нашем блоге и телеграм-канале.