2020年に読んだ本

読書メモ

フロントエンド / Web

UI/UXデザイン

開発手法

AWS関連

自己啓発・その他

まとめ

2019年と比べると3〜4冊少なめ。
SAPの試験本ばかり読んでる時期があることを考えると、思ったよりは読んでました。
結構偏ってしまった印象で、Vueやフロントエンド周りのインプットが書籍ではできてないという感じですね。

リモートで通勤時間なくなって本を読む習慣を付けづらくあるのが難しい所ですが、時間的には前より増えているはずなのでうまく時間みつけて今年も本を読んでいきたいです。

2020年後期のWebサイト

Webサイト

2020年後期分です。

RSSでギャラリーサイト購読して気になったのはPocketでブックマークのなかから選んでます。
今回はジャンル別で分けてみました。

医療系が多めになってしまいましたが、特に注目していたわけではないのでたまたま好きなサイトが多かったのかなと。
テイストとしては柔らかめのものでも今までよりもがっつり柔らかい感じではなく適度なものが多めで、パリッとしたサイト（V-RESAS, ベンザブロック, ジャストシステム）も対象に入るようになりました。

個人的ベストは、気仙沼 男山本店のサイト。
今までWebで見たこと無いトーンやレイアウトで印象が強く残りました。

医療・福祉

V-RESAS | 新型コロナウイルス感染症が地域経済に与える影響の可視化

f:id:jotaki:20210303120654p:plain https://v-resas.go.jp/

鼻水・のどの痛み・熱。症状別の風邪（かぜ）薬ベンザブロック

f:id:jotaki:20210303120703p:plain https://benza.jp/

医療法人社団せいおう会 | 鶯谷健診センター

f:id:jotaki:20210303120716p:plain https://seioukai.jp/

株式会社 日本・精神技術研究所（日精研） | 心理アセスメント・心理トレーニング

f:id:jotaki:20210303120735p:plain https://www.nsgk.co.jp/

天水福祉事業会

f:id:jotaki:20210303120753p:plain https://tensui.or.jp/

コーポレート

株式会社にんべん｜鰹節やだしの製造販売なら

f:id:jotaki:20210303120808p:plain https://www.ninben.co.jp/

次の「あたりまえ」をつくる - ジャストシステム

f:id:jotaki:20210303120828p:plain https://www.justsystems.com/jp/

TAGUCHI | タグチ工業

f:id:jotaki:20210303120844p:plain https://www.taguchi.co.jp/

株式会社果実堂テクノロジー

f:id:jotaki:20210303120853p:plain https://www.kajitsudotech.co.jp/

気仙沼 男山本店｜蒼天伝・美禄・男山｜創業大正元年

f:id:jotaki:20210303120904p:plain https://www.kesennuma.co.jp/

メディア

SUB-ROSA

f:id:jotaki:20210303120914p:plain https://sb-rs.com/

The Graphic Design Review

f:id:jotaki:20210303120930p:plain https://gdr.jagda.or.jp/

gooone（ゴーン） | 三浦・三崎の観光情報マガジン

f:id:jotaki:20210303120947p:plain http://gooone.help/

その他

ホンマタカシ監督「建築と時間と妹島和世」

f:id:jotaki:20210303121007p:plain https://kazuyosejima-movie.com/

養生ごはんのひみつ | 大阪北堀江の薬膳 天然食堂かふぅ

f:id:jotaki:20210303121024p:plain https://cafuu-shokudou.com/

2021年2月 振り返り

月次振り返り

結果

ブログ

目標：月 8 回（週2回）更新
結果：月 4 回 更新

読書

目標：月 1 冊
結果：月 1 冊

反省点など

振り返りすらままなりませんでしたが、ちょっと復調

来月に向けて

資格勉強も落ち着いて色々勉強する気持ちになれているので、まずは昨年残しになってしまったものからがんばります。

【読書メモ】オンスクリーン タイポグラフィ 事例と論説から考えるウェブの文字表現

読書メモ UI/UX

先日、オンラインの発売記念イベント にも参加した「オンスクリーン タイポグラフィ」を一通り読んだのでメモしておきます。

