Недавно наш клиент сказал: «Нужен новый дизайн ещё вчера» (классика). И нам удалось разработать всё за рекордные 2,5 месяца и не просто выжить помочь бизнесу привлечь инвестиции.

Вместе со Светой, аналитиком Surf, расскажем, как мы это провернули. С примерами, фейлами, выводами и щепоткой боли аналитиков.

Пара слов о проекте

Наш клиент — зарубежная строительная компания, которая не ограничивается кирпичами и бетоном, а реализует проекты «умных» домов с технологиями IoT — интернета вещей.

Сфера проекта = wellness + IoT.

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

Всё это — часть более широкой концепции smart building and healthy lifestyle. Казалось бы, где умные дома, а где ЗОЖ. Да, звучит как два совершенно разных мира. Но такой симбиоз — не эксперимент, а вполне привычная история для некоторых стран. 

Наш заказчик — из США, где подобные сквозные сценарии уже стали нормой. И никого не удивляет, когда технологии для дома адаптируются не только под бытовые привычки, но и под цели по улучшению качества жизни.

Как работает приложение

Один из сценариев — мониторинг жизненно важных показателей с помощью фотоплетизмографии (ФПГ или PPG) и алгоритмов машинного обучения. Так система получает показания пульса, уровня стресса, насыщенности кислородом и других биомаркеров по микровибрациям и цветовым колебаниям кожи лица. Этот процесс занимает от 20 до 60 секунд.

Фотоплетизмография (ФПГ или PPG) — метод оценки капиллярного кровотока, который основан на регистрации изменений объема крови в сосудах при помощи светового излучения. Иными словами, свет (обычно зеленый или инфракрасный) проходит через ткани, и датчик фиксирует изменения в количестве отраженного или проходящего света, которые связаны с пульсацией крови в сосудах.

Ещё один любопытный сценарий. Приложение интегрировано с системой Vivoo — пользователь может сдать анализ в домашних условиях, всего лишь отсканировав тест-полоску с помощью камеры. Алгоритм распознаёт цветовые изменения на реагентах и возвращает рекомендации по питанию, уровню витаминов и общему самочувствию. И всё это — без похода в лабораторию.

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

Как это может быть полезно?

Приложение помогает пользователю отслеживать состояние здоровья и управлять окружающей средой — без лишних устройств и усилий. Всё работает через смартфон и встраивается в повседневную рутину.

Вот такая забота о себе, которая органично встраивается в повседневную жизнь.

Кому это может быть полезно?

Почему мы начали редизайн

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

Бэкенд и дизайн на стороне двух разных вендоров — это White Label (WL) решение, то есть те коробки, которые поставлялись большому количеству заказчиков, и наш клиент стал одним и таких заказчиков. Так то, что мы делали в первой версии приложения, было ограничено возможностями WL-решения.

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

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

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

3. Нет релиза — нет данных. Из-за разрыва отношений приложение так и не вышло в релиз, поэтому не удалось проверить приложение на метриках.

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

И вот тут — сделали всё, как надо. 

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

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

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

Также мы начали интеграцию с системой управления доступом — умными домофонами и дверными контроллерами.

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

Это если коротко. А теперь — в подробностях. С примерами, граблями и находками.

Как подошли к новому дизайну?

1. Сформировали общее понимание

Первый шаг — синхронизация всех участников проекта.

Мы опросили заинтересованных лиц, проверили их ожидания, согласовывали Feature List (кстати, мы уже рассказывали, как его правильно составить).

Определили цели: 

• что меняем; 

• что сохраняем;

• какие проблемы решаем. 

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

Кстати, у нас снова был подрядчик — дизайн-команда из США.

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

• интерфейсы предлагались без учёта ограничений небольших экранов;

• решения выглядели красиво на десктопе, но совершенно не работали в мобильной среде;

• игнорировались базовые принципы доступности и UX;

• комментарии терялись, или трактовались произвольно.

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

Иногда доходило до комичного — например, однажды нам предложили поставить кнопку входа в систему на фоне с градиентом и белым текстом, из-за чего она была полностью невидима. Или использовать шрифт 10px в табах, «потому что красиво».

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

2. Провели аудит и деконструкцию существующего дизайна

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

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

3. Провели ревью нового дизайна

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

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

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

4. Приоритизировали задачи и функциональность

Выделили MVP — поняли, от чего откажемся на первом этапе, а что перенесём на будущие релизы. Дальше — 2 потока:

• новая функциональность;

• редизайн текущей.

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

5. Подготовили и написали технические задания

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

Хорошо, что в команде было двое аналитиков: Света (автор статьи) занималась редизайном, а Юля — разработкой новой функциональности. Иначе мы бы не успели в срок.

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

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

Наш самый «любимый» пример решения проблемы, которую «подарил» бэкенд — запихивать в один JSON-объект с массивом, представленным в виде строки, данные по предпочтениям, которые выбрал пользователь. То есть в этом поле хранится информация о:

• типе телосложения;

• времени пробуждения и отхода ко сну;

• предпочтениях по активностям и отдыху;

• отношении к курению.

И такой вид мы получаем с бэкенда:

