見出し画像

著書『はじめてのUIデザイン』第6章を無料公開します

平成最後の4月に共著で出版をした『はじめてのUIデザイン』が、おかげさまで2019/05/27時点で約3,800冊と。とてもうれしく思います。

発売記念イベント(応募は締め切ってしまいました🙇)も控えており、もっと多くの人に読んでもらいたいと思い、今回僕が本書で担当をした『第6章 UIデザインができたら』全文無料公開します

挿絵などを省略をした簡略版となりますため一部読みにくい部分もあるかもしれませんが、十分に全体の内容はつかめるものです。

この本は時代に流されず長く愛してもらえる本として書いていますので、もしこの章を読んで興味を持たれた方はぜひ購入して全章を読んでいただければと思います。

第7章を書かれた坪田さんもnoteで一部有料での全文公開をしていますので、ぜひこちらも合わせて読んでみてください。

✂===================

6章 UIデザインができたら

5 章で作り上げた美しいスタイルとレイアウトを、この章ではより使いやすく、よ りわかりやすく愛されるものに磨きあげる方法を紹介していきたいと思います。 Sketchなどで作ったデザインで満足してしまっていませんか? 実は、UIデザイ ナーの仕事としてはこれでようやく折り返し地点です。
「自分がいいと思った、チームのみんながいいと思った」デザインから、「使ってくれ ているユーザーがいいと思う、新しいユーザーが使いたいと思う」デザインへと昇華 させるステップを学んでいきましょう。

この章のゴール
・ユーザー体験を意識したUI デザインの流れを理解する
・目的に応じたユーザビリティの考え方を学べる
・開発から運用までの注意点を学べる

6-1体験をデザインする

必要なページのUIデザインができたので、より実際の画面に近い体験を作っていきます。前章ですでにプロトタイプなどをおこなっていますが、次はより具体的な使い心地の検証を深めていく作業となります。
今までページ単位で、いわば「点」で考えていたデザインが、このフェーズを経て「線」でつながり、より体験として感じられるものになるのです。
ここでは大きく2つの作業を進めていきます。

・画面遷移にトランジションをつけ、ページの要素やレイアウトの検証をおこなう
・ユーザーのアクションに応え、よりわかりやすく使いやくするためのインタラクションを追加する

双方の相乗効果によって、より良いものを作り上げていくのが最終目的です。必ずしも明確なフェーズ分けが必要なわけではありませんが、それぞれのフェーズで利用するツールには一長一短がありますので、作りあげたい体験によって使い分けていくのがよいでしょう。
5章で紹介したデザインツールですが、ここでは、さらに役割ごとに分類をして私の使い方を紹介します。

画面遷移をつける

ページ単位でのデザインに「このボタンをタップ(クリック)したらこのページへ遷移する」というつながりをつける作業です。

Sketchのプロトタイピング機能
InVision
Prott
Figma

私の場合、Sketchを利用してデザインしたときは、あえて他のツールを使わずSketchのプロトタイピング機能で完結してしまうことも多いです。あくまでここは前後のページのつながりを明確にするための体験をデザインするフェーズですので、複雑な機能はあまり必要なく、デザインの修正と行き来をしやすいことを優先しています。

インタラクションをつける

より完成品に近いアウトプットを作っていくための、インタラクションに特化したアプリです。

Origami Studio
Principle
Framer X
Flinto for Mac
ProtoPie

これらのアプリは、より完成物に近づけたインタラクションが求められるときに利用します。私は単純に「AのパターンからBのパターンに変化する」といったものであればPrinciple、より複雑なユーザー操作に反応するインタラクションや繊細な調整をしたり、アニメーションを作成する際にはOrigami Studioをよく利用しています。最近はReact.jsが使えるようになったFramer Xも利用者が増えているようです。
各アプリの特性や使い方だけでも1冊の本が書けてしまいますので、アプリの詳細は割愛しますが、どれも実機での操作と確認ができることが最大の特徴です。それぞれ習得難易度とそれによる表現力が異なりますので、目的や好みでより使いやすく最適なものを選んでみるとよいでしょう。

すでにUIデザインの際に頭の中で「こんなトランジションやインタラクションをつけたらいいのではないか」なども浮かんでいる人も多いかと思います。UIデザインを細かに作り込もうという段階から、実機で確認しながら、画面遷移をつける作業を始めてしまうのも1つの手です。それを実際にやってみると「こんなはずではなかった」や「もっと違う見せ方ができるのではないか」という改善点も浮かんでくることも多くあります。
必要に応じてUIデザインのフェーズと行き来することが大事です。

画面遷移をつける作業に必要なこと

画面遷移をつける作業は、点と点をつなげて線にしたうえで、体験の設計として正しいのかを判断するのが目的です。
UIデザインをしていると、どうしても重要なのは1ページ単位(Sketchでいうと1つのArtboard)での出来栄えだと考えてしまいがちです。事前にペーパープロトタイピングなどをしていても、作り込みをする段階でその視野が狭まってきます。あくまで各モジュールやパーツは一連の体験を最適化するための手段にすぎません。それらの出来を俯瞰的に見るためにも、この作業は必要なフェーズとなるのです。
この段階で、前後のページとの不整合を見つけていきます。実はいらないというページや統合をしたほうが使いやすいページもあぶり出されてくるでしょう。5章で見てきたプロトタイピングはそこにある要素の過不足や流れを確認する作業でしたが、この章では、より作り込んだUIでトランジションをつけていきます。それにより、体験としての具体性を上げることができます。
逆に言うと、このフェーズでその大きな流れを決めておかないと、この後のフェーズでより細かな作り込みをすることで気づきにくくなってしまいます。「UIの細部」と「全体の流れ」という粒度の違う面を交互に見ることで総合的な完成度を上げていくことが大事です。
このフェーズでは何度でもやり直しが効きやすいので、納得のいくまで作り込んでいきましょう。

