Перейти до вмісту
Усі матеріали
Про RÓSA

Як працює новий процес передачі RÓSA

Від оголошення до підтвердженої доставки: три ролі, два коди та зрозумілі сценарії помилок.

Євген Радецкій

Я перебудовую RÓSA екран за екраном, і це оновлення поки найкраще показує, як має працювати продукт. Складність не в тому, щоб намалювати ще одне оголошення. Треба зробити так, щоб кожен розумів наступну дію, свою відповідальність і момент, коли річ справді перейшла до іншої людини.

Одна подорож, три різні ролі

Оберіть учасника, щоб побачити його частину передачі

01

Відправник

Створює оголошення, описує річ, додає фотографії та погоджує місце й час першої зустрічі.

Три екрани RÓSA для відправника, мандрівника й одержувача
Кожен учасник бачить свою інформацію та наступну дію, а не однаковий набір кнопок.

Від публічного оголошення до реальної передачі

Відправник показує, що потрібно доставити, а мандрівник публікує майбутній маршрут. Коли дати, напрямок і умови підходять, розмова переходить у приватний чат конкретної передачі. Домовленість не губиться серед повідомлень: вона залишається пов’язаною з річчю, маршрутом і людьми.

Пройдіть п’ять етапів

01

Оголошення

Що передаємо, звідки й куди, коли, у якому стані та з якими обмеженнями.

Чотири екрани RÓSA від створення оголошення до завершення передачі
Окремі екрани показують не лише результат, а й місце користувача в процесі.
Мобільний особистий кабінет і приватний чат передачі RÓSA
Особистий кабінет і чат залишаються частинами однієї передачі, навіть на вузькому екрані.

Чому RÓSA використовує два різні коди

Один код змішав би дві різні події. Перша відбувається, коли відправник передає річ мандрівнику. Друга — пізніше, часто в іншому місті або країні, коли мандрівник віддає її одержувачу.

Порівняйте два підтвердження

Перша зустріч

Код приймання

Після спільного огляду відправник показує код. Він фіксує, що мандрівник прийняв річ, але не підтверджує кінцеву доставку.

Екрани коду приймання та коду доставки у RÓSA
Два коди відповідають різним людям, місцям і моментам зміни відповідальності.

Що відбувається за шістьма цифрами

АВТОРИЗУВАТИ → ПРИВ’ЯЗАТИ ДО ПЕРЕДАЧІ ТА ЕТАПУ → ПЕРЕВІРИТИ → ВИКОРИСТАТИ ОДИН РАЗ → ЗАПИСАТИ РЕЗУЛЬТАТ

Це пояснювальний псевдокод, а не частина виробничого коду. Самого числа недостатньо: сервер має перевірити акаунт, передачу, етап, учасника та строк дії. Після успіху підтвердження споживається, а повторний запит повертає вже записаний результат замість створення другої передачі.

Безпечний процес потребує сценаріїв помилок

Подивіться, як система має реагувати

Неправильний код

Інтерфейс пояснює, що значення не збігається, і не змінює стан передачі.

Стани неправильного, простроченого та нового коду
Успішний екран простий. Якість процесу видно з того, як він поводиться, коли щось іде не за планом.

Що вже існує, а що ще потрібно перевірити

Ці екрани є редагованим прототипом. Вони визначають ролі, стани та сценарії відновлення, але не доводять, що кожне правило вже забезпечує виробничий сервер. Справжні платежі та доставки в демонстрації не активовані.

  • Перевірити серверне виконання правил і одночасні запити.
  • Пройти сценарій на окремих пристроях та акаунтах усіх трьох учасників.
  • Перевірити втрату з’єднання до і після серверного підтвердження.
  • Не записувати чутливі матеріали підтвердження в журнали або публічні відповіді.

Я показую роботу зараз, тому що логіку ще можна покращити. Краще знайти незрозумілий крок або відсутній сценарій у прототипі, ніж під час справжньої передачі.

Усі матеріали