{
    "data": {
        "myProfile": {
            "customAttributes": "[{\"name\": \"Boxing\", \"value\": true, \"category\": \"workout preferences\", \"data_type\": \"BOOLEAN\", \"timestamp\": 1746599248918.0}, {\"name\": \"Running\", \"value\": true, \"category\": \"workout preferences\", \"data_type\": \"BOOLEAN\", \"timestamp\": 1746599248919.0}, {\"name\": \"Cycling\", \"value\": true, \"category\": \"workout preferences\", \"data_type\": \"BOOLEAN\", \"timestamp\": 1746599248919.0}, {\"name\": \"Breath Work\", \"value\": true, \"category\": \"recharge preferences\", \"data_type\": \"BOOLEAN\", \"timestamp\": 1746599480455.0}, {\"name\": \"Meditation\", \"value\": true, \"category\": \"recharge preferences\", \"data_type\": \"BOOLEAN\", \"timestamp\": 1746599480455.0}, {\"name\": \"Cognition Sharpening\", \"value\": true, \"category\": \"recharge preferences\", \"data_type\": \"BOOLEAN\", \"timestamp\": 1746599480455.0}, {\"name\": \"Unspecified\", \"value\": false, \"category\": \"Smoker Status\", \"data_type\": \"BOOLEAN\", \"timestamp\": 1747225423278.0}, {\"name\": \"Smoker\", \"value\": true, \"category\": \"Smoker Status\", \"data_type\": \"BOOLEAN\", \"timestamp\": 1747225423278.0}, {\"name\": \"Non-smoker\", \"value\": false, \"category\": \"Smoker Status\", \"data_type\": \"BOOLEAN\", \"timestamp\": 1747225423278.0}]"
        }
    }
}

Решение — полностью избавиться от этого «счастья» и для каждой сущности определить свой параметр с массивом данных. Но тут мы столкнулись с новыми трудностями — бэкенд выставил стоимость переделок, клиента она не устроила. И мы пошли искать новое решение. 

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

В итоге нашли не самое элегантное решение, которое мы между собой прозвали «насилием над customAttributes». Да, всё работает, но смотреть больно.

Какие же были вызовы

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

1. Сложности из-за легаси старого приложения

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

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

2. Интеграция сторонних SDK

На момент редизайна в приложение было интегрировано 6 SDK. Каждый SDK накладывал свои ограничения по UI, логике, правам доступа, обработке ошибок и скорости загрузки приложения.

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

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

В команде даже появился любимый мем:

• Ещё один пример, на этот раз с IoT.

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

Но из-за особенностей интеграции с внешними поставщиками бэкенд работает медленно и нестабильно — задержки достигают 7–10 секунд. 

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

Для полноценной проработки IoT-функций нам нужны были не просто моковые сценарии, а реальные устройства и живые кейсы. Особенно важно было собрать корректную Postman-коллекцию и на практике выяснить, какие именно данные приходят. Ведь документация от поставщика часто расходилась с реальностью.

Клиент подошёл к задаче с размахом: дал нам доступ к своим апартаментам, оборудованным умными устройствами. Так у нас появилась настоящая IoT-лаборатория: мы переключали колонки, меняли температуру, управляли освещением. 

Один раз, правда, смена будильника в рамках теста привела к тому, что клиент проспал встречу — после этого мы особенно внимательно подходили к выбору сценариев ? 

Были и приятные моменты. На одном из созвонов клиент попросил включить свет в комнате, где он находился. Мы включили. Потом выключили. Всё сработало идеально. Клиент был доволен. Мы — тоже.

• UAT и баги при редизайне

Для аналитика погружение в продукт — это работа с реальным приложением: пройтись по сценариям, понять поведение приложения «в бою». Это наша базовая практика. Но в этом проекте всё прошло иначе.

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

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

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

• Параллельная разработка новых фич и редизайна

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

Что дал редизайн

1. Мы улучшили UX

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

2. Наполнили бэклог

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

3. Укрепили доверие со стороны заказчика

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

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

4. Повысили качество кода и стабильность приложения

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

Мы оптимизировали несколько ключевых участков кода, наладили работу с API и закрыли (или почти закрыли) старые технические долги. В результате выросла производительность и значительно повысилась надёжность работы.

Что же мы поняли 

1. Общение спасает

Ранние синки с дизайнером и бизнесом помогли избежать лишней работы. Чем раньше разработка подключается к ревью макетов и ТЗ, тем меньше «сюрпризов» на этапе реализации.

Адекватная коммуникация — это экономия времени и денег

2. Фронт и бэк должны говорить чаще

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

Синхронизация — это красивый Figma-файл

3. Работа с SDK — это отдельный проект

Интеграции со сторонними SDK — это не «вставить библиотеку». У каждого свои ограничения, баги, особенности в UX и документации.

Выделяйте для таких задач отдельное время и ресурсы

4. Легаси — это нормально, если его понять

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

Чужой код — это не страшно. Страшно — не понять, как он живёт

5. Когда аналитика и разработка — друзья

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

Сначала общаемся — потом кодим

Кроме того, аналитик помогает:

• уточнять и фиксировать требования до того, как началась разработка;

• задавать правильные вопросы клиенту — и вовремя ловить несостыковки;

• расставлять приоритеты и не зарываться в «переделать всё»;

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

Короче, аналитик — это фильтр, буфер и медиатор между всеми сторонами. И если он в теме, проект идёт быстрее и спокойнее.

6. Аналитик — это не только про документацию

Аналитик идёт в «полевой» интерфейс. Смотрит, как работает реальное приложение, прогоняет сценарии, а потом — во время UAT — ловит баги до того, как их заметит пользователь. Ну, или параллельно с QA в нашем случае из-за сжатых сроков. Но обязательно стоит обсудить и утвердить с командой QA этот подход ;)

Фидбэк от аналитика в моменте — это меньше факапов на проде

7. Тесты в реальных условиях бесценны. 

Возможность тестировать IoT на реальных устройствах — редкая удача. Это сэкономило дни, если не недели отладки.

 Если работает «в поле» — будет работать у пользователя

8. Юмор и мемы тоже важны

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

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

Не забывайте смеяться. Без этого — никак.

Life is good! Enjoy!

Кейсы и лучшие практики в области системной и бизнес-аналитики, новости, вакансии и стажировки Surf — в телеграм-канале Surf Tech.

Присоединяйтесь!