また、ハーフモーダルやトースト(p.46)などの、ページの一部分が書き換わったり要素が追加されたりする見せ方をしたい場合は、この段階でしっかりとそれを見据えておきましょう。
次の項でより細かなインタラクションはつけていきますが、「ページを切り替えるのか」「ハーフモーダルUIで見せるのか」「トーストで見せるのか」といった部分は大切な情報設計の指針です。それらをここで定めていくつもりで組んでいきましょう。

インタラクションをつける作業に必要なこと

より詳細な各ページの作り込みや特殊なトランジションを作っていきます。
このフェーズは必ずしも必要なわけではありません。特にアプリでは、4章で紹介しているOS標準のトランジションがありますので、先の画面遷移をつけるフェーズで完了してしまいます。本当にシンプルなアプリであれば、このフェーズはスキップしてもよいでしょう。
とはいえ、標準UIでのみ組み立てられたものはふだんから見慣れているため退屈な印象を受けることもあります。そのサービスの中で本当に大事にしたいコアな体験などには、そのサービスを特徴づけるマイクロインタラクション(とても小さな範囲でのフィードバックやアニメーション)をつけるだけでも、大きく印象が変わってきます。
Facebookの「いいね」やTwitterの「お気に入り」が象徴的でしょう。それらはとても細かい装飾でありますが、それぞれのサービスを象徴するアクションであり、強く印象づけ「押すと気持ちいい」というプラスαの体験を生み出しています。

これらのiOSアプリでは共通してアニメーションと一緒にHaptic feedback(振動による触覚フィードバック)が用いられているのも特徴的です。これはiOSの標準機能(iPhone 7以降の機種で利用可能)ですが、ユーザーの行動に対して視覚だけではなく触覚に働きかけることができるため、非常に効果的なフィードバックといえるでしょう。常に使えるわけではありませんが、ときとしては音を利用するのもよいでしょう。
(Facebookアプリでは「いいね!」をすると「ポン!」という音が鳴るのを知っていますか?)視覚だけではなく触覚や聴覚に働きかけるのもまたインタラクションの1つの形です。
文字のジャンプ率や色による強弱と同様に、こういったインタラクションを付与することでよりそのサービスの中で「大事であり特徴できない動作」であることがわかってくるでしょう。
すべてにこのインタラクションを付与してしまうと逆に動きがくどくなってしまいますが、ここぞという一番大切な場面でのUXは大事にしたいもの。ぜひともコアとなるようなアクションには細部へのこだわりを持って作り込んでみてください。

“完璧”を目指さない

ただ、私自身が全体を通して大事にしているのが、完璧なものを作ろうとしないことです。
プロトタイプはあくまでプロトタイプにすぎません。特に、Origami StudioやFramer Xはほぼプログラミングをすることになりますので、極論的にはアプリと同じ表現をすることができてしまいます。その一方で、あくまでそれは表面上そのように見えているだけで、実際の実装とのさまざまな違い(プログラミング言語や通信処理、その他の裏側で動く処理)は確実にあります。
そのため、あくまでそのゴールに向けて、プロダクトに関わるメンバーの共通認識を合わせる工程であり、そこに行き着くための手段として使うことが一番大事なことだと考えています。
また、何より、いきなり作り込みをしてしまうと、作ったものに対してどうしても執着が生まれます。「これが一番いい」という頭で作ってしまうと、他の人の意見をフラットに受け入れられません。そうなるとプロトタイプとしては失敗です。
壊すために作る、より気楽に動くものを作る、というような心持ちで望むほうがより柔軟なものづくりとコミュニケーションを生むことができるのではないでしょうか。
作り込みをしてはいけないということではありません。言葉では伝えられない複雑な動きやより繊細なタイミングの磨き込み、むしろそれが非常に大事であることも多くあります。しかし、あくまでページの構成や遷移などを確定させたうえで、その先のフェーズの作業として考えておくことが大事です。

誰のためのデザインかを知る

ここでぜひともやっておきたいのが、「実際に他の人に使ってもらう」ことです。この章のはじめに「使ってくれているユーザーがいいと思う、新しいユーザーが使いたいと思う」デザインへの昇華という話をしていますが、それを知るためには、何よりも実際のユーザーに使ってもらうことが一番です。
「まだアプリやWebができていない状態で見せたくない」という思いもあるかもしれませんが、できるなら、きちんとした作り込みをしてしまう前の段階から、フィードバックをもらうようにしましょう。修正と改善をしながらプロトタイプを磨いていく作業が欠かせません。
大企業であれば、こういった工程に何百万円もかけて数千人にアンケートをとったり、実際にターゲットユーザーを呼んで使ってもらうことが可能です。私も過去、そういった大規模テストをおこなった経験があります。アウトプットとしても非常に良いものになりますし、リリース前にそういった機会を設けられることは非常に安心感があります。しかし実際には、なかなか大規模アンケートをやるお金も時間もない、というのが現実ではないでしょうか。
本当は、街に出て実際のユーザーに近い人に話しかけて試してもらうのがいいのですが、それもまた非常に緊張するでしょう。それであれば、会社で隣に座っている人でも、家族でもかまいません。まずは一度、第三者からフィードバックをもらうという体験をしてみてください。数多くの人にアンケートを取り定量的な数字を集めることも大事なのですが、それと同じくらい実際に対面した人に話を聞くことで得られる学びもたくさんあります。きっと「なぜそんな使い方をするのだ……」というような、思ってもみない使い方をする人がいることに驚くと思います。逆に、そこから「自分が思っていたのと違うけれど、こんな使い方もあるかもがしれない」というヒントを得ることもできます。そこで手応えを感じることができたら、さらに実際のユーザー層に近い人を見つけて聞いてみるということをやってみましょう。でき
フィードバックを得るには、実際に操作をしてもらって使い勝手を見るための「ユーザビリティテスト」たらや、満足度や印象などを聞く「アンケート」などさまざまな手法があるのですが、私の周りでよくおこなわれているのは「ウォークスルーテスト」という手法です。
これは、想定している利用の手順を書き出してみて、その手順の中できちんと目的を達成することができるかを第三者に試してもらい、課題の抽出をおこなうという手法です。きちんとターゲットユーザーを定め、そのユーザーになりきって試すのが1つの特徴です。
第三者ではなく、ふだんそのサービスを使っているチームメンバーとおこなっても、きちんとそのユーザーになりきることで思わぬ問題点が発見できたりします。また、一緒に作っているメンバーと一緒にウォークスルーテストをおこなうことで、目線を同じ方向を向けることができるので、よりスムーズなコミュニケーションがとれるようになるところも、私のお気に入りのポイントです。
実施する際はぜひ、さまざまな職種や役職を交えておこなってみてください。それによって今まで考えていた課題点と全く異なるものが見つかったり、既知の問題点でも違った視線で捉えることにより、重要度を正確に判断ができるようになると思います。

