ぶちあたった壁に対する回答のような本【縁の下のUIデザイン】
勝手に夏休みの課題図書に挙げてたこちらの本！読みましたー！！どこにでも持ち歩き、真剣に読みすぎてボロボロなった….😂
🌱 内容は実践的かつ具体的で、それを「まとめた本」です。Web上に記事もあるので自分がnoteにまとめる必要は全くないのですが、備忘録的に。
🌱 具体的な内容は本（か記事）を読んだ方が断然早いので、各章を読んで、なるほど！と思った箇所を書き留めてみました。（全章ではありません）
🌱 本の目次の順番ではなく自分がこれは！と思った順に並べてます。
全部で7章あって、1〜5章はTips的な内容です。実務で使うのは1〜5あたりだろうから6章以降はまたヒマな時にでもまとめようかな…？と思っていたのですが、個人的に6章が一番おもしろかった…！（最初の方に持ってきてます）
■初期リリースにおける理想像とのずれ
本当はミニマムリリース時の状態を想定して開発をしなければいけませんが、継続した開発ができない場合、できる限り多くの要件を盛り込んで開発しようとしてしまいがちです。リリース後デザインの変更なども行えないため、理想状態に最適化したデザインを作った結果、リリース時に使い勝手の悪いサービスになってしまうのです。
「目標はこうありたいよね」という未来のサービス像（理想状態）と、「こういう状態でリリースしよう」という初期のサービス像（ミニマム状態）、この2つの視点は分けて考えておかなければいけません。
未来のサービス像と初期のサービス像のズレの例として「1,000商品を扱うECサイトを作りたいが、オープン時は10商品しかない」「1,500記事を扱うポータルサイトを作りたいが、ストックが10記事しかない」などが挙げられていました。
依頼主は当然、理想状態を前提にしているし、開発が進んでいくうちに良い案が浮かんできてより良い方向へ向かって行くこともあると思うのですが、デザイナー自身が初期のサービス像と未来のサービス像にはズレが発生するということを認識しておくだけでも意味があるな🤔と思いました。
・理想状態を待ってリリースするのか
・理想にはほど遠いミニマム状態でなるべく早くリリースして価値検証するのか
私としてはミニマムリリースすることを普段からお勧めしているため、初期リリースを想定してデザインすることが多くあります。ただし理想状態もイメージしたい場合は、2つの案を同時に作るようにしています。
🐤 夏休みの読書感想文 🐤
スタートアップでやるような、01で作ることに慣れた経験豊富なプロダクトデザイナーさんならみんな知ってることだろうけど、自分は本を読むまで気づかなかった…
実装時に困らないように「UIパターンを全部出す」という意味で、情報がMAXに入っている状態で作って、情報がない場合はエラー画面のように例外的に追加作成していました。全画面作ると間に合わんというのもあったけど。
どこもかしこもなんも情報がない、面白くなさそうな画面も試作して議題にあげるとかアリだな🤔
■画面遷移を意識した改善
「小さな改修に目が行くと全体の流れが損なわれる。小さな改修で高い効果が得られる施策を優先することは当然のように感じるが、小さな改善を積み重ねていくと以下のような課題が出てくる」
・施策が小粒になってしまい、ユーザーが良くなったと実感してもらえるレベルに達しない
・改善が部分最適になり、前後の文脈に違和感が出て、改善した箇所以外が改悪になるケースがある
一部の数値は向上しても流れの中で不自然な動きが多くなると、中長期的なリスクにつながる可能性がある。
🐤 夏休みの読書感想文 🐤
改善が部分最適になり、前後の文脈に違和感が出て、改善した箇所以外が改悪になる
本業では前任者が作ったデザインを引き継ぐことが多いのですが、まさにこの状態になりました。いったんミニマムで開発してリリースできる状態になった後、クライアント企業の担当者さんにシステムを使用してもらい、追加で出てきた改善要望に沿って部分最適をやったのですが、ボタン文言変更ひとつとっても「ボタン押下後のダイアログの文章との不一致」「遷移先ページのタイトルとの不一致」などが発生したので、スプシで一覧表を作成して全体の流れが損なわれないようにしました。
■デザインシステムで統一感を持たせる
デザインシステムを構築するメリット
・一貫した使い勝手をユーザーに提供する
・統一した視覚表現で魅力的な世界観を表現する
・提供しているサービスの思想や価値観の認識を開発者間で合わせられる
・スタイルやコンポーネント単位でソースコードを共通化し効率化する
デザインガイドラインに含まれるもの
・UIコンポーネントのパターンライブラリ
・スタイルガイド
・アイコンやフォントなどのリソース
・CSSフレームワーク
・React Components
🐤 夏休みの読書感想文 🐤
昔、簡単なWebサイトをコーディングしたりしてたので、htmlとcssは基礎レベルならわかる状態だけど、さすがにjsのフレームワークは全くわからない。。VueとかReactって良く聞くし、特にシステム開発ではTailwindみたいな不可欠なやつなんだろなー程度の認識でした（※今も）
本に取り上げられていたGitHubの事例では、DesignのInterface guidelines には「Buttonusage」があり、DevelopmentのReact/CSS には「Buttons」があって、前者だけだとデザインガイドライン、後者だけだとコードを書くためのフレームワークに過ぎず、これらの両面がちゃんと1つの考え方やしくみによって作られているからこそデザインシステムとして機能する、と書かれていました。
■UIデザインのためのGA
ここは本にしかないコンテンツかも。GAを使って数値を取る場合の設計方法（仮説＆検証）などが書かれていて興味がある人は買って読んだ方がよいかもです。6Pにまとめられているので（私含め）分厚いGA4の本に挫折しそうな人におすすめしますｗ
🐤 夏休みの読書感想文 🐤
内容は、KAIZENのグロースハッカーやってた時や、某有名ECサイトを担当した頃に経験したまんまの内容でした。プロダクトデザインやりたいって思ってるけど今までの経験は無に帰るのか〜と思ってたので、あ、そうでもないのかって思った箇所でもありましたw でもやっぱ本で取り上げられてた例はECサイトだったな🤔
ここらへんまでがだいたい本の後半から後ろの方に置かれていた内容です。（主に6章）
この後の7章もおもしろかったのですが、特に「業務用サービスのデザイン」の箇所は現在進行系で「どうにかせねば」と感じている内容だったので、何度か読んでこっそりブラッシュアップ案作って提案してみようかな？🤔と考えてます！
こう作っちゃったけど、こうした方がよかったんじゃ…と思ってたことがまんま書いてあったりして「やばいやっぱりそうか😱」みたいな…
以下、1〜5章の内容から、気になった部分をピックアップ
■コンテンツがない時に考えること
ここもネット上にも記事がなさそうだったのですが、ユーザーの体験を大きく変えそうだなと思ったのと、個人的にすぐこういうことをやりたくなる方なので、書いてあることをざっくりまとめました↓
・ユーザーの行動によって状態が解決できるケース
コンテンツがないことを伝えると同時に、どうやったらユーザーが見ている画面にユーザーが見たいものが表示されるようになるかも伝える。
・ユーザーの行動によって状態が解決できないケース
機械的に表示できるコンテンツがないことを伝えるだけでなく、サービス運営側の予定やそれによって今後表示されることなど、なにかしら詳細な内容を伝える。
■カードUIの向き不向き
目的を明確に持たないと良さを引き出すことができない。同じ情報で異なるコンポーネントのデザイン案を作ってみると思想に合うものがどれか判断しやすくなる。
■未読と既読
無駄な未読表現を控える。未読表示がつくことでCTRが高まることはあるが、厳選した情報でないと機能しなくなる
ユーザーにとって不必要な情報を未読として出すと未読を消化しきれなくなる
未読を既読にするタイミング、方法をちゃんと考える。既読にしづらい状態だと未読がたまり、ストレスとなる。
■エラーと確認
必要条件が成立しないと押せない（disable）にするより、どんな状況でも押せる状態にしておいて、押したらエラー箇所と説明を示してあげた方がユーザーが思った通りに行動することができる。
エラーで驚かせないように、エラーメッセージの文体を機械的にせず気持ちを込めた人間らしい文体にする。赤をつかうとしてもサービスの体裁と調和するような色合いにして印象を和らげる
デザインする前に実社会の体験を想像して置き換えることで、確認方法も自然なものになる。
■受動的な体験のデザイン
「UIはユーザーの体験（UX）によって変化します。逆に言うと、どういった体験をしてもらうかによってUIが決まるのです。を意識することが重要です。」
この本、よくある「◯◯の教科書」ではなく、完全に参考書です。しばらくはこの本片手に作ることになりそうです！
この記事が気に入ったらサポートをしてみませんか？