デザイナー不在のプロダクト開発チームがデザインのためにできること [LT資料]

北海道の学生ITコミュニティ「未完Project」と、新潟県を拠点にエンジニアやクリエイターが集うコミュニティ「デルタ新潟」のコラボ企画「北海道未完×デルタ新潟合同LT会」で話してきました。

久々にLTをしたのですが、どうも僕は年々話すスピードが遅くなっている気がします。

そんな感じだったので話しきれなかった部分も多くなってしまいましたが、話す内容として事前に準備していた文章はここで公開しておきます。

加筆修正や参考リンクの追加だったりは気が向いたらやろうと思います！

はじめに

皆さんはデザインという言葉をどのように理解しているでしょうか。

デザインという言葉には多くの意味が含まれますが、デザインという言葉が見た目だけを指すと誤解している方は多いです。とはいえ、最終的に利用者に届けられるデザインのアウトプットは見た目であることが多いので、そのように理解するのは決しておかしなことではありません。

実際は、designという英単語が「設計」や「意図」といった名詞に始まり、「〜を設計する」や「〜を計画する」という動詞を表すように、デザインという言葉はスタイルに閉じません。

エンジニアにとっては、デザインパターンやdomain-driven design（ドメイン駆動設計）といった用語から、デザインが見た目以外を指すことは多くの方がご存じかもしれません。

さて、そんなデザインですが、サービス設計やアーキテクチャ設計が一筋縄ではいかないように、言葉そのものに設計という意味が含まれるデザインもまた簡単ではありません。

それゆえに、デザインの知識や経験が足りない状態で行われたデザインは、ユーザー体験はもとより、一貫性や保守性、再利用性などに難のある見た目や振る舞いを導く可能性が高いです。

このようなデザインは負債となりえます。これをデザイン負債と呼ぶことにしますが、デザイン負債は技術的負債の発生要因と共通する点も多く、組織的な問題とは別に、知識や経験によって防げる負債も多いです。

しかし、技術的負債がそう簡単には防げないように、デザイン負債もまたカバーするべき知識や経験の範囲が広く、たとえデザイナーだとしてもデザイン負債を完全に防ぐことは難しいです。

今回は、デザイナー不在のチームや個人開発者が、デジタルプロダクトにおけるデザイン負債を避けるためにできること、言い換えれば、より良いデザインを提供するためにできることを話そうと思います。

UIライブラリを使う

デジタルプロダクトにおいて、利用者が触れるデザインの中でUIが占める割合は最も大きいでしょう。

UIは様々な要素の組み合わせでできていますが、多くのUIのパーツは汎用的なものであり、既にデファクトスタンダードとなっているものが多いです。

しかしながら、もう既に世の中に多くの実例がある、ボタンやテキストフィールド、モーダルウィンドウといった多くのUIを、いざ自分で一からデザインするには少なくない知識が要求されます。これを何となくデザインしてしまうと、後々そのデザインが大きな負債となってしまう可能性があります。

そうなってしまうのを避けるには、潔くUIライブラリを使うべきで、UIデザインに自信がある場合を除き、可能な限り自らUIをデザインをすることは避けた方が良いでしょう。

加えて言うと、UIデザイナーである僕でさえも、開発工数や実装速度を考慮した際にUIライブラリを使用した方が優位性があると判断することも多いです。

UIライブラリには多くの選択肢がありますが、ほとんどのライブラリがUIデザインにおいて頻繁に利用されるパーツを備えており、自分たちで一からUIコンポーネントを開発する手間を大きく削減してくれます。

また、広く使われているUIライブラリは、アクセシビリティやカスタマイズ性を担保しつつ、実装するには中々骨の折れるインタラクティブな機能も多く持っており、プロダクトのクオリティを簡単に一段階上げることもできます。

具体的なUIライブラリの例としては以下のようなものがあります。

一応の前置きですが、僕はWebをメインに活動しているので、ネイティブアプリで使用できるUIライブラリの例は挙げられません。iOSならUI Kit？AndroidならJetpack Compose？やら使うイメージがありますが間違っていたらすみません。Human Interface GuidelineもMaterial Designも優れたデザインシステムですし、公式なものを使っておけば間違いないとは思います。

• MUI
• Chakra UI
• Next UI
• Headless UI
• Radix UI
• Ant Design
• Ionic
• Base Web(Uber)
• Carbon(IBM)
• Evergreen(Segment)
• Polaris(Shopify)
• Primer(GitHub)
• Pajamas(GitLab)
• Spectrum(Adobe)