オンスクリーン タイポグラフィ 事例と論説から考えるウェブの文字表現

オンスクリーン タイポグラフィ 事例と論説から考えるウェブの文字表現

目次

構成はWeb Typograpy, Accessibility, Web Font, Historical Changesの大項目からなり、上記の各10ページ前後のコラム文、それらに関する10例程度の事例を画面キャプチャ付きで掲載されています。 コラムもビジュアル多めなので文章を読む感覚はさほどなく、めくりやすい本だと感じました。

ポイント

気になった点などのメモです。

01_ オンスクリーンタイポグラフィの本文

  • 文字サイズはPCで16px相当が2020年現在で最も読みやすいサイズといえる
  • 行帳は全角35〜45文字がひとつの目安
  • サイズ指定は相対指定で
  • 書体は基本的にユーザはデフォルト書体が読みやすいのでは。しかしそこでデザイナーが思考停止するのも良しとは言えない。
  • Webフォントも日本語の場合デメリットがフォーカスされがちだが、書体開発など業界のこと考えるとそこも尊重すべき選択があって良い。
  • コントラスト的に黒は#111〜#333がベター、#000は少し強く感じる。
  • 文字詰めは主要ニュースサイトで本文で font-feature-settings を適用しているサイトはなし。
  • 各環境での最善を尽くしつつ、ユーザーの自由度を奪わないデザインを心がけるべき。

事例の選定、イトイ新聞とTHE FASHION POST、Yahoo！ニュースのピックアップでらしいなあと思った。

02_ Webで紙のようなレイアウトを実装するには

  • 見出しの文字詰めを実現するには font-feature-settings, letter-spacing を使うことが代表例だが、イラレからアキ情報取って使うことも可能（getKerning）
  • 本文の約物が続いた場合の処理はアキを自動調整するフォントを使う方法がある（約猫）
  • text-align: justify にすると欧文の長めの単語が入ると前の行が不自然に開くときも。 そのときは hyphes: auto に
  • その他、行間を基準にしたグリッド設計、箱組みのためのfloatボックスの活用など

03_ オンスクリーンタイポグラフィの夜は明けたか

デジタルメディアの特徴や課題として、

リリース後ほぼ変わらないコンテンツを最大限に魅力的につくろうとする取り組みとは逆に、どんな内容でも見やすい状態を提供する可視・可読性のためのフォーマット設計の方を重視すべき場面も多い。

とありますが、自分も最もデジタルで考えるのはその点。うまいデザイナーの定義あげるとするとその点がうまい人がWebのデザインがうまい人と思ってます。

また乗り越えておきたい課題として、「実装者を評価する」をあげています。

デジタルメディアのエンジニアは、視覚的な完成度や意味、文書構造、情報構造などに対する興味が薄い場合がある。プログラム的素養を高めるほうが業界での年収が上がりやすい一方で、視覚的な再現はエンジニアリングを介さずとも実現できる仕組みづくりが活発になってきているため、目標とし難いのが実情なのであろう。 ... プログラムしたものを伝わる、使える形に転換できる。そんな実装者を評価し、よきパートナーとなることもクオリティ改善の一助となるであろう。

こちらも深くうなずきたい部分で、デザインの再現性や汲み取りする能力をエンジニアは評価されづらいと思う。（or そもそも評価軸がない。）それはエンジニアの評価はエンジニアが行うというのも大きいように感じていて、より良いものが世の中に出回るようにデザイナーや視覚性を大事にしている人がもっとフックアップ的なことをすることも大事なのかなと思っています。

04_ Webアクセシビリティとタイポグラフィ[前半]

  • Webのメディア特性として、特徴的な点はユーザー自身が見た目を変更できる点がある。
  • コンテンツ側はよいデフォルトを提供し、ユーザーはユーザースタイルシートなどを活用しコンテンツとユーザーが協力した形でよいタイポグラフィが実現できる。
  • WCAG2.1達成基準例
    • テキストは支援技術なしで200%までサイズ変更できる
    • 使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが使われる
    • テキストブロックブロックでは利用者が全景と背景色を選択できる。幅が80字を超えない（全角の場合は40字）