ユーザビリティをデザインする

ユーザビリティというと少し難しい印象を持つかもしれません。たしかに、これもまた、これだけで本が数冊書けるお題ですし、コラムで触れているWebアクセシビリティ(p.209)なども非常に大切です。
そのあたりも詳細はまた専門書におまかせするとして、ここでは一般的な座学ではなく私が実践する中での考え方を中心に話をします。
ユーザビリティと聞くとどんな内容を想像しますか?機能的な色の使い方、文字の大きさ、アイコンの意味のような「見やすさ」「わかりやすさ」を求めるための指標でしょうか。もちろんそれは間違いありません。すべてに通ずる汎用的なユーザビリティのセオリーは存在します。4章で紹介しているようなHuman Interface GuidelinesMaterial Designもこれらを強く意識したうえで作られています。
「わかりやすく」「見やすく」といった観点をきちんと理解してデザインをすることは非常に大事ですし、そのためには、すでに世にあるガイドラインを読んでいくことは非常に有用です。しかし、このユーザビリティを追求していくにはそれだけでは足りません。
まず、ユーザビリティの定義、これは1つの回答があるわけではありません。JIS Z 8522では、「ある製品が、指定された利用者によって、指定された利用の状況下で、指定された目的を達成する際の、有効さ、効率及び利用者の満足度の度合い」と定めています。
「指定された利用者」「指定された利用の状況下」「指定された目的」という制限がたくさん明文化されていることがわかります。このあたりがUIデザインにおけるユーザビリティに密接に関わってくるのです。対象ターゲットとその利用シーンを明確に定めることにより、より最適なユーザビリティがあるということです。
これは、決してターゲットを絞らなければいけないという話ではありません。極論、「全世界の全性別の全年齢の全宗教の全言語の人」でも、それがサービス上必要なターゲットならかまいません。それならそれで、まさしくユニバーサルデザイン(「できるだけ多くの人が利用可能であるようなデザインにすること」を基本コンセプトとしたデザイン)という考え方があります。
しかしその一方で、特定層のユーザーしか使わない場合は、ときとしてユニバーサルデザインはオーバースペックになりますし、冗長な表現にもなりやすく、難易度が高いです。逆にいうと、もっと実際のターゲットにフォーカスすることで、より最適化したユーザビリティを追求することができるようになります。
この節できちんと問いかけたいのは、対象とするターゲットにより、求められるベストなユーザビリティが異なってくるということなのです。
ターゲットをきちんと定めたうえで実際に使う人の立場に立ち、それを使ってみること、また眼の前で実際にユーザーに使ってもらうことで、ユーザビリティの検証を高い精度で実現することができます。
ターゲットの違いによるユーザビリティの例は、たとえば次のようなケースです。

・女性がターゲットに入る場合
→手が小さいので、できるだけ操作する範囲を画面の下に寄せる

・若年層がターゲットに入る場合
→斜め読みをする傾向があるので、ジャンプ率を意識してタイトルなどの拾い読みをしやすくする

また、同じターゲットでも使う時間や場所場所などによっても、求められるユーザビリティは異なります。

・電車に乗りながら使う場合
→電波が途切れて使えない機能がある場合、オフライン状態であることをUI上でもきちんと伝える

・寝る前に使う場合
→ナイトモードなどを取り入れ、目に負担をかけないようにする

・運転しながら使う場合(カーナビなど)
→ちらっと見るだけで把握できるよう情報を大きく表示し、必要でない情報に目が奪われないよう大事な表示のみに絞る

・属性の違い
男性/女性

・利用シーンの違い
電車の中

このように、実際にどんな人を想定するかで求める最適なユーザビリティが大きく変わってくることがわかるでしょう。ある人が使いやすいと思っていても、別の人が使った場合に大きく使い心地を損なうこともあるのです。
文字の大きさを大きくすればより広い年齢層の人に読みやすくなりますが、逆に1画面に収められる文字数が必然的に少なくなるため、情報量も少なくなってしまいます。それによって同じ文字数でもたくさんスクロールをしなければ文章が読めず、結果として使い勝手を損ねてしまうかもしれません。

すべての環境に適合できる最高のデザインというものは少なく、誰に一番伝えたいのか、何を一番伝えたいのかということをきちんと明確にしたうえで検討を進める必要があるのです。
こういった細かな調整は全体のスタイリングが終わったあと、このフェーズでこそ見えてくることと言えるでしょう。

目指すユーザビリティの見極め

