こんにちは、サイボウズのkintone開発チームでデザインテクノロジストをしている小林大輔（@sukoyakarizumu）です。デザインテクノロジストとは、デザイナーとエンジニアの間に立ち、デザインと実装のコミュニケーションの橋渡しを共におこなう職種です。
デザインテクノロジストの業務のひとつは、デザイナーさんが日々作る画面やUIのデザインプロトタイプについて、エンジニアリングの視点からアドバイスやレビューをすることです。この記事では、デザインテクノロジストである私が、デザインをどのような観点でレビューしているか、またどのような心構えでレビューしているかについてお伝えします。

デザインをレビューする観点

観点１：開発が容易かどうか

プロトタイプによっては、開発コストがかかることが容易に予想できる場合があります。たとえば以下のような場合です。

• 独自のコンポーネントが使われている場合: 既存のコンポーネントの組み合わせではなく、全く新しいコンポーネントを作る場合は、コンポーネントの設計や実装に多くのコストがかかります。

• 独自の画面設計が行われている場合: デザインされた画面の構成が今までに実装した画面と大きく異なる場合は、既存の実装を使い回しづらくなるため、実装にコストがかかると予想できます。

• 複雑な操作が必要な場合: 複雑な操作は開発コストがかさみ、不具合も発生しがちです。たとえばドラッグ＆ドロップや複数のキー入力のサポートなどです。

必要以上に開発コストがかかると予想できる場合に、デザインテクノロジストは、複雑な操作を簡単な操作に置き換えられないかデザイナーさんに相談します。また独自コンポーネントではなく既存のコンポーネントで置き換えたり、既存コンポーネントの複数の組み合わせで代用できないか提案することもあります。

観点２：開発計画に従っているか

開発チームは大きな開発計画にのっとって動いています。開発のフェーズによっては、ユーザビリティや審美性を追求する一方で、開発容易性とのバランスを考慮しなければならない局面があります。そのバランスが適切であれば今後もデザインを改善し続けることができます。逆に「今」のデザインにこだわりすぎてバランスが崩れてしまうと、今後デザインを改善し続ける挑戦権を失ってしまうこともあります。
観点1にも関連しますが、典型的なのは、使い勝手を意識して新しいコンポーネントを作ろうとしている場合です。一度開発したコンポーネントは、開発チームが継続してメンテナンスし続けなければなりません。メンテナンスコストが高ければ、そのコンポーネントのデザインをさらに改善しようとしても難しい場合があります。（もちろん、将来コストを支払うことを見越した上で、新しいコンポーネントを開発して使い勝手を追求しなければならない場合もあります。）
デザインテクノロジストは、開発計画を理解し、デザイナーさんが開発計画に即した適切な成果物を出せるようにフィードバックしています。デザイナーさんによっては、単にデザインのクオリティの下げているように感じてしまうこともあるので、フィードバックするときには、現在の開発のフェーズや今後デザイン改善できる余地などを合わせてお伝えするようにしています。

観点３：一貫性が保たれているか

製品の中でデザインの一貫性が保たれているかどうかはとても重要です。
デザインテクノロジストは、製品の一貫性を保つためにデザインシステムを開発しています。このデザインシステムには以下のような内容が含まれています。

• コンポーネント: 製品のさまざまな箇所で使う典型的なコンポーネントがまとめられています。

• デザイントークン: 製品で使う基本的な色、大きさ、余白、タイポグラフィ、シャドウなどがまとめられています。

• ガイドライン: デザインするときの基本的なルールがドキュメントとしてまとめられています。

デザインテクノロジストは、デザインシステムを最大限活かして、今までのデザインを踏襲できないかデザイナーさんに提案します。
デザイナーさんと議論しているうちに、今までデザインシステムでは管理していなかったものの、ガイドラインとしてまとめるべきルールやコンポーネントが登場する場合もあります。そういった場合はデザインシステムを更新し、今後のデザインでより一貫性を保ちやすくしています。

観点４：ユーザビリティやアクセシビリティを高められる余地がないか

デザインテクノロジストは、エンジニアリングの視点から、ユーザビリティやアクセシビリティの問題に気づける場合があります。よく発見される問題を挙げます。