05_ Webアクセシビリティとタイポグラフィ[後半]

  • 文字サイズは実機で評価する
  • サービスのターゲットに合わせて適切な文字サイズを選択する
  • 視野は個々人により異なる。重要な要素ほど中央寄りに集める
  • 疑似ボールドは意図しない潰れの原因になるので使用しない

06_ プロダクトのアイデンティティを表現する文字

Apple, Google, Uber, Dropbox, Atlassian, Facebook, Twitter, Figma, 楽天, メルカリの書体選定や使用例。
確かにAppleのSan Franciscoなど自社開発でのフォントが増えるなか、TwitterはHelvetica Neueを使用していて普遍性を強調しているのが印象的です。最近、Chirp フォントが出回っているので、そのようにサービスに組み込まれるかも楽しみです。

07_ 「読みやすさ」の不思議

  • 「読みやすさ」の指標はさまざま。道路標識と書物では異なる視点でのフォント選びが必要
  • オンスクリーンでの「読みやすさ」は「バックライトによる文字のアウトラインのぼけを考慮したフォントを選ぶこと」
    • ふところの広い書体
    • 縦線と横線のコントラストが低い
  • スクリーン向きのフォントの例にオンスクリーン用にリデザインされた Benton Sans RE などは使ってみてよいのでは
  • 各UD書体、オールドスタイルでも丸明オールド、明朝で3種類のコントラストが用意されているTP明朝もオンスクリーンに適している

08_ 日本語Webフォントの過去、現在、未来

  • Webフォントの変遷（2009年〜）
  • 日本語環境ならではの配信技術（ダイナミック・サブセッティング）
  • セルフホスティングでの配信
  • 日本語Webフォントの文字詰め機能
  • Webフォントのサイズはサンセリフ体よりセリフ体のほうが基本は軽くなる。（アンカーポイントが少ないため）

日本語環境におけるWebフォントの課題について、Webフォントを導入すると重くなる、は必ずしも正解ではなく、さまざまな配信技術やレンダリングの方法があるのでそれを使っていきましょうという方向性の話でした。

表示が遅く感じる理由は、システムフォントが表示された後に、Webフォントの表示が開始されることに起因していることが多い。つまり、この画面がチラつく挙動が遅さを感じさせてしまうのである。

確かに盲目的にWebフォントは遅いっていうイメージにとらわれている感は否めないので、きちんと切り分けして考えないとなと思いました。

09_ Webタイポグラフィの変遷と現代的常識

感想

この本に掲載されているような文字周りのCSSって、ボックスをレイアウトしたりするCSSとはまた別で、そこの対象範囲で興味を広げないと今のブラウザでできることやスタンダートなことを捉えるのがなかなか難しかったりすると思っているのですが、今回この本を通してそのあたりはインプットできた印象があります。
ただもっと大枠の選定の話とか、先日のイベントの際にも感じましたがここ数年追えていない感が残っていて、たづがね角ゴシックは結構使いやすいと言われてる書体なんだなとか、そんな程度なのでもうちょっと追いついておきたいなあという焦りも持ちました。

オンスクリーンに絞ったタイポグラフィ系の書籍は ウェブタイポグラフィ もありますが、今回のオンスクリーンタイポグラフィも初学者が読むには敷居が高めな印象もあるので（基礎的な内容もあるが発展系への展開もある部分で）、もう少し大衆的な雰囲気のあるベーシック部分をカバーした書籍も今後出るともっと裾野が広がるというか興味を持ったり意識を持ちながら仕事をする人が増えるのかなと感じます。
決して教科書的なこうしなさいというやり方を教える成分は弱めかなと思います。こういう考え方がありますよの提示的要素の強い本だなという印象です。

ともかく久しぶりに発売が楽しみな本があって、それを予約して届いて読んで、執筆陣も個性豊かでとてもお気に入りの本になりました。

【イベント】Front-End Study #4「いま考えるユーザー体験とデザイン」

イベント UI/UX