ここでも、先の項で書いているように「どのような環境で、どのようなユーザーに、どんなふうに使ってもらいたいか」という軸を決めるのが一番良いと私は考えています。
ユーザビリティというものは、やはり千差万別です。老若男女問わずすべての人に使ってもらいたいのか、妊婦と乳児を育てる男女に使ってもらいたいのか、それぞれで適したユーザビリティは異なります。
ターゲットが広いと最大公約数的にすべての人に嫌われにくいデザインが求められますし、ターゲットが狭い場合は一部のユーザーに強く愛されるデザインを作ることも可能です。
サービスカラーなどはこれらの意思を最も強く反映したものと言えるでしょう。iOSの標準UIなどのようにモノトーンを基調としたものは好みに左右されにくいですが、その分、個性のないものになってしまいがちです。
コンビニに並んでいる雑誌を見てみるととてもわかりやすいですね。同じ女性誌でもターゲットにより大きくデザインが異なります。年齢や好みの服装が表紙のデザインに大きく現れていますし、逆にいうと、そのテイストを好まない人には手にとってもらわなくていいという割り切りも感じられます。
先のユーザビリティの話では「どのようにして使いやすくするか」という視点でしたが、ここでは「どのように使ってもらいたいか」「誰に使ってもらいたいか」という、よりサービスの意思を反映したものが大事になってきます。
デザイナーがきちんとゴールイメージを持ち、場合によっては、他の職種の人たちも巻き込み、みんなで統一したイメージを持って、その軸に沿ったデザインを考えていく必要があります。
ときとして一部ユーザーから嫌われることもあるかもしれませんが、それもきちんと考慮したうえで決断をしていく必要があるのです。ある場面では良くないUIも、ある場面では良いUIになったり、いま使ってくれているユーザーには良くないUIだけど、将来的に使ってほしいユーザーには良いUIだったりと、ミクロな目線で見たときとマクロな目線で見たときでUIの良し悪しは変わるものです。
UIデザインは、それ単体で何かを成すものではなく、プロダクトのミッションやビジョンを強く反映し成長を促していくためにあります。ユーザーファーストという言葉がよく使われますが、それは決して「今のユーザー」のためにだけある言葉ではありません。これから使ってくれるユーザーや、今後使ってもらいたいユーザーにとっても、ユーザーファーストでなければなりません。
「この機能は使ってくれる人がいるから削れない」というような話もよく聞きますが、それを続けていくと、プロダクトは細かな機能で山盛りになり、結果として初めて使う人にはよくわからないUIになってしまうというのもよくあることです。
未来を見据えて成長させていくために、いまUIに何が求められているのかを、きちんとデザイナーの目線から作り上げていきましょう。
その決断を支えるのがプロトタイピングであり、さまざまな定量・定性両側面からのテスト、そしてプロダクトの意思だということを覚えておいてください。

-------------------------------------------
[コラム] Webアクセシビリティは誰のためにあるのか

さて、ここで少しWebアクセシビリティについても簡単に触れておきたいと思います。単語自体は聞いたことがあるかもしれませんが、その一方できちんとした対応はしたことがないという人も多いかと思います。
Webアクセシビリティの対応というと、視覚障害のある人のためのスクリーンリーダー対応や、高齢者の対応というイメージが強いかもしれません。そのためにHTMLではimgタグのalt属性をつけたり、文字サイズを可変にできるといった対応が有名です。ただ、それはWebアクセシビリティの対応としてはほんの1つの側面にすぎません。
厚生労働省ではアクセシビリティを下記のように定義しています。

