The Design Review
The design review, and then later in the development phase, the production readiness review, are two incredibly important parts of our development cycle on the Jet.com engineering team. These two events are a huge part of our success; in fact, I will argue that the design review process has been instrumental to us building a world-class engineering organization. As you’ll read in this post, I attribute much of our uptime, cross-pollination of technical ideas, and the reliability of our systems to these two engineering wide meetings. They help catch edge cases and really push our systems in the right direction.
I would like to talk you through what the design review process looks like for us at Jet. I would also like to get into some of my favorite design reviews that I have seen over the last 4 years here at Jet.com and some of the learnings.
What is a design review?
A design review is an engineering wide meeting that is an opportunity for a team, or an individual from a team, to showcase the architecture design and get approval from the rest of engineering for the building of a new system, a new feature they would like to introduce to jet.com, or the on-boarding of a new platform that will impact all of engineering in some way. These meetings are a staple of our engineering culture. Folks can, and should, spend days or weeks preparing for one of these. Many documents are drafted and re-iterated on before they are presented in these meetings. Lunch is always served.
For us at Jet design reviews happen on Thursday, every single Thursday. There are one or two design reviews scheduled by different teams across engineering every week. Each is an incredible opportunity for new engineers to learn how scalable distributed systems are built from the design phase to implementation. These design and production readiness reviews are tremendously helpful to catch edge cases that the designing team may have missed. They are a great opportunity for teams to understand the tradeoffs of certain technologies without having to do so the hard way.
For example, if a team is preparing to introduce a new piece of technology such as Cosmos DB to their system, and that particular team has never worked with this technology before, this is an opportunity for other engineers from other teams who have experience with it to chime in and to talk about their experiences and the edge cases they have seen in a production setting. The value of this cannot be understated — people are often blinded by the promises of new technology but it’s only when you are woken up in the middle of the night because it broke down that you really understand what the design review and production readiness review process are doing for you.
Design reviews have a few rules at Jet.
1. Be on time. They start promptly at the scheduled time. A lot of engineers can and do attend, and engineering time is valuable.
2. Be prepared. You must come prepared with the design document, architecture diagrams, and the risk management thought through. If you have not thought through your system well enough then this is where that will be made evident in front of all of engineering, and you don’t want that. At the same time, it is ok if you missed some edge cases, that is what this process is for.
3. Be ready to answer questions. It is a given that you should be ready to answer questions about your design. However, if your system is particularly interesting, occasionally questions will come during the presentation and there will definitely be questions after your presentation.
Learnings and benefits.
For me personally, I always seem to learn something new with each design review that I am able to attend. I am either learning about a new area of the business that I never touch, such as Supply Chain, and how they are going to solve a deeply technical challenge using a new system, or I learn about new techniques and technologies.
Decisions are made in the design review process that can and will impact other teams. Decisions are made to approve the on-boarding of new technologies or presenting new ways of doing things. Not attending means you don’t have your concerns heard and this can have consequences (but that is for another blog post).
Being selected to present by your team is an honor. It means they trust you to deliver the architecture of this system to the rest of engineering. It is a great opportunity to hone your presentation and public speaking skills in a safe and friendly environment.
Some of my favorite design reviews.
1. The push for containerization and the Nomad design review. This particular design review was perhaps one of the most contentious at Jet, because it impacted every single engineering team at Jet and the way they write their code. This led to some funny outbursts during the design review itself, and a few calls for an engineering-wide vote, but ultimately it yielded some great results. The back and fourth led to the rethinking of certain aspects of this system and ultimately led to a better rollout of this technology, providing flexibility for teams.
2. I presented a design review, in the early days of Jet, for the segmentation engine my team was building for marketing and I was not able to get approval from the teams that would be affected on the first try. This is because this system required a particularly large set of data, and in as a real-time fashion as possible. At the time, this conflicted with our Tiering system for SLAs (Service Level Agreements) between teams, as it required pulling data from what was considered a big data analytics system with loose SLAs (measured in minutes) into a production system that had tight SLAs measured in milliseconds. This was a huge no-no but we needed something, because the marketing business was desperate for this segmentation engine. Ultimately this led to many compromises, which in turn resulted in the formation of a brand new engineering team to support the type of large data aggregation our system required. This new team would go on to use Kafka, Spark, and Cassandra to handle the near-real-time aggregation of all production data at Jet and make it available to our Segmentation Engine.
3. The Equinox design review was a particularly interesting one that I think many folks at Jet learned a great deal from. We are known at Jet for having one of the largest event sourcing systems in the world but that hasn’t come without cost. We have had many issues in the past with the backbone of our event storage layer and as we barreled down the path of millions of users and the load kept going up we needed to build something ourselves. Equinox was our answer. It was a well thought-out event store that sits on top of CosmosDB on Azure and enables event sourcing. I think a good number of engineers learned a great deal about distributed systems and event sourcing from this particular design review.
4. The original Inventory System design review and the introduction of Document DB (now known as CosmosDB) to our tech stack. A new real-time inventory system was needed at Jet and, as such, a group of folks was pulled together to get this done. As they explored their options, they landed on a technology that they felt could fit their needs for the hundreds of millions of daily updates to inventory, their persistence, expiration, and many other aspects of their system. However, they couldn’t be too sure since the technology on Azure was very new at the time. So they set out to run some massive load tests that would prove the technology could handle the load. These tests were so large that their cost ran into the hundreds of thousands of dollars, and they exploded our technology costs exponentially for the week they were running. I will always remember how interesting the findings were, and how great it was that the team, with the OK of the business, was willing to go to this length to make sure the system was sound.
There are many other fantastic design reviews at Jet, too many to mention in one blog post, but these are a few that stand out and come to my mind right away.
Дизайн ревю что это
Что такое дизайн-ревью? Это процесс, в ходе которого дизайнер оценивает результаты разработки до релиза проекта, указывает на недочеты и вносит предложения по доработке дизайна. В некоторых компаниях этот процесс может называться по-другому, но суть остается той же.
Какие задачи решает дизайн-ревью?
Не всегда тимлид, разработчики, тестировщики и сами дизайнеры понимают, для чего внедрять дизайн-ревью. В действительности это очень важный этап работы над любым IT-проектом, решающий сразу несколько задач:
- Дизайнер получает целостное представление об итогах своей работы
Без дизайн-ревью со временем у дизайнера появляется ощущение, что он работает «в стол». А это может перерасти в выгорание, особенно если в продакшн выкладывается совсем не то, что предлагал дизайнер - Улучшается взаимодействие внутри команды
Дизайн-ревью помогает разработчикам и тестировщикам делать свою работу еще лучше. Дизайнер указывает им на незаметные неспециалисту мелочи, которые важны для привлечения внимания пользователей или облегчения восприятия интерфейса в целом
Преимущества разработки с дизайн-ревью
Схема разработки IT-решений, включающая этап дизайн-ревью, обладает целым рядом весомых преимуществ:
- На выходе получается продукт, точно соответствующий исходным дизайн-макетам, которые уже утверждены клиентом
- Растет качество готового IT-продукта и удовлетворенность заказчика итогами сотрудничества
- Упрощается работа тестировщиков
- Взаимодействие между специалистами внутри команды выходит на качественно новый уровень. Как дизайнер может указывать на неточности в сверстанном макете, так и разработчик может предложить собственные идеи, к которым может прислушаться дизайнер и использовать их в будущих проектах
- В коллективе повышается культура общения, решение задач происходит быстрее и более качественно
- Заказчики проекта быстрее согласовывают итоги разработки перед релизом, поскольку они точно соответствуют уже согласованным прототипам и дизайн-макетам
Что показывает опыт внедрения дизайн-ревью?
В процессе внедрения дизайн-ревью в работу команды, можно столкнуться с возражениями вроде:
- дизайнеры забирают работу тестировщиков
- это дополнительная нагрузка на дизайнера
- еще кто-то указывает, что делать разработчику
- проверка тестировщиком — это хорошо, но вместе с ревью дизайнера результат еще лучше
- дизайнер не может заменить тестировщика, поскольку у них очень разный набор скиловразработчики также заинтересованы в получении качественного результата, а грамотно организованный процесс дизайн-ревью не задерживает, а ускоряет релиз
- нагрузка на дизайнера действительно растет, но это серьезно экономит время и силы на следующих этапах работы, защищая от непредвиденных результатов в продакшн и доработок перед самым релизом
При желании схему дизайн-ревью реально адаптировать под разработку и тестирование любого IT-продукта, независимо от его масштаба и отраслевой направленности. Ключевое значение для успешного внедрения дизайн-ревью имеют soft-skills инициатора этого новшества. В первую очередь это касается коммуникационных навыков и умения мотивировать коллег. Чтобы получить от дизайн-ревью максимум пользы для общего дела, крайне важно дать команде верный настрой.
Заключение
Внедрение в процесс создания IT-продуктов этапа дизайн-ревью улучшает взаимодействие между разработчиками, дизайнерами и тестировщиками. Это дает на выходе максимально качественный, удобный и полезный продукт, точно соответствующий ожиданиям заказчика разработки.
Чтобы ускорить процесс дизайн-ревью, можно составить собственный чек-лист для поиска ошибок. Им смогут пользоваться как дизайнеры, так и сами разработчики перед отправкой задачи на ревью. Помните, ваша цель состоит не в выискивании ошибок друг у друга, а в создании высококачественных IT-решений для развития бизнеса ваших клиентов.
design review
анализ проекта
Документированная, всесторонняя и систематическая проверка проекта с целью оценки его возможности выполнять требования к качеству, выявлять проблемы и определять способы их решения.
Примечание
Анализ проекта может проводиться на любом этапе процесса проектирования, но в любом случае он должен быть осуществлен по завершении процесса.
[ИСО 8402-94 ]
Тематики
- проектирование, документация
- управл. качеством и обеспеч. качества
Обобщающие термины
- термины относящиеся к системе качества
- design review
пересмотр конструкции
—
[Л.Г.Суменко. Англо-русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.]
Тематики
- информационные технологии в целом
- design review
3.10 анализ проекта (design review): Документально оформленный, комплексный и систематизированный процесс проверки проектной документации с целью оценки способности продукции удовлетворять установленным требованиям, позволяющий выявлять проблемы и предлагать пути их решений.
1 В настоящем стандарте основой для анализа проекта являются функциональные требования.
2 При разработке проекта оказания услуг также может быть проведен анализ проекта.
Англо-русский словарь нормативно-технической терминологии . academic.ru . 2015 .
Полезное
Смотреть что такое «design review» в других словарях:
Design Review — was a publication of the Wellington Architectural Centre. The Centre was founded in 1946, and began the first architectural school in Wellington (1947) and the first town planning school in New Zealand (1949). The Centre was unique at the time of … Wikipedia
Design review — This article is about the general concept of design reviews. For Design Reviews in DoD and NASA, see Design review (US Government). A design review is a milestone within a product development process whereby a design is evaluated against its… … Wikipedia
Design Review Based on Failure Mode — (DRBFM) is a tool originally developed by the Toyota Motor Corporation. This tool was developed based on the philosophy that design problems occur when changes are made to existing engineering designs that have already been proven successful.… … Wikipedia
Design review (US Government) — This page refers to the system engineering principle, for the magazine, see: Design Review (publication) In the United States military and NASA s engineering design life cycle, a phase of design reviews are held for technical and programmatic… … Wikipedia
Design Review (publication) — This article is about the magazine, for the military and government engineering design life cycle, see: Design review. Design Review was a publication of the Wellington Architectural Centre. The Centre was founded in 1946, and began the first… … Wikipedia
Design Review Based on Failure Mode — Versagenserfassungsgestützte Konstruktionsänderung bzw. Design Review Based on Failure Mode (DRBFM) ist eine Entwicklungsmethode, die den Entwicklungsprozess eines Prozesses/Produktes begleitet. Sie wird im Rahmen des Qualitätsmanagements zur… … Deutsch Wikipedia
Critical Design Review — Unter Critical Design Review oder abgekürzt CDR (deutsch: entscheidende Entwurfsprüfung) versteht man die letztgültige Planungskontrolle eines Projektes vor der Umsetzung. Es bildet einen wichtigen Meilenstein im Projektablauf, und ist oft auch… … Deutsch Wikipedia
System Design Review — A System Design Review (SDR) is a scheduled review, of many government contractor relations, which ensures continuous involvement throughout a program. The SDR is defined in the Air Force s MIL STD 1521.The SDR is a technical review conducted to… … Wikipedia
Design Web Format — Filename extension .dwf, .dwfx Developed by Autodesk Type of format CAD Design Web Format (DWF) is a secure file format developed by Autodesk for the efficient distribution and communication of rich design data to anyone who needs to view, review … Wikipedia
Design history file — is a compilation of documentation that describes the design history of a finished medical device. The design history file, or DHF, is part of regulation introduced in 1990 when the U.S. Congress passed the Safe Medical Devices Act, which… … Wikipedia
Design for manufacturability — (also sometimes known as design for manufacturing) (DFM) is the general engineering art of designing products in such a way that they are easy to manufacture. The basic idea exists in almost all engineering disciplines, but of course the details… … Wikipedia
Дизайн-ревью. Внедряем новый процесс
Всем привет! Меня зовут Артем Суслов. Я работаю продуктовым дизайнером в стартапе Playdex и в данной статье я хочу рассказать про процесс дизайн-ревью, который у нас выстраивается в компании.
Мы создаем маркетплейс для аренды NFT для Web3 игр, ориентированный на рынок Филиппин, но целимся и на всю Азию.
Тяжело предположить, кто будет читать эту статью — опытные IT-шники или же новички в сфере, но в любом случае хочу привести несколько понятий, которые сделают данный материал доступнее:
- Продакшн (прод) — то, что видит пользователь при переходе на сайт.
- Тестовый стенд — это среда в которой проводятся конечные тесты перед внедрением в продакшн.
- Пул реквест (Pull request, PR) — функция, c помощью которой разработчик может внедрить или изменить что-либо в проекте без влияния на остальной код. Пул реквест проходит ревью, после чего отправляется на тестовый стенд и затем в продакшн.
- Превью — режим просмотра для того, чтобы протестировать насколько верно внедрена фича.
Когда я пришел в продукт и передал в верстку первые макеты — пришлось испытать не очень приятные эмоции после увиденного результата. Цвета, типографика, отступы, поведение компонентов сильно отличались от того, что было в макетах. С этим нужно было что-то делать и возникла ожидаемая идея внедрить процесс дизайн-ревью.
Данный процесс полезен для будущего всей команды, так как он улучшает коммуникацию между разработчиками и дизайнерами.
В начале было заметное замедление в релизах фичей, так как требовалось время, чтобы адаптироваться к новому процессу. Однако через месяц скорость вернулась примерно к прежнему уровню, а качество улучшилось, поскольку все участники выполняли свою работу ответственно и понимали ценность дизайна.
Для того, чтобы наш продукт выглядел консистентным и единым, мы начали с создания сборника компонентов в Фигме и переноса их в Storybook. В приоритете были кнопки, инпуты и пагинация так как они наиболее часто использовались в текущем интерфейсе.
Storybook — это сервис для разработки переиспользуемых UI-компонентов. Он позволяет взаимодействовать и тестировать их до внедрения в продакшн. Важно отметить, что при изменении компонента в Storybook он изменится и в проде после деплоя. Инициатива принадлежит нашему ультра-фронтенд-разработчику — Мише, за что ему огромный респект.
Перед началом разработки я завожу задачу в таск-трэкер и прикладываю ссылки на интерактивный прототип, пошаговые макеты сценария для десктопа и мобилки, используемые компоненты.
Также можно описать все свои задумки и поведение компонентов при скроле, адаптивности. Если есть анимации — желательно приложить референсы. В общем, постараться ответить на все возможные вопросы разработчика заранее.
Но если все же требуется — мы созваниваемся с разработчиком, который делает данную задачу и обсуждаем нюансы. Возможно, внедрение анимации в данной задаче может занять долгое время, а так как мы работаем в стартапе — в приоритете скорость разработки. Поэтому все, что не успели сделать в текущей задаче — закидываем в бэклог. Главное, лучше это делать сразу, иначе потом будет тяжело вспомнить, что не успели сделать.
После первой итерации в пул-реквесте разработчик уведомляет, что можно приступать к дизайн-ревью. Для превью мы используем Vercel.
Vercel — это облачная платформа для размещения фронтенд-приложений и статических веб-сайтов. Одной из самых крутых фичей является возможность оставлять комментарии к конкретному компоненту или части интерфейса в превью.
Благодаря этому, не нужно коммуницировать в личных чатах (что пока не всегда получается) и все остальные разработчики видят комментарии.
- Логика и краевые состояния (edge cases) . Пример: есть флоу присоединения Дискорд-аккаунта к сайту. Что будет если человек перейдет на страницу присоединения аккаунта, но затем нажмет кнопку “Отменить”? В таком случае нужно предусмотреть релевантное модальное окно.
- Адаптивность и размеры отступов (паддинги и марджины) . Делается это с помощью режима разработчика. Тут дизайнеру нужно минимально знать HTML/CSS, чтобы, если нужно, внести правки и приложить скриншот к комментарию.
- Состояния компонентов: hover, active, disable, focus.
- Типографика. Проверяю с помощью плагина Font Ninja. Очень удобная тулза.
- Цвета. Либо на глаз, либо через режим разработчика.
- Контент. Правильно ли написаны тексты в интерфейсе и ничего не упущено.
После того как комментарии отправлены и по ним внесены правки, пул-реквест проходит вторую итерацию ревью. И желательно, чтобы она была последней. Но часто так не всегда получается, так как либо я что-то упущу или решу изменить после просмотра превью, либо разработчик сделает не так, как указано в комментарии. Но мы стараемся: )
Также нужно понимать, что так как мы работаем в стартапе, в приоритете у нас скорость и зачастую некоторые вещи, которые хотелось бы внедрить сейчас — уходят в бэклог.
Несколько раз мы вносили правки в код в режиме онлайн через демонстрацию экрана. На выходе качество получается лучше, чем оставлять комментарии, но такие созвоны отнимают много энергии, особенно при большом количестве правок.
Я понял, что этот метод лучше всего использовать, когда дедлайны горят, и нужно выполнить работу в срок.
- Можно сравнить результат работы в редакторе и в проде;
- Улучшение коммуникации между дизайнерами и разработчиками;
- Понимать результат своей работы;
- Прокачиваться в HTML/CSS. Понимать ограничения разработки
Спасибо, что прочитали данный материал. Надеюсь, он был полезен!
Подписывайтесь на мой Телеграм-канал. Я выкладываю личные находки и интересные материалы относящиеся к дизайну интерфейсов.