• 一部のユーザーにとって操作が困難になる: 複雑なUIの中には、マウスで操作できたとしても、他のデバイス──たとえばキーボードでは操作しづらい／操作できない場合があります。
  また、用途に特化したようなオリジナルなデザインのUIが提案された場合、適切にマークアップすることが難しい場合があります。特に、他のデザインシステムやAPG（ARIA Authoring Practice Guide）などに掲載されていないような特異なUIは危険です。スクリーンリーダーの利用者など、マークアップのクオリティが特に重要なユーザーにとっては、UIの操作方法がわからなかったり、そもそもUIが存在すること自体に気づけなくなる恐れがあります。

• 一部のユーザーにとって閲覧が困難になる: 画面設計によっては、一部のユーザーが情報を見落とす恐れがあります。たとえば画面がいくつかの領域に区切られ、領域に背景色が塗られているとします。視覚的にはおおよその情報構造や自分がどの領域に着目すればよいか（視線を移動させばよいか）がすぐにわかります。しかしスクリーンリーダーの利用者などは簡単にはいきません。領域に見出しなどがなければ、情報構造や自分が着目すべき情報をすぐには見つけられません。

上記にあげた問題は、デザイナーさんでもある程度把握することができますが、エンジニアリングの視点を持ちマークアップに精通したメンバーがより検知しやすい問題です。

観点５：過去の意思決定と相反していないか

わたしたちが開発しているkintoneはリリースしてから10年以上開発が続けています。デザインの分野だけに絞っても、多くのデザイナーが関わり、デザインを提案したり改善したりしてきました。
長い歴史を知っている人は非常に少ないです。デザイナーさんによっては、過去の意思決定の歴史を知らないために、過去に理由があって変更したデザインを再び元のデザインに戻そうとしてしまうことがあります。
わたしたちデザインテクノロジストは、デザインの意思決定の歴史をデザインシステムのドキュメントにまとめています。これは同じ意思決定を繰り返さないようにするためです。またレビューの際も、ドキュメントでまとめきれていない細かい意思決定については思い出せる限りフォローするようにしています。

デザインをレビューする心構え

ここまで、デザインテクノロジストの私が、デザインをレビューするときのいくつかの観点を紹介してきました。ここからは、レビューするときの心構えの話をします。

心構え1: エンジニアリングだけで問題を解決しようとしない

私がデザインテクノロジストとしてデザインレビューするときに大切にしているのは「エンジニアリングだけで問題を解決してしまおう」という誘惑に負けないことです。
たとえば、ユーザビリティやアクセシビリティに問題があると気付いたとき、WAI-ARIAなどの高度なマークアップを駆使すれば、視覚的にはデザインを変えないまま、なんとか問題を解決する道が拓けるかもしれません。
しかしデザインテクノロジストの最も大切な仕事は、勇気を出してデザイナーさんと議論し、デザイナーさんと一緒にユーザビリティやアクセシビリティを高めるデザインを探し出すことです。自分の持っているエンジニアリングの力は、すでに作られたデザインの帳尻を合わせるために使うのではなく、根拠を持った新しいデザインを創造するために使うべきだと思います。

心構え2：デザイナーさんの意思決定をリスペクトする

デザインテクノロジストは、ガイドラインやマークアップのベストプラクティスなど、明確に言語化しやすい根拠でデザインに向き合っています。ややもすると、それのみが重要だと感じてしまいがちです。
でもそれと同じくらい、あるいはそれ以上に、デザイナーさんが生み出したデザインや意思決定に対して敬意を払うことも大切です。デザインの意思決定の中には、それを作り上げたデザイナーさん自身ですらうまく言語化できないような繊細な意思決定もあります。わたしたちデザインテクノロジストはそれを切って捨てるのではなく、意思決定に共感して言語化できるようにサポートしていくべきだと思います。
デザインテクノロジストは、デザイナーにとってガイドラインを振りかざす「警察」でもなければ、一方的に知識を伝える「先生」でもありません。専門領域は異なるけれど、デザインを通じて問題解決をはかるプロフェッショナル同士です。お互いを尊重し、一緒に悩んで模索する姿勢を忘れずにいたいものです。

まとめ

この記事では、デザインテクノロジストとして活動する私がデザインレビューするときの観点と心構えをまとめました。エンジニアリング視点を持つメンバーだからこそデザインに対して持てる視点があると思います。同じような立場の方の参考になれば幸いです。

一緒にサイボウズで働いてみませんか

サイボウズでは、デザインテクノロジストやデザイナーとして一緒に働いていただける方を募集しています。興味があればぜひご検討ください。