---
publishYear: 2020
name: Easydocs
title: Интерфейс приложения для проверки и подписи документов
excerpt: Разработали дизайн приложения, в котором руководители компаний могут читать документы и подписывать их электронной подписью.
context: У заказчика уже было мощное веб-приложение для работы с документами, так что в продукте он разбирался хорошо. А в мобильном приложении хотел использовать всего один сценарий.
logo:
src: ~/assets/images/portfolio/easydocs/logo.png
alt: Easydocs logo
link: https://easydocs.ru/
image: ~/assets/images/portfolio/easydocs/easydocs.png
imageAlt: Интерфейс приложения для проверки и подписи документов
thumbnail:
src: ~/assets/images/portfolio/cards/easydocs.svg
alt: Собака Павлова • EasyDocs • Дизайн приложения для проверки и подписи документов
tags:
- it
- ux-design
- mass
- mob
tags2:
- IT для бизнеса
- СЭД
- UI-дизайн
- Мобильный интерфейс
relatedPages:
- text: |
### Вам нужен интерфейс?
#### Заказать дизайн
Напишите нам на [we@sobakapav.ru](mailto:we@sobakapav.ru)
#### Что мы можем сделать?
[UX-design под ключ](/services/ux-design), как в этом кейсе, и [многое другое](/services).
collection: services
page: ux-design
- text: |
### Хотите сделать сами?
Научим создавать хорошие интерфейсы.
collection: promo
page: mio
- collection: promo
page: uc
- collection: promo
page: focus
relatedPages2:
- text: |
### Похожие проекты
collection: portfolio
page: simplefly
- collection: portfolio
page: control-patent
- collection: portfolio
page: smartdeal-ecp
- collection: portfolio
page: control-forest
- collection: portfolio
page: easydocs
- collection: portfolio
page: edms
result:
- src: ~/assets/images/portfolio/figma.svg
text: Финальные макеты
link: https://www.figma.com/design/6OV8oQIqAoLxOlMvMFOA5Q/Paradocs-2.0_outbox?node-id=0%3A1
budget: ~ 900 000 ₽
review:
text: «Понравился вдумчивый подход и ритмичность работы. Дизайнеры всегда возвращались в срок с результатом и драйвили процесс так, что мы прошли много итераций и закончили в срок, не превратив процесс изменений в бесконечный».
photo: ~/assets/images/portfolio/easydocs/person.jpg
person: Алексей Кузнецов
position: Основатель
director: Профессиональный заказчик — отличный результат
metadata:
canonical: https://sobakapav.ru/portfolio/easydocs
title: СЭД • Интерфейс приложения для проверки и подписи документов
description: "Разработали дизайн интерфейса мобильного приложения для руководителей, в котором реализовали всего один пользовательский сценарий: читать документы и подписывать их ЭЦП."
robots:
index: true
follow: true
openGraph:
site_name: Собака Павлова
images:
- url: '~/assets/images/portfolio/easydocs/easydocs.png'
width: 1680
height: 501
type: website
---
import Image from '~/components/common/Image.astro';
import TOC from '~/components/widgets/TOC.astro';
import PhoneMockup from '~/components/widgets/PhoneMockup.astro';
<TOC>
[Заказчик](#anchor1) • [Процесс](#anchor2) • [Фокус на контрагентах](#anchor3) • [Фокус на документах](#anchor4) • [Сценарии](#anchor5) • [Дизайн интерфейса](#anchor6) • [Тестирование](#anchor7) • [Результат](#anchor8) • [Отзыв, цены, сроки](#anchor9)
</TOC>
## <a name="anchor1" />Заказчик
Easydocs — платформа для кадрового и электронного документооборота. Это не стартап, у компании-разработчика уже есть клиенты, которые пользуются веб-версией продукта. А вот мобильной версии пока нет — за дизайном Easydocs и обратились в «Собаку».
В приложении заказчик решил ограничиться минимумом функций. Фактически сделать инструмент для руководителей, в котором документы можно только читать и подписывать. А создавать — в веб-версии.
В принципе этим вводные и ограничивались. Нужно создать дизайн, который закроет этот сценарий. До некоторого момента сама гипотеза, что бизнесу нужно приложение, в котором можно подписывать документы, была ничем не подтверждена.
## <a name="anchor2" />Процесс
Начали, как обычно, с аналитики. Изучили веб-версию и составили карту функциональности продукта, чтобы зафиксировать все возможности и ничего не потерять.
_[Карта функциональности](https://miro.com/app/board/o9J_kvIw6xY=/)_
Еще посмотрели конкурентов — близкие Easydocs по тематике приложения, которые рассчитаны всего на одно действие.
А потом взялись за концептуальное проектирование.
Весь сценарий выглядел так: увидеть, что появились документы на подпись, прочитать и подписать. Мы его даже нарисовали на доске.
_Первые наброски мы всегда делаем на доске, чтобы не тратить время на лишнюю для этого этапа детализацию_
Но хоть сценарий и один, на него можно смотреть под разными углами. Поэтому мы сделали несколько разных концептов.
## <a name="anchor3" />Фокус на контрагентах
В этом концепте пользователь заходит в приложение и видит список контрагентов с последним документом от каждого. Интерфейс выглядит как мессенджер или почтовый клиент. Пользователь кликает на контрагента и попадает в список документов. Любой из них можно раскрыть одним кликом.
_Все документы по контрагенту видны на отдельной странице. Каждый документ можно открыть отдельно и прочитать в полном размере. Либо повернуть экран — тогда увеличится масштаб_
Еще один подход — уже без последнего документа в карточке контакта. Просто список контрагентов. Пользователь нажимает на контакт и попадает в папку, где собраны все входящие, исходящие и архивные документы.
_В этом концепте входящие документы видны сразу, а исходящие и архивные лежат в отдельных папках_
Третий вариант — с шаблонами документов. Пользователь проваливается в папку контрагента, но внутри уже может наводить порядок на свой вкус. Впрочем, приложение умеет группировать документы по типам: договоры, счета, акты и тому подобное.
Если в первом случае пользователь мог добраться до документа в два клика, то здесь надо кликнуть три раза. Но это не страшно — мы пока находимся на уровне идей.
_В этом концепте даже входящие документы лежат в отдельной папке_
Четвертый подход — сгруппировали контакты по алфавиту, а рядом с каждым указали количество документов. Внизу добавили меню.
_В этом концепте папок нет вообще_
## <a name="anchor4" />Фокус на документах
Возможно, пользователю удобнее смотреть сразу документы, а не контакты. Поэтому в следующем концепте мы сфокусировались на них.
Мало того, у пользователя может быть несколько бизнесов, а приложение всего одно. Поэтому мы сделали верхнюю навигацию по компаниям и для каждой показали относящиеся к ней документы с указанием контрагента.
Поэкспериментировали с UI: показали контрагента выше документа серой плашкой и ниже — маленьким серым текстом, сделали переключатель между входящими и исходящими документами.
Внизу — основная навигация.
_Пользователь заходит в приложение и сразу видит список документов_
Следующий вариант очень похож на самый первый. Пользователь попадает в список контактов, под каждым указан последний документ. Отличие в том, что список контактов формируется по последним документам, а не по алфавиту.
Пользователь кликает по карточке контрагента и переходит сразу в документ. Всего в один клик.
Возможно, вы обратили внимание, что документ набран очень мелким шрифтом. Но увеличить текст в нем нельзя. Разработчики сказали, что это очень сложно и не стоит усилий. Во всяком случае, пользователь может повернуть телефон горизонтально — тогда документ прочитать будет проще.
_В этом концепте мы предположили, что руководителю важнее увидеть не последние документы, а найти контрагента по алфавиту_
Следующий заход — с фокусом на типы документов. Группировка помогает ускорить поиск: можно сразу перейти к счетам или актам, не ища их в длинных списках.
_А может, руководителю будет проще найти документ по его типу?_
Концепт с предпросмотром документов. Пользователь заходит и сразу видит, что это за документ и что в нем написано. Один клик — и файл разворачивается на весь экран.
_Зашел в приложение, а там сразу лента документов «в полный рост»_
Самый смелый заход — с механикой Тиндера. Пользователь заходит в приложение, а оно ему сразу подсовывает случайный документ. Можно подписать и получить следующий случайный док. И так до тех пор, пока пользователь не подпишет каждый.
Впрочем, список документов всегда можно развернуть, чтобы выбрать нужный.
_Тиндер для документов. Заказчик от этого концепта отказался_
## <a name="anchor5" />Сценарии
Концепты — это хорошо. Но все же мы не понимали до конца, как обращаются с документами руководители компаний. Поэтому провели кастдев.
_[Гайд для интервью](https://docs.google.com/document/d/1M4DXNDRMQmYvJ7xRFgGLSO6lhnMv-9PU1kRyihucs-E/edit)_
К тому моменту мы уже подготовили концепты, поэтому хорошо понимали, что нужно спрашивать. С этим гайдом взяли интервью у четырех бизнесменов. Аналитика помогла подтвердить часть наших теорий, еще лучше разобраться с приоритетами и подготовить микросценарии приложения.
_Самое важное подчеркнули_
В интервью мы выделили основные действия. Они и стали основой микросценариев
_Всего мы подготовили 18 микросценариев_
Микросценарии и шаги микросценариев, описанные во второй колонке, — это буквально проектирование текстом. На их основе мы и разрабатываем интерфейсы. Позже эти же микросценарии можно использовать, чтобы проверить качество дизайна: что работает, что не работает, все ли возможные действия пользователя мы учли.
>Use cases — пользовательские сценарии, сценарии взаимодействия, сценарии использования, пользовательские сценарии — последовательное описание поведения человека при взаимодействии с системой и системы, когда с ней взаимодействует человек. У нас есть [модуль дизайн-задачника «Сценарии взаимодействия»](https://www.eduhund.ru/program/usecases/?utm_source=sobakapav&utm_medium=site&utm_campaign=page) для тех, кто хочет научиться их использовать в дизайне интерфейсов.
А вот сценарии мы взяли у заказчика. Он уже все подготовил, осталось только пользоваться. Позже мы вместе прошлись по каждому сценарию и решили, что будем реализовывать, а что — нет.
_Заказчик подготовил сценарии в Miro — удачное совпадение, мы тоже им пользуемся на каждом проекте_
Так. А чем отличаются сценарии и микросценарии? Сейчас объясним.
Представьте, что вам нужно сходить в магазин за продуктами. Сценарий опишет, как вы выйдете из дома, зайдете в магазин, наберете продукты, оплатите их и пойдете домой. А микросценарий спрячется внутри сценария и опишет, как вы выясните срок годности у творога.
_Все сценарии выписали в документ и подписали, какие берем или не берем в разработку_
Таблица из Airtbable превратилась в карту приложения и карту фокусов.
_[Карта фокусов](https://miro.com/app/board/o9J_kutxtMY=/)_
>Фокусы — это функциональные элементы, важные для работы интерфейса, точки, где реализуются основные сценарии, которые выполняют сразу много задач или хотелок пользователя или бизнеса. Если интересно, почитайте [статью про карту фокусов](/publications/focus-card).
>
>И еще у нас есть про них [модуль дизайн-задачника «Интерфейсные фокусы»](https://www.eduhund.ru/program/focus/?utm_source=sobakapav&utm_medium=site&utm_campaign=page), но он только для тех, кто уже освоил более простые инструменты дизайна: [модели информационных ожиданий](https://www.eduhund.ru/program/io/?utm_source=sobakapav&utm_medium=site&utm_campaign=page) и [сценарии взаимодействия](https://www.eduhund.ru/program/usecases/?utm_source=sobakapav&utm_medium=site&utm_campaign=page).
## <a name="anchor6" />Дизайн интерфейса
Мы взяли стандартный фреймворк для iOS и сделали версию для айфонов, а потом адаптировали ее для Android.
Все макеты делали сразу в дизайне.
_[Макеты в Figma](https://www.figma.com/file/6OV8oQIqAoLxOlMvMFOA5Q/Paradocs-2.0_outbox?node-id=0%3A1)_
Подписали каждый шаг пользователя. В каждом сценарии сразу видно, что он делает и почему.
_Мы подписывали каждое действие и сразу показывали, что будет, если пользователь пойдет не по основному сценарию_
В этом проекте нам попался очень профессиональный заказчик.
Во-первых, он был глубоко погружен в свою систему — такое не всегда встретишь. Иногда заказчики имеют поверхностное представление о продукте и надеются, что мы все [продумаем за них](https://sobakapav.ru/publications/dont-mix-up-product-and-interface). Во-вторых, давал ценные комментарии и предлагал удачные решения, в том числе и интерфейсные. В-третьих, дотошно изучал нашу работу и задавал много вопросов, которые заставляли нас подумать. Так что в этом проекте, можно сказать, он стал частью команды «Собаки» и активно влиял не только на результат работы, но и на процесс. Дизайн получился совместным.
С другой стороны, заказчик на нас не давил и доверял компетенциям дизайнеров. То есть не пытался рисовать нашими руками. Вот показательный пример.
_Мы не только подписывали действия пользователя, но и объясняли поведение приложения в квадратных плашках_
В продукте есть сценарий добавления нового контрагента. Пользователь вводит ИНН, а остальные данные подгружаются из общедоступной базы данных и сами заполняются в нужные поля. Кроме одного — электронную почту нужно написать самому. И пока это поле пустое, добавить контрагента нельзя.
В веб-версии форма длинная, а кнопка «Продолжить» находится в конце страницы. Пользователь, когда будет скроллить экран, увидит поле для e-mail и отметку, что его надо заполнить. Поэтому заказчик сделал кнопку активной. Если на нее нажать, поле с электронной почтой станет красным и подскажет, что его тоже нужно заполнить. В таком контексте это выглядит как просьба быть повнимательнее.
А вот в приложении все не совсем так. Да, форма тоже длинная, но кнопку «Продолжить» видно сразу, потому что она плавающая и приклеена к нижней границе экрана. Поэтому некоторые поля скрыты внизу. Заказчик настаивал на том, чтобы оставить кнопку активной, как в веб-версии. Но тогда получилось бы, что некоторые пользователи просто не увидят поле e-mail и будут нажимать кнопку, а приложение начнет ругаться: «Введите электронную почту». Согласитесь, контекст уже совершенно другой, а опыт неприятный.
_Обратите внимание на поле e-mail — в приложении оно находится ниже кнопки, приклеенной к экрану_
Мы настаивали на том, что кнопка должна быть неактивной. Это популярный паттерн: так система дает пользователю понять, что еще что-то хочет от него. Заказчик сначала возражал, и у нас были довольно интересные дискуссии на этот счет, а потом согласился с решением «Собаки».
Так мы и работали. Подготавливали макеты сценария, обсуждали, переходили к следующему. Постепенно закончили версию для iOS и адаптировали ее под Android.
_Глобальных отличий в Android-версии нет, только UI_
## <a name="anchor7" />Тестирование
На тестировании мы решили пройтись по самым важным сценариям в приложении и попросили респондентов:
- подписать документ;
- создать документ из файла;
- добавить новую организацию;
- добавить электронную подпись;
- найти и скачать заявление для электронной подписи;
- удалить организацию;
- изменить тарифный план
К тому моменту уже началась эпидемия, поэтому мы проводили [тестирование удаленно](https://sobakapav.ru/publications/user-testing-online).
_Да, в тексте есть ошибки. Ну так и документ внутренний_
Всего мы протестировали семь сценариев, сразу же сделали выводы и подготовили рекомендации. После обсуждения с заказчиком по трем первым внесли правки в макеты, а последнюю рекомендацию на время отложили — в ней предлагали добавить новую функцию.
_Да, в тексте есть ошибки. Ну так и документ внутренний_
## <a name="anchor8" />Результат
Заказчик поблагодарил нас за приятную работу, забрал макеты и ушел разрабатывать приложения под iOS и Android.
## <a name="anchor9" />