見出し画像

UI改善のためにエンジニアに仕様を構造化してもらったら再設計がめちゃくちゃ捗った話

鈴木 健一 / PLAID & Ex.STANDARD
この記事はPLAID Advent Calendar 9日目の記事です

UI改善の前提理解、うまくできていますか？

皆さんはこれまで着手してこなかった既存画面のデザイン改善をする時、どのように進めているでしょうか。

自分がプレイドで所属しているreBAISUというチームでは、タタキとして定義したスタイルガイドを旧来の画面に適用しながらUI改善する取り組みをしています。

取り組み方として、改善対象となる画面の仕様を理解しながら課題を見つけ、解決策を検討していく流れになるのですが、この仕様理解が難しいと感じていまして。

なんとか前提理解を促せる方法はないものかと検討した結果、対象画面の構成要素をひとつずつ紐解いていく方法で理解していく「デザインの逆行分析」という方法をとっていました。


デザインの逆行分析とは

「リバースエンジニアリング」とも呼ばれる手法で、その考えをデザインでも応用しようというものです。具体的には、既存画面に存在している要素をひとつずつ見ながら「見える情報」と「できる操作」のような形で分解する作業を行っていました。

画像1

これらを洗い出していくことにより、その画面で担保すべき情報と操作を網羅していけると思っていました。

良さそうなアプローチだなと感じていたのですが、画面上の要素をひとつひとつ知れる一方で、画面上で見えていない暗黙的な仕様については知ることができず、UIの改善案を作ったはいいものの、開発フェーズで検討漏れがあったことがわかり、手戻りや再検討が必要になってしまうことがありました。


仕様の調査をエンジニアメンバーにお願いした

そうした事情を踏まえて、次の改善施策の際には、初めに既存機能に関する調査をエンジニアさんにお願いし、可視化してもらうことにしました。

改善対象となる画面はKARTEの「接客サービス作成フロー」という画面で、サイトやアプリの利用者に対して届けるコンテンツの配信条件を指定するための画面になります。

画像2

この画面は、お客様が契約しているプランややりたい事によって表示される入力/選択フォームが変わる画面になっていて、自分が見えるものだけを手がかりに仕様を理解していくと、取りこぼしが生まれてしまう懸念がある画面でした。

そこでreBAISUチームエンジニアの藤川さん（atsushi.fujikawa）にお願いしたのが、対象画面で表示される情報がどのような条件で出し分けられているのかを調査してもらうことでした。


仕様を図示し、構造として捉える

そうして調査してもらったものが次の図になります。

画像3

図の中では、対象となる画面に関係するオブジェクトや、作成しようとしているコンテンツの性質による条件分岐（Web上に表示するコンテンツなのか、メールやLINEのようなWeb外のコンテンツなのか）、契約しているプランによる分岐などが枝分かれする形で図示されていて、それぞれのステップで現在どんな情報を設定していくのかがわかりやすい形でまとまっていました。

見える情報や設定できることを構造として捉えられることによって、項目の移動や分岐ポイントの改善を踏まえた再設計が格段にしやすくなりました。実際に、改善案を検討していく中で、取りこぼしてしまった情報を最小限に抑えることができたように思います。

また、自分だけでなくチームメンバー全員が仕様に対する理解の土台を作れたように感じていて、一つ前のプロジェクトよりも、設計に対するフィードバックや意見が活発にでき、建設的にブラッシュアップできたように思いました。

このような調査のプロセスを挟むことによって、仕様理解の網羅性が劇的に上がることに気づけた出来事でした。


デザインはデザイナーだけがやるには重要すぎる

インターフェース設計やソフトウェア開発のような領域はそれ単独で存在しているわけではなく、ソフトウェアデザインという一つのテーマとして捉えられる取り組みだと感じています。

利用者に対してより良い体験を届けていくためには、いわゆるデザイナー1人ができることは限られていて、今回のようなエンジニアメンバーによる支援や、SaaSの文脈で言うとセールスやカスタマーサクセスのメンバーとの密な連携によって実現されていくものだと感じています。
一緒に実施してくれたチームメンバーに感謝しつつ、これからも一緒により良い体験をデザインしていきたい気持ちです。

明日ははぎちゃん（hagipen）による「Lookbackを使ってユーザビリティテストをしたらとても良かった話」です。


2019/12/10追記
公開されました🎉


いいなと思ったら応援しよう！