アクセシビリティとは、年齢や身体障害の有無に関係なく、誰でも必要とする情報に簡単にたどり着け、利用できることをいいます。厚生労働省では、Webアクセシビリティの日本工業規格「JIS X 8341-3:2010」における等級A(シングルA)のレベルを達成するホームページ作成を心掛けています。まだ対応が十分でないページもありますが、引き続き整備を進め、アクセシビリティの向上デザイに努めてまいります。
(https://www.mhlw.go.jp/accessibility/index.html)

この「誰でも必要とする情報に簡単にたどり着け」というところが一番大事なところです。この「誰でも」には当然ですが、年齢や身体障害の有無に関係なくすべての人、さらには、人だけではなく機械などまで、広義の意味で含まれます。
まず、環境によって求められる情報の見せ方は変わります。都心に住んでいると電波が切れるという体験はあまりないかもしれませんが、たとえば新幹線に乗っていてトンネルの中で電波が切れるということはありますよね?電波が入っていても格安SIMなどで速度制限がかかってしまうと、非常に低速になってしまうというシーンは経験のある人も多いでしょう。もし、そのとき画像を全部読み込めなくても、alt属性が表示されていればある程度の内容を理解することができます。
また、スマートフォンを日光の下で見ると反射してしまい非常に見えにくく、低コントラストの文字などが読みにくくなった経験はありませんか?(明確に言うと異なりますが)色弱の人のためにコントラスト比を保つという考え方だけではく、その利用シーンによって求められるアクセシビリティが変わるのがわかるでしょう。
さらには、「機械にも理解しやすくする」ということです。さまざまな文字の役割を定義することで、Google検索のクローラーがその内容を理解しやすくなると考えるとどうでしょう?また、スクリーンリーダーというとどうしても身近に感じられないかもしれませんが、それがPepperやGoogle Homeのようなロボットやスマートスピーカーと考えるといかがでしょうか?そのコンテンツを正しく読めるようにすることで、より多くの人にさまざまな方法で伝えられるようになると思いませんか?それによって文字の読み書きができない子どもまでもが、そのコンテンツに触れられるようになると思いませんか?
アクセシビリティは決して特別な対応ではありません。自分をベースにしたとしても、その過去の体験や利用シーンによって求められるものが変わってくることがわかるでしょう。
特別に肩肘をはるべきものではありません。机のうえで限られた条件だけを想定するのではなく、使う環境や、人々にどんな使い方が求められているのかを考えていくことで、結果的にアクセシビリティにもきちんとした対応ができるはずです。アクセシビリティは後から特別に考えるものではありません。その土台として根底にあるものなのです。
Webアクセシビリティの知識を深めたい人には『デザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチ』という書籍をおすすめします。ぜひ読んでみてください。

-------------------------------------------

6-2 開発者と連携する

さまざまな検討をもとにUIデザインがフィックスしましたね。おめでとうございます!しかし、当然UIデザインは使ってもらうためのものであり、その先の実装があります。ネイティブアプリなのかWebサイトなのかによっても使われるシステムは違いますし、それをそのままデザイナーが実装してしまう場合もあるでしょう。しかし、ここではあくまでJavaScriptやSwift、Javaなどでプログラミングをするような別ロールの人と協業をする前提で話を進めます。

何のためのUIなのか

まずここでもしつこく「なぜこのUI?」という話にもう一度触れたいと思います。アニメーションのタイミングや余白のサイズの指定なども大切なのですが、「なぜ、このUIが必要なのか」「どのような経緯でこのUIに至ったのか」ということを実装担当の人にも共有することが大事です。
とあるページだけを見れば近しいものができても、他とつなげたときになめらかな体験が生まれなかったり、その後のグロースを見込んでいない設計になってしまうかもしれません。
「そういう目的があるなら、ここはもう少し柔軟な作り方をしておこう」といった先を見据えた設計や、「そこを変えるなら、こちらも一緒に変えたほうがいい」という実装目線から、より俯瞰したアイデアがもらえるかもしれません。
たとえば、体感速度を上げるためのアニメーションを作ったとしましょう。そのとき、古い端末ではどうしても滑らかな動きができないということがよくあります。そのとき、担当エンジニアができる限りの努力をしたとします。でも、それは単に「滑らかなアニメーションを作る」ことが目的となってしまったのかもしれません。実際は「体感速度を上げる」のが目的です。実は、無駄なアニメーションを挟まずにそのサービスのTipsなどを表示したほうが効果的なのかもしれません。デザインもまた手段です。その目的をしっかりと共有し、いい意味で、”実装時にいじれる”余白を用意しておくのも大事だと私は考えています。
エンジニアとの連携を例として出しましたが、これは何も開発面だけの話ではありません。UIの意図はそれを展開するサービスの意思です。もし大人数でのプロダクトづくりをしている場合は、マーケティングや広報、カスタマーサポートにまで、その意思が浸透していることが大事です。それによって各領域でユーザーに対してどのようなアプローチを取るのかが変わってきます。
互いの領域をデザインという共通言語でつなぐことは非常に円滑なコミュニケーションを生みますし、もし数人で(または1人で!)すべてを担っていたとしても、それぞれの役割でそのUIを意識することで目的が明確化し、より視野の広い対応ができるようになっていくと思います。

デザインを伝える方法

前述のUIデザインの意図とともに、より詳細なデザインの指示を出していきます。この分野に関しても今はさまざまなツールが充実していますので、できるだけ手間を減らし更新性を担保していきましょう。
伝えるべき要件は次のようなものが考えられます

◎スタイル/レイアウト
・フォントの指定(フォントファミリー・行間・段落)
・画像サイズや余白
・座標指定(絶対/相対)
・色など(シャドウやブラーを動的にかける場合はそちらも)

◎パターン
・状態によって変化するパターン(ログイン前/ログイン後など)
・コンテンツによって変化するパターン(文字数や挿入される画像の比率など)
・ユーザー操作によって変化するパターン(スクロール/スマートフォンの向きやウインドウのサイズ)
・リンクやボタンの状態によって変化するパターン(visited、disabled、checked)

◎インタラクション
・クリック(タップ)時の挙動(hover、active、focus、touchstart、touchend)
・アニメーション(アニメーションのスピードやタイミング、イージングなども含めて)

深掘りをするともっと多くの要素や上記の掛け合わせが出てくるため無数と言えます。とりあえずは、ざっくりこのような項目を考えておいてください。
さて、これらをそれぞれGoogle DocsやConfluence、Qiitaなどで仕様書としてまとめるのもいいのですが、最近はUI仕様をグラフィックソフトと連携させたツールでエンジニアに共有することが増えてきました。ここでは、その先駆けであるZeplinを説明しましょう。

Zeplin
Zeplinはデザイナーに留まらず、開発チームメンバー全員でデザインデータの共有が可能な開発支援ツールです。Sketchだけではなく、Photoshop、Adobe XD CC、Figmaと代表的なツールに対応しています。また、これらのツールを持っていない人でもブラウザやアプリ(macOS/Windows)から利用することができ、SketchのようにmacOSにしか対応していないアプリのデータも確認が可能です。
Zeplin https://zeplin.io/

Zeplinは、前述の「伝えるべき要件」でお伝えした「スタイル/レイアウト」の部分を指示するためのツールとして大活躍をします。
また、Zeplinを開発支援ツールと表したのは、それだけが理由ではありません。Developer向けの機能として、各スタイルの指定を各言語のコードスニペットとして、CSSやSwift、XMLなどを始めとしてさまざまな言語で生成してくれます。Extensionとしてサードパーティーでも開発ができるようになっており、独自の命名規則なども柔軟に作れるようになっています。

また、UI上で要素を指定してコメントを入れることができますので、それらの工夫で「パターン」の補足や簡易的なUIレビューをすることも可能だと思います。
さらに、Zeplinの特徴的なものにスタイルガイドの作成機能があります。Zeplin上でスタイルを登録していくことで、必要とされる色やテキストスタイルを集めて1画面内にまとめて表示できます。また、前述のコードスニペットもこのスタイルガイドに対して適用されるものとなります。
今までスタイルガイドというと、どこかデザイナーのためのものという意識もありましたが、より開発者のためのスタイルガイドとして利用できるのが、Zeplinのメリットと言えるでしょう。

その他ツール
Zeplinだけでなく、他のツールでも同様の開発支援ツールとして機能するものがあります。5章の「連携サービス」(p.172)でも触れていますが、この中で、私が今一番利用頻度が高いのはAbstractです。こちらは開発支援ツールというよりも、Sketch版GitHubともいうべきデザイン支援ツールです。
類似のアプローチのツールにVersionsやKactusなどがあり、それぞれ特徴があります。きちんとした開発フローを踏むうえでは、2018年現在ではバージョン管理だけでなくレビュー機能などまで備えているAbstractがやりやすいと考えています。私のチームではデザイナーだけではなく、企画職やエンジニアもAbstarctでデザインを確認し仕様レビューをするパターンも増えてきました。大人数での作業の場合はどうしてもそれぞれの作業の可視化や、誰が何を触っているのかなども管理する必要が出てくるために、ある程度は決まった運用ルールに乗せる必要があります。そういったときにGitHubと同じような考え方で使えるAbstractは開発メンバーにもなじみがあり、とても力強いツールとなってくれます。
もちろん少人数で作業をしている場合、そこまで厳密なバージョン管理やレビューフローを求められないがことも多いと思います。むしろそれにより確認作業が増えてしまい開発のスピード感を損ねてしまうこともあるでしょう。この章ではあまり触れていませんが、同時に作業可能な状態を作るという意味では、Figmaはそもそも複数人数での同時編集を前提として作られていますので、適していることもありそうです。そのあたりは一緒に開発をするチームの規模感なども考慮してツールを選ぶのがよいでしょう。

Versions https://versions.sympli.io/
Kactus https://kactus.io/
Figma https://www.figma.com/

開発支援ツールは一度導入すると他のツールに乗り換えるコストが高いため、導入に及び腰になりがちです。また、基本的には業務用ツールであるため利用コストも安くはありません。しかしそれらのツールをうまく利用することで意思の疎通が円滑になったり、きちんとしたバージョン管理をすることでちょっとした失敗によるリスクなどを防ぐことができます。
そういった「何かが起こってからしかわからない」問題は運用コストとしてあまり表に出てきにくいのですが、だからこそ、あらかじめ投資すべき箇所だとも言えるでしょう。何か起こったときの対応に工数が避けないプロジェクトこそ、事前にそこに投資をすることで、結果として運用コストやリスクを低くすることができます。
データを失ってからバックアップソフトを購入しても遅いのと一緒ですね。本気で走ることに集中するためにも、事前にこういったフローをきちんと考えておくことが大事です。

6-3 運用を考える

キャンペーンサイトなどであれば基本的に出したらそれで終わりで、一発本番。修正のきかない世界でした。非常に緊張感があり良い経験だったのですが、最近はそのようなデザインの仕事の割合は減ってきているのではないでしょうか。私のような事業会社のインハウスデザイナーは出して終わりではありません。むしろ世に出してからが本番であり、遥かに長い航海となります(正しくはそうなるように信じて作っています)。使ってくれるユーザーの反応や世の中の流れ、さらなる事業拡大のためにPDCAを回しているというのが一般的でしょう。
ちょっとしたパーツの見せ方の改善からサイトやアプリ全体に関わるリブランディングまで、世に公開した後もデザイナーの仕事は続きます。そのうえで大事なことは、いかにきちんと継続的な更新がしやすいよう運用していくかということです。コードを書くエンジニアはこのようなことをよく考えていますが、昨今はデザイナーも同じようなことが求められるようになってきています。
「このデザインはなぜこうなっているのか」という明確な理由がまとめられていること、あとから見ても正しい挙動になる仕様や、スタイルの変更などが比較的容易にできるデザインデータの作り方をする、などの保守性も求められてきます。
全くデザインの変更をしない場合でも、新しいスマートフォン端末が出れば、ある程度の修正は必要になってくるでしょう。他の人がそのプロジェクトに参加したり、別の人に引き継ぎをしなければならないことも多々あるでしょう。そんなときに、過去の仕様を理解したり紐解くために時間を使うのは、決して効率たらのよい方法とは言えません。自分だけが理解できていればいいというわけではないのです。極力、そういったコストを削減するために、それを前提としたドキュメントの作成やデザインの構成をしていく必要が出てきます。

ガイドラインはどうあるべきか

Human Interface GuidelinesやMaterial DesignのようなOSに紐づいたガイドラインはすでに紹介していますが、サービス単位のガイドラインについても軽く触れておきましょう。これらはどういう位置づけであるべきなのでしょうか。
もともとはデザイナーのために位置づけられたものであることがほとんどだったと思いますが、最近はガイドラインの枠を飛び出しデザインシステムとして、より広い範囲で利用をされることが増えてきました。スタイルとコードが常にセットで提供されて、エンジニアがそのままUI実装をできるような手助けをするパターン。デザインの思想とスタイルがセットで語られることにより、他のデザイナーとの協業がしやすくなるパターン。プロデューサーやディレクターも既存のパーツを組み合わせることで、より具体的なイメージが作りやすくなるパターン。こうしてさまざまなところで、デザインシステムとして利用できるようになっています。

図6-09 AtrassianDesign
図6-10 BBCGEL
図6-11 LightningDesignSystem

デザインシステムには先に書いたような機能的な役割があるのはもちろんですが、それ以上にここに込められているのはUIデザインの意思だと思います。「こんな世界を実現したいから、こんな課題を解決したいから、こういうUIデザインになった」という意味が込められて、初めてUIデザインとして成立するのでしょう。
ガイドラインやデザインシステムを作る際は、単純なルールブックやUIパーツの寄せ集めではなく、そのUIサービスを体現し牽引していくためのデザインシステムであることを強く意識してみてください。ドキュメントそのものには意味がなく、そこから生み出されるクリエイティブに意味を持たせるために存在するということを強く意識しましょう。
デザインシステムに関しては『Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド』という書籍が非常にわかりやすく説明されていますので、興味のある人はぜひ手にとって読んでみてください。

属人化しないデザインデータの作り方のすすめ

さて、ここでは少し目線を変えて、作られたデザインではなく、それを構成しているデザインデータ(SketchやPhotoshop、Illustratorなど)について考えてみましょう。
デザインの良し悪しには直接的な関係はないかもしれませんが、継続的にそのプロダクトを磨き込んでいくことを考えると、デザインデータの作り方は非常に大切なものです。大前提は「わかりやすくする」ことですが、「そのデザインの意図を伝える」ことも大切な目的です。

・自分が1年後に見てもデザインの意図が理解できるか
・デザインをした人でなくても、新しいデザインを追加できるか
・デザイナーでなくてもパーツの役割や構成が理解できるか

これらはプログラミングの世界では当たり前ともいえることですが、意外とデザインデータの世界では軽視されがちです。そのため、レイヤー名などもデフォルトのものがそのまま使われていたりすることもよくあります。しかし、デフォルトのレイヤー名はあくまでデザインをする段階の補助となるものでしかなく、あとで見てわかるようなものではないのです。
いくつか例を上げてみましょう。

図6-12 予約状況を表す○と×は形状を表す「Oval」ではなく、パーツの意味を表す単語として「Availability」などを利用するほうがわかりやすい
図6-13 正しくグルーピングがされていないとどのパーツの要素なのかがわかりにくい
図6-14 タップ時のフィードバックの状態を表す名前を示す
図6-15 変形をする可能性のあるパーツにはリサイジングを設定しないと使い回しがしにくい
図6-16 横断的に使われるパーツは正しくスタイルやシンボルを定義しておかないと、あとからの修正が大変になる
図6-17 シンボルのオーバーライドのレイヤー名は、対象となる役割を示す名前にしておかないと何を入れる場所なのかがわからない

実際に比べてみれば一目瞭然であることがわかるでしょう。
作る段階ですべてを考慮した作りにしなければならないわけではありません。むしろ、よりスピード感を重視し、ラフでいいので早く数を作り上げるほうが大事なフェーズも多くあります。
しかし、ある程度スタイルが決まってきたら、きちんと構造化された構成にしていかないといずれデータを作り続けていく中で不整合が起きてきます。頭の中でもそれを整理しきれていないので、余計なパターンを作ってしまったり、似た色だけど微妙に違う色のものなども作り上げてしまうことになるのです。
そうなると先に書いたように他職種との連携もより難しくなります。意味があって違う色なのか、それともただの間違いなのか。右に1pxずれているのはわざとなのか。案外、デザイナーではないほうが客観的に見られる分、よく気づいたりすることもあるものです。
最近のデザインツールはより機能が複雑化してきており、パーツの使い回しや編集など実際の実装に近しい考え方も増えてきました。それだけに、どのような作り方をするかで、実装するエンジニアもその意図を理解しやすくなっていますし、文字だけではないコミュニケーションをとる1つのツールとしても活用できるようになってきたと言えるでしょう。
もし他職種(ディレクターやエンジニア)もSketchデータを使う場合、そのあたりを意識しましょう。エンジニアと会話をし、実際のコーディングルールに合わせた命名をするのもいいですし、逆にきちんと、誰が見てもわかるようにムリに英語を使わずみんなが呼んでいる名前に合わせるのもよいでしょう。これらはどのパターンが正解というものはありません。一緒に利用する人の中で「このパーツはこう呼ぶ」「この動きはこう呼ぶ」という共通言語を作ることが何よりも大事なのです。共通言語というと難しく感じるかもしれませんが、チーム内で用いる用語集のようなものだと思えばよいでしょう。
前述のように、自分が作ったデザインデータでもそれを自分だけのものと思わず「こういう使い方もされるかもしれない」「こう書いておいたらわかりやすいかもしれない」という視点を持って作っておくことも、またデザイナーに求められている技術と言えるでしょう。
かっちりとしたルールをいきなり作る必要はありませんが、どこかでそういった意識を持ち、長期的視点で見たときにも使いやすく、わかりやすいデータを心がけていきましょう。そういった小さな心がけが結果として効率的なデータを生み、デザインのスピードを上げていくことにつながるのです。

デザイナーと数字の関係

なぜ今デザイナーに数字を見る力が求められているのか

デザインと数字は縁がないものだと思っていませんか?しかし、実際は密接に関わっているのです。過去に得られた指標を基にデザインを作る、またその逆で、デザインを評価するために数字を見る。人間の感情はそのまま数値化することはできませんが、実際にユーザーがそのUIを使った記録や数字は、そのデザインを評価する指標となり得るのです。
ユーザーが直接触れるもの、一番ユーザーに近いものを作るのがUIデザインという仕事ですが、つまりそこから生まれる行動データもまたそのUIデザインの延長線上にあるものであり、その一部だと言えるでしょう。それだけにUIデザイナーにとっては非常に身近な存在であり、それを身近な存在として捉えなければなりません。
自分自身が作ってきたデザインが意図どおりに使われているかの検証に利用したり、逆にそこから課題点を見つけ出してくるのは、そのデザインを作ったデザイナーが一番真剣に考えるべきだと私は思います。自分の作ったデザインに責任を持ち、それを磨いていくのは当然デザイナーの仕事です。
とはいえ、決して難しいものと捉える必要はありません。サービスやサイト全体を見ようとするのはとても大変ですが、まずは自分が手がけた、特に思い入れのあるUIデザインや、サービスの根幹となるUIの使われ方から見てみるのがよいでしょう。

どのような数字を見ればいいのか

先に書いたように、デザインをおこなう際にはそのアウトプットの評価として定量的な数字を目標として持つことがあります。それらの目標はKGI(Key Goal Indicator:重要業績評価指標)やKPI(Key Performance Indicator:重要目標達成指標)という指標で表されます。

・PV(Page View:特定のページが閲覧された数)
・セッション数(サイトへの訪問回数)
・UU(Unique User:サイトへの訪問者数)
・DAU(Daily Active User:1日あたりの利用ユーザー数、月間の場合はMAU)
・CTR(Click Through Rate:表示数に対してのクリック率)
・CVR(Conversion Rate:訪問者数に対しての顧客転換率)

さらに、これらをかけ合わせたPV/セッション(1セッションあたりのPV数)など、サイトの特性に合わせてさまざまな指標が利用されます。
これらすべてが直接デザインに関わっているわけでもありません。ただ、それらの数字が事業に求められているならばデザインの面からそれを支える、それもまた今のデザイナーに求められていることではないでしょうか。
もちろんその指標を追うことによりユーザー体験を損なってはいけません。デザイナーの立場から考えるべきなのは、自分の作ったデザインが一体どのような影響を与えるのか、どれだけの人に影響を与えたのか、より良い体験を提供するためにはどのようなデザインがいいのか、それらを判断するための軸としてきちんと意味を理解しておくことです。その上でデザインをはかるための指標自体をデザイナーが自ら考え評価するということがとても大事になってくるのです。


-------------------------------------------
[コラム] A/Bテストで陥りやすいワナ

昨今はGoogle OptimizeやFirebase、KAIZEN Platformなど、比較的気軽にA/Bテストをできる環境が整ってきています。明確にどちらが良いという答えを出すためのすばらしいアプローチですし、デザイナーとしても調整をするための心理的障壁を低くしてくれるとても良いツールです。
しかし、そこでも闇雲にA/Bテストを繰り返せばベストアンサーが出るというわけではありません。誤解を恐れずに言うならば、A/BテストはAとBを限られた条件内で比較した場合に「どちらが良いのか」しか教えてくれません。さらに言うと、ちょっとした条件が異なった場合はその結果が変わるかもしれませんし、他にもっとよい答えがあるかもしれません。何より、そもそも「なぜうまくいったのか」というのも仮説を出していくことしかできないのです。
一例としてショッピングサイトを例に考えてみましょう。

図6-20 ボタンのA/Bテスト

ランディングページで、購入ボタンのCTR(Click Through Rate:表示数に対してのクリック率)の高いページを作ろうとA/Bテストをおこない、一番押されるページデザインを作ることができたとします。しかし原点に立ち戻ってください。「このページのボタンを押されるUIを考える」のがこのページにとってのベストなデザインではありません。「このショッピングサイトで購入をしてもらうことを促す」デザインが正しいUIデザインです。
結果としてCTRを向上させたが実は購入数が増えていなかった、場合によっては遷移先のページがボタンを押したユーザーの期待値に答えられず、購入数が減ったということも起こります。しかし、全く異なるページデザインによってそれが起きている場合は、どの部分が起因してAとBに差ができたのかは予想するしかありません。
A/Bテストでは、大原則として複数の要因比較をしてはいけません。というよりも、正確にいうと複数の要因比較を同時にしても結果がわからないのです。
もしそれを厳密に測りたいならば、延々とパターン数を増やしていくしかありません。AとBの単純な比較であれば2パターンで済みますが、AとBにそれぞれ2種類ずつバリエーションがあった場合は4種類。AとBに4種類ずつあった場合は8種類と、延々と増えていきます。そういったバリエーションを手動で作るのも大変ですが、何より、そんなに大量のパターンのテストを回すには相当なユーザー数がいないと難しいでしょう。そうでないと1パターンにあたるユーザー数が少なくなってしまい、確率の信憑性が極めて低くなってしまいます(多変量テストやKAIZEN Platformが採用している決戦方式でのテストはこれらをカバーする手法の1つです)。

図6-21 レイアウトと色を2種類ずつのテストをする場合、その組み合わせは4種類になる

また、絶対にしてはいけないのが、複数の意図を混ぜてしまうことです。

・ユーザビリティ
・ビジネスモデル
・デザインの美しさ
・利用するコンテキスト
・etc.

これらは同じ軸での判断ができません。混ぜ込んでテストをしても、どの要因で良い結果が出たのかを推察するのは困難です。何をテストしたいのかを定め、同じ軸で比較してこそ、初めて「なぜ、この結果になったのか」を検討できるようになるということを覚えておきましょう。

-------------------------------------------

デザインは何を解決するのか

デザインの変更によってさまざまな定量的な指標はどのような影響を受けるのでしょうか。たとえばECサイトを例に考えてみましょう。

1. 商品を探す(商品検索)
2. 内容を確認する(商品詳細)
3. 購入をする(購入完了)

図6-22 それぞれの場面で求められることは異なる

この3つの画面をあなたはUIデザイナーとして担当します。商品を探すページでは、当然ですが、より多くのクリックを生むことが購入数の増加につながります。しかし、商品を探す際によく写真やタイトルを見ずにクリックされるようにデザインしてしまうと、商品詳細ページにいった後に購入につながらない可能性が高くなってきます。ユーザーの期待値を必要以上に上げてしまい、その期待値に沿わない商品を見せてしまうことで離脱をしてしまうのです。
これでは大きな「がっかり体験」を生んでしまいますし、それを積み重ねると、もうこのサービスを使いたくないと思われてしまうかもしれません。
それぞれのページでの数字を追いすぎるがあまりに、結果として、たくさんの離脱者を生むことで長期的な目線でのユーザー数を減らしてしまうかもしれません。それを防ぐためには、UIデザイナーはきちんとそのページでの目的を理解し、ゴールに向けて一番良い体験を作り出すことが求められます。
商品検索ページではたくさんの商品を見比べることが目的ですし、商品詳細ページではその商品の詳しい説明が見やすいことが求められます。購入ページでは、そこから購入をしたいと思った瞬間にすぐに購入ボタンを押せること。それぞれページで全く求められることは違い、単純にクリックされることだけを増やすのではなく、よりその場に応じたUIを作り出すことがとても大切です。
そのためにはきちんと長期的な目線を持った指標を追うことが大事です。
商品検索ページでは、当然ですが、CTRが重要なKPIとなってくるでしょう。しかし、前述のようにCTRを高めるためだけに不用意に目立たせるのは逆効果になります。
最終的に一番大事なのは購入数で、これがKGIとなります。それを最大化するためには、商品検索ページでのCTRよりも、商品検索ページから購入完了ページまでのCVR(Conversion Rate:訪問者数に対しての顧客転換率)が重要な指標となってくることがわかるでしょう。
さらにここでは記していませんが、もっと長い目で見た場合、このサイトでまた買い物をしてくれる回数を増やすことも非常に大切です。そうなるとリテンションレート(既存顧客維持率)も大事な指標となってきますし、それを向上させるためにはちょっとした体験の気持ちよさ、使いやすさ、信頼性も大事になってきます。
そういった意味でCTRやCVRのように短期的な数字を見るのではなく、デザイナーとしてはより長期的な目線で1か月、半年、1年といったスパンで、ユーザーが何度も使いたくなるような、そんなデザインを作っていくことが求められるのです。

✂===================


いかがでしたでしょうか?読みにくい部分もあったかもしれませんが、この本の魅力を少しでも感じていただければ嬉しいです。電子書籍版もご用意しておりますので、ぜひ購入して他の章も読んでみてください!


頂いたサポートは次なるUIデザインやその記事に役立たせて頂ければと思います!