他にも非常に多くのライブラリが存在しますが、ソフトウェアベンダー各社が作るデザインシステムがUIコンポーネントをパッケージとして公開していることも多く、その線でさらに多くのUIライブラリの選択肢を見つけることができるかもしれません。

実際に利用するにあたってどれを選定すべきかという話は、時間が足りないので話しきれませんが、まずこれらのライブラリはオープンソースで公開されているので、コミュニティの貢献度にも密接に関係するGitHub等のStarの数は多いに越したことはないです。それによって、アクセシビリティやインタラクションの対応度合いが異なってくると言っても過言ではないです。あとは、UIの見た目やコードの書き心地などで選んでしまっても良いかなと思います。

CSSとHTMLをなるべく書かない

CSSとHTMLは純粋なWeb世界のUIフレームワークとも捉えることができる存在ですが、CSSで指定したスタイル、もしくはHTMLのタグや属性によって、Webサイトにアクセシビリティ上の問題を生み出すことをもし知らないなら、記述はなるべく避けるべきです。

言い換えると、あなたの書いたCSSとHTMLが、誰かがそのWebサイトを気持ち良く使うことを妨げてしまう可能性があるという事ですね。

このような場合においても、前述のUIライブラリは有用です。当然の話ではありますが、UIライブラリの各コンポーネントはCSSとHTMLを内包したものであるためです。

とはいえ、時には独自にUIをデザインしたい場面もあるかと思います。

そのために、UIライブラリのコンポーネントのスタイルを上書きするようなコードを書いたことのある方も多いと思いますが、これは沼です。UIライブラリを使用するなら基本的にスタイルの上書きはしない方が身のためです。

このような時、僕自身よくやるのが、CSSは自分で書いて、HTMLやその他の挙動はライブラリに任せるというパターンです。

このパターンはヘッドレスUIと呼ばれるスタイルを持たないUIライブラリを用いることで対応可能です。具体的には、名前そのままなHeadless UI, Radix UI, React Aria+Stately、あるいは、MUIのUnstyled Componentsを使うような方法があります。

反対に、HTMLは自分で書いて、CSSをライブラリ……というよりフレームワークに則って記述するというパターンもあります。

このパターンには馴染み深い方も多いと思いますが、BootstrapやBulmaなどのCSSフレームワークがこれに当たりますね。最近ではユーティリティクラスに重きを置いたCSSフレームワークである、Tailwind CSSが広く利用されています。

ただ、このパターンはHTMLとCSSどちらともコーダーに委ねられている状況と変わらないので、本LTの文脈で言うと、あまり望ましくはなさそうです。

CSSとHTMLは何となく書かれることも多いですが、なるべく書かないという制約を設けることで、少しだけ書くときに、そのコードの意味を考える余地が生まれると思います。

デザイントークンを作る

デザイントークンとは、あるデザインの中で使われるスタイルを共通化したものです。

ざっくりと言えば、メインカラーは青、テキストカラーは黒、背景色はグレーみたいな定められた色のスタイル。タイトルのフォントはゴシック体、サイズは大きめ、文字間は狭く、といったテキストのスタイル。各要素の間隔は広め、といった余白のスタイル。

などなど、あるデザインに一貫性をもたらすために使われるスタイルのカタログのようなものです。

デザインを考えるときに難しく感じる要因の一つは選択肢が多すぎることだと僕は思います。デザイナーは無限に等しい多くの選択肢を目的のデザインを作るために取捨選択しています。

まず、色を一つ選ぶだけで1,677万通りのパターンがあるわけですが、この全ての色がどの場面でも使えるわけではありません。分かりやすい例で言うと、背景色が黒の場面でその上に被さる要素に黒が使えないようなことですね。

テキストについても同様です。ユーザーが使えるフォントは限られますし、Webフォントを用いたとしても可読性などを考慮すると選択肢は限られます。

余白についてはルールを定めて制限をかけることが多いです。UIデザイナーはよく8や4の倍数で余白や要素のサイズを整えますが、現在は特に8の倍数で縛るメリットもそこまで無いと思いますので、5の倍数などでも良いです。この余白とサイズのルールを定めるとデザインの速度が明らかに変化するはずです。

このようなデザイントークンを作ることで、一貫したデザインが提供でき、あわせて、デザインの保守性も向上します。