ForkwellさんのオンラインイベントFront-End Study #4「いま考えるユーザー体験とデザインの世界」を視聴しました。
フロントエンドエンジニアがデザインとどう向き合うべきかという興味のあるテーマの中で各セッションを聞けたので、メモと感想を残しておきます。

セッション

  • 基調講演「フロントエンドエンジニアが今学ぶべきデザイン」
  • セッション1「共創するためのデザイン批評」
  • セッション2「サービス横断デザインシステムのフロントエンド開発に携わって学んだこと」

基調講演「フロントエンドエンジニアが今学ぶべきデザイン」

サイバーエージェント 谷さん
発表Figma： https://www.figma.com/file/a4m5ohTjU6JWZ80CGVTAMd/Front-End-Study-%234?node-id=44%3A103

FLOCSSのは知ってましたが、魅せるiPhoneサイトもこの方だったんですね。昔とてもお世話になりました。
スマホのリキッド実装と拡縮実装の両方どっちが正解やスタンダードが分からなくて、本読んで腑に落ちた記憶があります。

フロントエンドエンジニアができること

マイクロインタラクション

表現としてのエフェクトはデザイナー
ただリアクションには多くの領域が含まれる（VoiceOverに対してなど）のでエンジニア側も一緒に考える必要。

レイアウト

ずれているのが問題というより設計された情報の意味や狙っている効果がなくなることが問題
そうならないために「デザイン」をプロセスとして遡る必要がある
レイアウトの意図、情報構造の設計を理解してそれに適したマークアップをする

パフォーマンス

Core Web Vitals（LPC/FID/CLS）
CLSの向上は実装する段階ではもうどうしようもないこともある
状態ごとのパターンのデザインを作る

デザインへの接し方

  • デザインの批評・レビューをする
  • デザインの仕組みをつくる
  • UIデザインのアプローチを変える
  • デザインツールを使ってみる

デザイナーとフロントエンジニアのデザインの境界はない
職務ではなく役割として考える

質疑応答

Q.異なる職種でやってよかったこと、うまくいかなかったこと
新規のタイミングからみんなでFigmaに向かいあってやるとよい
デザイナーは途中経過のものは見られたくないみたいな感覚が初期はあるがそこを1回乗り越える

感想

レイアウトのところでピクセルパーフェクト論ではなく、伝えたいことが伝わるかが大事というところでちょっとハッとしました。
自分はデザイナーの意図汲んでコーディングするの得意と思ってますが、完璧に再現できるのが大事というよりは本質的にユーザーに届くかが大事だなと思って今後はその視点でやっていこうと思いました。
Figmaの使い方にちょっと触れていましたが、考えてみたらこれワイヤーとデザイン並行で同じところに描けるのでおもしろいですね。

セッション1「共創するためのデザイン批評」

ClassDo takanoripさん
スライド： https://speakerdeck.com/takanorip/gong-chuang-surutamefalsedezainpi-ping

デザイン批評の基本

デザインがプロダクトの目的を達成するために適切かどうかを判断する
批評には適切な方法がある

デザイン批評とデザインレビューの違い

  • デザイン批評：デザインが目的を達成できるか判断するための分析手法
  • デザインレビュー：デザインの承認や合意形成のために行われるミーティング。

ベストプラクティス

  • 質問で始める
  • 感情のままに話さない
  • 自分の意見が正しいと思い込まない
  • 意見を押し付けない
  • 長所について話す
  • 「誰の視点から考えているか」を考える

おおまかにスタンスとしてはコードレビューと同じですね

見た目にとらわれない = 見た目の好き嫌いを表明することは「批評」ではない
エンジニアがデザインに口出しし辛い風潮があるのは見た目に意識が行っているからで、本質に焦点を当てることが必要になる

デザイン批評

  • デザインの目的を理解する
    • なぜこのデザインにしたのか、これがレビューの「基準」になる
  • 使いやすさを確認する
    • 達成したいことを迷わず達成できるか
  • ダークパターンになっていないか

デザインレビューで考慮すべきポイント

  • UIの一貫性（一貫性のないデザインを鵜呑みにしない）
  • 実装難易度
    • 本来はデザインつくる前に確認する
  • データとUI
    • データ構造とUIに矛盾がないか

