
できるだけUIを作らない(新規作成画面編)
貿易管理 SaaS を提供している Shippio でプロダクトデザインを担当している toofu です。
最近、機能開発・改善をするときに「なるべく UI つくりたくないなあ」と思うことがよくあるので、その考えを事例とともに共有させてください。
メインオブジェクトの作成機能を設計しました
先日、Shippio のメインオブジェクトである「シップメント(貿易案件的なもの)」の作成機能をリリースしました。
メインオブジェクトの作成機能がなかったの…?と思われるかもしれませんが、Shippio にはシップメントを画面上で作成する機能がなく、外部データをインポートすることしかできませんでした。
「プロパティが多い貿易案件をすべて手入力していくよりも、ユーザーが普段の業務で管理している Excel 上の貿易データをそのままインポートしてもらうほうが、より業務効率化に近づくはず」というプロダクト開発初期の仮説がありました。そのため、画面上でシップメントを作成できるようにするよりもインポート機能が優先して作られ、その後しばらく画面上での作成機能は存在しなかったのです。
ですが、(嬉しいことに)ユーザー数が増え、さらにユーザーの業務が Shippio を前提としたものに変わってくると、逆に「インポートを行うための Excel データを作成することが面倒」「案件が発生したらすぐ Shippio に登録したいので、まとめてインポートよりも画面上でサッとつくりたい」というニーズが強くなってきました。そこで、満を持して「シップメントを画面上で作成できるようにする」開発に着手することにしました。
「新規作成画面」を作らないつもりでした
UIの方針として、最初に「新規作成画面」を作らない方針を立てました。必要な情報を諸々入力してからデータを作成するのではなく、まずデータを作成して、そのあと必要に応じて情報を入力してもらう、という方針です。

これには大きく言うと2つ理由があります。
すでに編集 UI はあるので、それを使いまわしたかった
同じことをする UI (API も)はなるべく統一するほうが、メンテナンス性はあがりますし、ユーザーの学習コストも下がると考えています。
価値を体感できるまでの時間を短くしたかった
ユーザーはデータを作成したいのではなく、そのデータで何かしらの業務を効率化したいと考えているはずです。そして「このツールを使えばこんな感じで業務効率化できそう」は、作成画面よりも作成されたデータを見ることでイメージできるようになるはずです。そのため、ユーザーが価値を感じる手前の「データ作成」で手間を取らせるのではなく、すぐに価値を感じられる画面まで進んでもらえるようにするべきだと考えました。
UI 作りたくない気持ち vs 取り扱うものの複雑さ
本当は「作成」ボタン押したら即座にレコードが作成されるフローを考えていました。が、下記の事情から、作成 UI を作ることになってしまいました。
データベース上必須の項目が多い
貿易には種々の形態(船便とか航空便とかコンテナ貸し切りとか相乗りとか云々)があり、同じ「シップメント」といっても、その形態に応じて取り扱われる情報が変わるケースがあります。そのため、その前提となる貿易の基本情報はデータベース上も必須項目となっていました。さらに実装上の制約により、一度作ったシップメントの基本情報は変更できないため、「作成ボタンを押したらまずレコードが作成される」を実現するのが難しいという結論になってしまいました。「UI を作らない」を実現するには、根本の仕様からシンプルにしていく必要があるようです。今回は最小限の作成 UI を作る方針に切り替えました。
そのオブジェクトの更新 UI が複数画面に渡っててめんどくさそう

作成した後にユーザーが入力したい項目も多岐にわたるため、ローカルナビゲーションを行き来してそれらを入力するのは非常に面倒だろうなという仮説が生まれました。(そういった複雑な UI になっていること自体に改善の余地は大いにあるのですが)
そのため、「価値を感じるまでの時間を短くする」の大方針から、「作成直後の画面遷移をなるべく減らすために必要な項目を作成 UI に含める」かたちで UI を作成し、開発に進みました。
で、どうだったのか
「作成 UI をできるだけ最小限にする」という設計方針は開発メンバーからも賛同を得られ、開発を担当してくれたエンジニアからは “great example” というあたたかい言葉をもらいました。
Shipment creation is a great example of how to reuse existing parts of our system instead of creating something completely new!
また、Shippioにアカウントが作成されてから、そのユーザーがシップメントを作成するまでにかかる時間は、この機能をリリースする前後でおよそ半分ほどになっていました。Shippio はハイタッチで顧客接点を持っている BtoB サービスなので、このあたりはプロダクト改善のみの結果であるとは言えません(むしろセールスやカスタマーサクセスメンバーの取り組みに拠るところのほうが大きいと思う)。ですが、「プロダクトの価値を体感できるまでの時間」は間違いなく短くなっていると言えます。
とはいえ、いざ使い込んでくれているユーザーからするとまだまだ冗長な手順になっているので、その要因となっている複雑性を取り除いていきたい欲求があります。UI をシンプルに保つことで、開発者である我々自身のメンテナンス性や、使い始めるユーザーの Time to Value だけでなく、使い続けてくれているユーザーにとっての価値も継続的に出し続けられるはずなので。
さいごに
みんな、UI は必要最小限にしていこうな…!
あと、こういったUI設計について他の人と話してみたいと常々思っているので、よければぜひお声がけください!