これらの色、文字、余白などのデザイントークンは、様々なデザインシステムを参考に策定することができると思います。有名どころで言えば、先程少しだけ話に挙がった、AppleのHuman Interface GuidelineやGoogleのMaterial Designなどにも各デザイントークンを説明するページがあります。

また、UIライブラリにもデザイントークンに対応するための機能が大体含まれています。CSSを自分で書く場合は、CSSのカスタムプロパティや、CSS拡張言語であるSassで変数を管理することが多いでしょうか。

シンプルさを保つ

不必要な要素は配置しないようにします。

これは決してアイコンだけでアクションを示すべきとかそういうことを言っている訳ではなく、必要な要素だけを配置するべきという意図です。

要素が増えることはデザインの選択肢を増やすことにも繋がります。要素が一つ増えることはデザインの選択肢が一つ増えるのではなく、他のデザインした要素全てに新しい選択肢が複数個増える可能性があります。

デザイナーは複雑さをシンプルという枠に当てはめようとデザインしている節があります。

この複雑さは要件レベルからUIに侵食してきます。要件定義の段階で、まずは必要なものだけを提供することが重要です。シンプルにすることは、デザインにとっても良いことな訳ですね。

オブジェクトを起点にする

エンジニアリングの分野ではオブジェクト指向プログラミング（以降、OOP）というプログラミングスタイルがありますが、デザインにおいてもオブジェクト指向ユーザーインターフェース（以降、OOUI）というUIデザインの設計論があります。この言葉自体はかなり前からあるようですが、OOUIという手法が日本で広く注目され始めたここ数年の出来事であるように感じます。

OOUIとOOPに共通する部分は多いですが、その中でもデザインにおいて重要なのが、オブジェクトは対象ドメインから抽出された共通概念であるということです。

OOPではクラスのインスタンスをオブジェクトと呼ぶことが多いです。そのクラスとインスタンスの説明ではよく「鯛焼きの型とそれによって出来上がった鯛焼きそのもの」が例に挙げられますが、この例で言うと、鯛焼きの型は鯛焼きを効率的に作るために生み出された共通点の集合体であるということですね。

これが、先程言った「オブジェクトは対象ドメインから抽出された共通概念である」という所の大まかな説明にもなりそうです。

また、instanceという英単語は実体という意味を持ちますが、実体という意味を持つ英単語は他にもentityがあります。これを聞いてピンときた方もいると思いますが、データベースにおけるテーブルもオブジェクトに近い性質を持っていると僕は考えています。

これらの実体、オブジェクトを起点としてUIをデザインすることによって、拡張性や再利用性の向上、はたまたユーザーによるUIの学習効率を向上させる効果などもあります。

では、実際にオブジェクトを起点としてUIをデザインするとは具体的にどういうことなのか？という点は時間の都合上お話ししきれませんが、ざっくりと言えば「名詞から動詞」の順番になるようにデザインすることです。

オブジェクトの性質の1つであるメソッドから配置するのではなく、オブジェクトそのものがUI上でまず目に入るようにすべきとも言えるでしょうか。

ただ、オブジェクトの生成（インスタンス化）に関しては、オブジェクトから実行することが難しいかもしれません。先程の鯛焼きの例で言えば、鯛焼きは鯛焼きの型という上位存在からしか生成することができません。

現実的に考えれば、鯛焼きも鯛焼きの型も実体なのですが、オブジェクト指向で言うところの実体を生み出せるのはクラスという共通概念であって、その共通概念そのものは実体ではないからですね。

そのため、OOUIにおいてもオブジェクトの生成は動詞が先導しがちです。こういった場合では生成されるオブジェクトの例を先に見せるという方法が考えられます。

はじめてログインしたサービスで、サービスを利用するにあたって重要なオブジェクトが既に作成済みであった経験はありませんか？

リサーチを実施する

なにか良いプロダクトのアイデアを思いついたとき、エンジニアならすぐ実物を作ることができるのは大きなアドバンテージです。ただし、そのプロダクトをより多くの人に使って欲しいと考えるなら、手を動かす前に何かしらのリサーチを行うべき状況も多いです。

リサーチという言葉は非常に広範囲な取り組みを指しますが、今回はプロトタイピングとユーザーリサーチという二つに絞って話します。

プロトタイピングは、試作品を作ることによってプロダクトが本当に価値があるのか検証したり、早期にユーザーからフィードバックを得てプロダクトの完成度をより高めるためのリサーチです。