みんなではじめるデザイン批評 はデザイナーもエンジニアも読んだほうが良い

感想

どこからどこまでがデザイン批評と定義されどういうメリットがあるのか話されていたのでその点が一番勉強になりました。
見た目にとらわれない、っていうのはなるほどなあと。
ある程度慣れが必要とも感じますがデザイン確認するとき基本実装可否についての確認に留まってしまっていましたが、もうちょっと踏み込んでやってみようと思いました。

セッション2「サービス横断デザインシステムのフロントエンド開発に携わって学んだこと」

ヤフー 春野さん
ヤフーのデザインシステム「Riff」の開発においての話

デザインシステムを作る目的

  • UIデザインの品質向上
    • デザインの当たり前品質を担保する
  • UIデザインの業務効率化

制作物としてはスタイルガイドとUIライブラリに分けられる

デザインシステム制作の流れ

  • スタイルガイド制作グループ
  • UIデザインキット制作グループ

  • コーディング開発グループ それぞれ5名程度、兼務でジョイン

  • プロダクト側へヒアリング

  • 必要なスタイルガイド、コンポーネント洗い出し

取り入れているツール

React/TypeScript/StoryBook
ビジュアルのテストツールには reg-suit
これはVRT（ビジュアルリグレッションテスト）というものでビジュアル面のテストが行える
reg-suitは変更前と変更後のキャプチャを撮って差分を確認できる

感想

ビジュアルリグレッションテスト、初めて知りましたが便利そうで使ってみたいですね。
デザインシステム制作チームの人員ってYahooでもだいたい兼務でということだったので結構大変そうだなと・・・
最後にメインの仕事のノウハウ持ってこられるというのを聞いてメリットもあるなあと感じました。

全体感想

一応括りはフロントエンドの勉強会で視聴人数はそこまでなかったと思いますが、平日夜にオンラインで1000人規模で興味持たれるイベントもすごいよなあと感じました。スポンサーもついてライトなTV番組みたいです。
全体としては、登壇した方々は自分と同じフロントエンドエンジニアという職種で、組織として個人としてデザインへの関わり方の熱量がちょっと違うなというところでモチベーションが高まりました。自分ももともとデザインから入った世界というのもあり、そこにもっと向き合う必要がありそうです。

次回もなかなかつよつよなメンツなので参加してみたいと思います。

【イベント】タイポグラフィを武器にする 〜文字とデザイン、WEBとUI、そしてUXのお話〜

イベント UI/UX

イベント概要

Connpass： タイポグラフィを武器にする 〜文字とデザイン、WEBとUI、そしてUXのお話〜
書籍『オンスクリーン タイポグラフィ 事例と論説から考えるウェブの文字表現』の発売記念イベントとして、この書籍から派生して現場で使えるTipsやあるある話などを共有する会という感じでした。

トークテーマ

など、実際の現場レベルでのよくある悩みやこれどうしている話をされていました。

登壇者はGoodpatch Anywhereのカワセさん、ハマダさん、SmartHRの桝田さん、編集者の宮後さん。 自分の中ではネット上での昔からの有名人の方々でした。

オンスクリーン タイポグラフィについては、カワセさん、ハマダさん、桝田さんなど計9名の方の論説をまとめている本です。 2/17の発売で今読んでいる最中ですが読書メモは別でまとめます。

勉強になったこと

「ガイドラインを守ることが大事」ではなく、主観によって判断されがちな色の指定などの基準にこういうのを使うといいですよっていう内容

桝田さんはアクセシビリティに大変詳しいエンジニアの方ですが、自己紹介の流れで書籍のコラムの内容についてこのように最初に話していて、そういう心持ちなのかとちょっと意外なところもありました。
個人的な勝手なイメージですがアクセシビリティ詳しい人と詳しくない人って分断されがちで、詳しくない人（自分）は詳しい人を怖がっているところがある印象があります。
それに加えて「善意のバリア」的な見方で、僕の去年読んで一番印象に残った記事にある、「アクセシビリティはさ、誰かのためにとかじゃなくて、自分のためにって思ってやるといいと思うよ」 的なスタンスでのトークだったのでとても自分ごととして勉強させてもらえました。

