UIデザインをきちんとエンジニアに伝えるための、イケてる設計資料を定義してみた
この記事はfreee Designers Advent Calendarの20日目です。
こんにちは。freeeのUXチームでデザイナーをしている@ymrlです。freeeでは5年半エンジニアをしたあとデザイナーに異動して、もうすぐ2年半になります。UXチームではデザインシステムやアクセシビリティーまわりのことをやりながら、freeeのプロダクトのUIがより良く、より早く作られるためには何をすればいいのかをずっと考えています。
今回は、そんな中で考えた、デザイナーがエンジニアにUIを作ってもらうときに、作ってほしいものがきちんと伝えられるようになる方法を考えた話をします。
「設計資料って何ですか？」
freeeのアクセシビリティー・チェック・リストは「対象」を「デザイン」「コード」「プロダクト」の3つに分けていて、それぞれデザイナー・エンジニア・QAがチェックを実施することを想定しています。
このなかで「デザイン」の項目にはいくつか、「設計資料」というのが登場していて、デザイナーのみんなに使ってもらうとよく「設計資料って何ですか？」と聞かれるようになっていました。
画像に関する簡潔で過不足ない説明が、設計資料で明示されている。かつ
短いテキストでは充分に説明できない場合には、詳細な説明のテキストが設計資料で明示されている。
見出しとして表現されるべきものが、設計資料で明確になっている。
画像の代替テキストは、その画像がページの文脈の上でどういう意味を持つべきかを考えて書く必要があります。画面上のどの部分を見出しとしてユーザーに伝えるべきかどうかも、画面全体の構成を考えている人が決めるべきでしょう。
freeeのアクセシビリティー・チェックリストでは、これらをHTMLを書く人に押しつけず、あるべき場所の人が責任を持つよう、デザイナーのチェック項目としました。そして、その責任を果たす方法についてはどんなやり方であれやれていれば良いとして、何らかの資料に記載せよという意味で具体的に書かないでおいたのです。
実際のfreeeのUIデザインの業務では、SketchやFigmaを使ってUIモックを作り、それをエンジニアに実装（コーディング）してもらうというやり方がとられています。そして、SketchやFigmaによるUIモックでは、出来上がった画面の見た目しかふつうは表現しないわけで、「この部分は見出しとして実装されているべき」とか「ここの画像の代替テキストはこう」といった情報はどこにも表現されないのでした。
ということで、チェックを実施してくれたデザイナーから、冒頭のように「この設計資料って何ですか？」と次々と聞かれる事態となりました。人によってはチェックリストが「保留」にされ「実装されたら確認」と書かれていたりと、チェック項目の意図が全く汲み取られない状態になってしまっていました。
UIのモックを渡すだけでいいんだろうか
アクセシビリティ以外の部分でも、デザインプロセスの整備や品質向上のためにいろいろな場所に顔を出していると、設計資料に関してほかにも問題意識が生まれてきました。
今年の半ばから、デザインシステムやアクセシビリティー・ガイドラインの作成に関わっているメンバーとして、プロダクトの画面デザインのレビューをやるようになりました（品質エヴァンジェリスト活動）。
その立場で改めてUIモックを見ると、たぶんデザイナーが作っているUIモックだけでは実装に必要な情報が足りないだろうというのが見えてきたのです。情報が足りないので「これは何ですか？」「ここがこうなったらどうなりますか？」というのを聞いていたら、1時間くらい用意していたレビュー会の時間がほぼそれだけで終わってしまうということもありました。
freeeの社内で行われている、デザイナーが関わる開発フローでは、よく「作成したモックに関する口頭での説明」が行われていました。口頭での説明が行われる前提であれば、情報不足のままでもなんとかなるのかもしれません。しかし同じ説明をいろんな人に何度もするのは非効率ですし、あとから開発の経緯を調べていくのも難しくなってしまいます。
さらにデザイナーが作っているUIモックは、理想的な使い方をしているときの状態だけが作ってあるものも多くありました。そこにはユーザーが何も入力していない状態であったり、エラーとなっている状態であったり、普通の使い方より巨大なデータを入力した状態であったりするものは作られていませんでした。
自分がエンジニアだったときは、そういう空白地帯に到達すると、しばしばデザイナーの席まで行って「このUIがこういう状態になったらどんな見た目になればいいですか？」というのを口頭で聞いたり、あるいは相談せずに勝手に補完したものを作ったりしていました。
エンジニアが質問するか、勝手に補完するか、あるいは空白地帯のままにするかどうかは、エンジニアに依存してしまいます。そうなってしまうと出来上がるものの品質をコントロールすることができません。ユーザー体験に責任を持つはずのデザイナーがそういう状況を放置するべきではないはずです。
「イケてる設計資料とは」を定義しよう
そういう問題意識から「イケてる設計資料」の定義をすることにしたのですが、当初は、私が以前から「実装指示をUIモックに細かい字で書き込む」ということをやっていたので、それをみんなにも広められないか、と考えていました。
しかしこれをデザイナー何人かに勧めてみたところ、あまりピンと来ていないようでした。なんでだろうねということを @magi1125 に聞いてみたところ「これはymrlの長年の実装経験によるエスパー能力があるから書けるもので、そういう経験が無いデザイナーには何を書けばいいのかわからないのでは」という意見を貰いました。
たしかにそうかもしれないということで、逆に自分がデザイナーに書いてほしかったものをリストアップしたものをベースに設計資料に記載されるべきものをまとめることにしました。
それに、UI Stackのそれぞれの状態のアートボードを作っておくべきという話や、アクセシビリティー・チェックリストで「設計資料」の記載を求めているものも必須で記載するようにという話を加えて、「イケてるUI設計資料を作ろう」という社内ドキュメントにまとめました。
イケてる設計資料のためのツールを用意する
さらに、イケてる設計資料を簡単に作れるよう、lib_patwahという社内Sketchライブラリを用意しました（すぐに @hrtnde がFigmaにも移植してくれました）。これはイケてる設計資料に書き込まれているべきとされているものを、デザインツール上に簡単に貼り付けられるようにしたものです。
patwah（パトワ）という名前は、ジャマイカのクレオール言語から取りました。エンジニアとデザイナーという異なる文化が交わる場所での橋渡しの言葉となることを期待しています。
デザインツールの上で注釈を貼りつけるというアイデア自体は、IndeedのA11y Annotation Kitを参考にしました。freeeのUIデザインの現場では社内コンポーネント集であるVibesのパーツを組み合わせてUIモックを作ることが多く、メンバーもHTMLのコーディングにあまり詳しくないため、A11y Annotation Kitよりも用途を絞った（そしてボタンの挙動を表現するものなども足した）ものを作成しました。
設計資料の定義をやってみて
この設計資料の定義とlib_patwahは、自分が思っていた以上にすんなりとプロダクトデザイナーのみなさんに受け入れてもらえて、特にlib_patwahはかなり活用してもらえています。デザインの品質を高めるためのレビュープロセスの中でもこうした設計資料を作ることが前提になっています。
しかしながら、その使われ方にはまだ疑問が残るものがあって、「注釈を付けていくのが大変」という声をちらほら聞いたり、私の想定していたよりもかなりたくさんの注釈をつけているUIモックを見たりしています。デザイナーの立場からすると、どの程度の情報をUIモックに付加すればよいのか、必要最低限のレベルがどの高さであるのかがわかりにくく、結果としてたくさんの情報を書き込むようになってしまっているようです。
また、Vibesとして提供している既存のUIコンポーネントを並べてUIモックを作るうえで必要になるものは提供できているのですが、新たにUIコンポーネントを定義するにはまだ足りなさを感じています。イケてる設計資料のドキュメントには、「マウスオーバーやフォーカス時の見た目を定義する」「サイズの指定や長大な文字列が入った場合の見た目を定義する」「その他、いろんな表示パターンを検討したものを付けておく」といったことは書いていますが、それらの具体的なやり方についてはあまり触れられていません。
このあたりをもっとスムーズにできるようになるには、究極的にはデザイナーとエンジニアがお互いをもう少し理解して、お互いの役割に必要なものを把握している状態になるのが理想なはずです。しかし、デザイナーがエンジニアの仕事を体験しようにもコーディングに参加する敷居はかなり高いですし、エンジニアにデザイナーの考えていることを全部説明して理解してもらうのも大変なことです。そのギャップを、少しでも埋めていけるやり方を、来年も考えていきたいなと思っています。
明日はfreeeの新しくなったブランドコア表現を社内に広めている、Eri Hoshiさんです
この記事が気に入ったらサポートをしてみませんか？