プロトタイピングにおける、試作品——プロトタイプのクオリティには大きな幅があります。

この時点でサクッとコードを書いてプロトタイプを作ってしまうのも良いですが、プロダクトの価値提供に技術が強く影響する場合を除き、もっともっと簡単にプロトタイプを作ることが可能です。

例えば、PowerPointなどで作られるスライドもプロトタイプになり得ます。スライドによって紙芝居的にそのプロダクトが何を成そうとしているのか、何ができるのかを説明するようなイメージです。

もう少し踏み込むと、Figmaなどのデザインツールを用いることによって、比較的簡単にスマートフォンなどのデバイスで操作可能な紙芝居を作ることも可能です。

これらのプロトタイプの中で最も簡単に作成できるプロトタイプは、ペーパープロトタイプです。

これはまさしく紙にプロダクトをお絵描きしたものです。ペーパープロトタイプは早い！安い！楽しい！という利点がありますが、意味のあるフィードバックを得るためにはプロトタイピング参加者の想像力と、その想像力を引き立てるプレゼンテーションが必要になってきます。

このようにペーパープロトタイプの欠点は大きいですが、ペーパープロトタイプは自らの思考を整理するためにも有用なので、良いアイデアが思いついた時は一度紙とペンを手に持って見るのも良いかもしれません。

さて、続いてユーザーリサーチですが、プロトタイピングの過程でユーザーになり得る人と行う対話はそユーザーリサーチに分類されます。つまり、言葉通り、ユーザーを対象に行う調査は全てユーザーリサーチと呼ばれ、わりかし広い意味を持っています。

その中でも、ユーザーリサーチは大きく分けて量的調査と質的調査の二つの方向性で実施されます。

量的調査で頻繁に用いられるのはアンケート調査で、あらかじめ考えた設問に対して、多くの人から回答を集めて、その集計結果を元に洞察を深めます。

この調査では、アンケートの設問設計によって得られるデータに大きなブレが発生するので、何のためのアンケートなのか？このアンケートを通して何を知りたいのか？という点を強く意識しつつ、正確なデータが取れるように、誘導的にならないように、設問を考える必要があります。

質的調査ではインタビューが多く採用されます。

何らかの疑問やニーズの有無などを確認したり、自分がまだ知らないドメイン知識を深めたりするためにインタビューは実施されることが多いです。

インタビューはアンケート以上に知識や経験が必要で、より良いインタビューを実施するには専門的なスキルが求められます。

ですが、とにかく上手くインタビューができなくても良いから、自分が提供するプロダクトの利用者となり得る人と話をしてみることの方が明らかに大事で、完璧にインタビューをこなすことは一旦忘れても良いと思います。

僕もこの分野に関してはあまり勉強が足りていないのですが、インタビューに不安のある方は半構造化インタビューという形式をとってみると比較的上手に話を進めることができるかもしれません。

今回紹介したもの以外にも非常に多くのリサーチの手法がありますが、まずは、プロトタイピングとユーザーリサーチの二つから始めてみるのがおすすめです。

アクセシビリティを意識する

利用者はどのようにプロダクトを扱うのでしょうか。

アクセシビリティを意識するとここには書いてありますが、僕の伝えたいことは利用者を想像すること・知ることに近いです。

当然ながら、プロダクトは使ってくれる人がいなければ続きません。

では、どういった人たちがプロダクトを使ってくれるのでしょうか。さらに、その人たちはどういった目的で使ってくれるのか。気持ちよく使えるか。やりたいことは完遂できるか。想定外の使い方に対処できるか。心を傷つけてしまう可能性はないか。騙していないか。

時間の都合上、具体的にアクセシビリティを良くするために何をするべきかは説明しきれませんが、アクセシビリティはプロダクトを利用してくれる全員のためにあります。

アクセシビリティを良くするのは難しいと思うかもしれませんし、実際難しいところもあるのですが、真剣に利用者のことを想像すること・知ることはその時点でアクセシブルです。

そして、実は、今回話した内容を実践できていれば、ある程度は既にアクセシブルになっているはずです。ラッキーですね。

おわりに

デザインのためにできることという主題に沿って話をしましたが、つまるところ、デザインというのはプロダクトをより良くするための取り組みとも言えます。

今回は様々なトピックのほんの触りだけ話したようなものなので、これをきっかけに興味のあったトピックを深ぼっていくと、何か良い感じになるような気がします。

以上の内容が皆さんのプロダクトをより良い形に導いてくれることを願っています。