要素をちゃんと作ってからページデザイン作成

  • カラーパレット作る
  • フォントサイズのジャンプ率作る

コンポーネント作る前にこれらをエンジニアと話して進めるだけで後々の辛さが軽減されるというは納得です。

デザインカンプの一枚絵ではなくレイヤーなどのデザイン構造など中間成果物のなかを見ること

どういうデザインがコーディングしやすいか、みたいな話の流れだったと思いますが、デザインで空けられているスペースが16pxなのか1文字分として空けられているのかはデザインデータ見て分かると実装もしやすいと。
自分もエンジニア側なのでもちろん同感で、リストテキストのline-heightでリスト間のマージンを取っちゃうかline-heightは適正値で取ってちゃんとスペース開けるかで全然違うところかなと感じました。

また難しいデザインが上がってきたときにチーム全体で解決できなくフロント側だけが負荷がかかってしまうことが問題みたいな考え方も、これまでそういう取り組み方で仕事あまりしてないのでなるほどそういう考え方なんだなあと思いました。

アクセシビリティ向上、「向上」は何を持って判断しているのか

定量的な結果ではなく、特定の機能が特定の条件で動く
例えば特定の機能をキーボードのみの操作で完了できるなど。

まとめ

失礼ながら書籍の宣伝的な要素が強いイベントと思ってましたが、その要素がゼロだったので楽しかったです。
参加する前はデザイン的な話がメインかなと思ってましたが、聞いてみると実装のテーマや内容に関してばかり興味が惹かれたり勉強になりました。
登壇のデザイナーさんの話聞いてると実装のリテラシーも高いんだなというのが印象的でした。

【読書メモ】UI/UXデザインの原則

読書メモ UI/UX

UI/UXデザインの原則

UI/UXデザインの原則

  • 作者:平石 大祐
  • 発売日: 2020/10/23
  • メディア: 単行本（ソフトカバー）

目次

  • 原則1【:HOW】ユーザー心理/行動をとらえる
    「ユーザー心理/行動に則って考える」ことがUI/UXデザインの第一歩である
  • 原則2【:HOW】どう改善するか
    「ユーザー真理/行動」をUI/UXデザインに落とし込む
  • 原則3【:HOW】どう改善するか〈体制とプロセス〉
    UI/UXデザインにおける三方良しをつくる
  • 原則4【:応用編】
    UI/UX思考でこれからのビジネスをデザインする

ざっくりになりますが、
原則1では、どのようにユーザー心理を捉えUXを改善していくか、例えばユーザーテストなど手法的なことの説明。
原則2では、主にUI改善の例が挙げられています。
原則3では、UI/UX改善を行う上でどのような組織や体制を保つことが大事かについて、
原則4はまとめになります。

ポイント

原則1【:HOW】ユーザー心理/行動をとらえる

「ユーザー心理/行動に則って考える」ことがUI/UXデザインの第一歩である

新しい機能を追加するなど改善施策を打ってみても頭打ちになる、などだれしも抱える問題はなぜ起こるのか
→ 多くの場合、サービス提供側の想像と現実のユーザニーズに乖離があるがそれに気づかないことが要因

ユーザーのリテラシーや、ユーザーのサービスへの期待値を正しく理解し、ユーザーが自然と「自分だとこういうふうに使えそうだ」と想起できる状態をつくり上げる。それこそがUI/UXをデザインするということなのです。

WEB担当者とユーザーのニーズはすれ違う

Web担当のニーズとユーザーのニーズがすれ違う原因
→ "詳しくなりすぎてしまう" ことと、"考え方が偏ってしまう" ことにある

定量分析だけではユーザーのニーズはつかめない

定量分析と定常分析の使い分け

  • 定量的なデータ → ユーザが離脱するポイントを特定
  • 定常的な分析 → 離脱する原因

相互補完的な仕組みを導入することが必要

ユーザー体験の時間軸をとらえる

サービスの「利用前」「利用中」「利用後」にまたがる時間軸で潜在的なニーズを正しく把握するのが基本

  • 利用前：予期的UX
  • 利用中：一時的UX
  • 利用後：エピソード的UX
  • 全体：累積的UX

原則2【:HOW】どう改善するか

「ユーザー真理/行動」をUI/UXデザインに落とし込む

ユーザーニーズに沿って情報を組み立てる

ユーザーのステップごとの不安や解決したいことに沿って、ゴールとなるCVまでスムーズに情報を組み立ててあげる必要があるのです。

  • 重要事項が事前に確認できる
    • ユーザーが遷移前のページで不安や懸念を解消できているか
  • CTAのワーディングをわかりやすく
    • 具体的にボタンをクリックしたときに何が起こるかをイメージできるか

ユーザー視点で情報をデザインする

文脈を理解せずにただ同じデザインを当てはめるのではなく、類似の機能であってもユーザー視点に立ち、大きさ・色・表記など各パーツのデザインの理由を明確に説明できるようにすることあ￥が重要です。

初期体験こそ丁寧に設計しよう

サービスを初めて利用する「最初の体験」で多くの課題が出てくる傾向
初期体験における情報取得は理由とセットで設計する。

外で利用されることを考慮する

特にスマホアプリなどの場合、白ベースの背景は避けるなど

先人の知恵を借りる

初めて訪れたユーザーの不安を取り除くTips

  1. CTAのワーディングを分かりやすくする
  2. CTAは統一する
  3. 重要事項の説明を行う
  4. マイクロコピーを活用する

気持ち良く使い始めてもらうためのTips

  1. パーソナライズする
  2. プッシュ通知の許可は承諾する価値を伝えてから表示する
  3. 必要なタイミングで最低限の説明を
  4. 最初にやるべきことを制限する
  5. 擬似的にAHA!体験させる

使い心地が良いサービスをつくる "おもてなし" Tips

  1. 待ち時間を工夫する
  2. 重要なページから離脱する際は、確認画面が表示される
  3. 検索時に候補をレコメンドする
  4. 最小限のページ切り替えで情報を把握させる
  5. 相談して決めることを考慮する

原則3【:HOW】どう改善するか〈体制とプロセス〉

UI/UXデザインにおける三方良しをつくる

UI/UXデザインにおける品質（良い結果が得られる状態）は「ビジネス（戦略・収益・営業）」「テクノロジー（開発・システム）」「UX（顧客視点）」の重なるところに生まれる

現状は「UX」に関する人材・体制が不足

ユーザーファーストの組織 / 体制が命運を握る

本来は、マーケティング部門や開発部門、運用部門も含め、社内の各部門がユーザーと向き合う機会を持つべきです。

UI/UXが重要という認知が広まっているなかで、実際の取り組みに落とし込めている組織は少ない。

  • 実際に手を動かす現場の担当者レベルがUI/UXデザインの意義や具体的な手法を十分に理解できていないこと
  • 意義も具体的な手法も分かっているのに、UI/UXの改善に取り組める体制になっていないこと

が大きな要因の2つ。

  1. UI/UXデザイン責任者を立てる
  2. リリース判断基準をつくる
  3. UI/UXの評価基準を均一化する

など、横串で管理するチームを設け、会社全体で品質を担保していく

感想

本のボリューム的には軽めで何時間かで読めます。
内容は基本的なワードも注釈での説明があったり、大事なポイントを列挙している感じで初学者向けの印象で、デザイナーやWeb担当者以外にも読みやすいUI/UXの取っ掛かりになるような本でした。

逆にいうと深堀りはされていないので、例えばユーザテストの手法についてじっくり学びたい人は ユーザビリティエンジニアリング、UIついては インタフェースデザインのお約束 のほうが特化はしています。

会社でもユーザーテストなどをやり始めている段階ですが、個人的には手法や細かいUI改善例というよりビジネスとしてUI/UXがなぜ必要とされるかについて把握できたところがよかったかなと感じます。
単純にUXに向けての興味がここ最近薄れていたことも相まって、必要性を認識できるとやる気が湧いてきました。

また手法以外のところで、原則3のような体制をどのようにするかというところも興味があるので、その分野に特化している本を別で読んでみるのも面白いかなと感じました。