【読書メモ】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のような体制をどのようにするかというところも興味があるので、その分野に特化している本を別で読んでみるのも面白いかなと感じました。

AWS ソリューションアーキテクト プロフェッショナル 受験記(再)

f:id:jotaki:20200105065609p:plain

これまで・今回の結果

受験理由・モチベーション

年末年始で勉強時間取れそうだったので。
と思い1/3に受けましたがもう1ヶ月やることになっちゃいました。

今回分の勉強計画

前回受験時にあと20点まで来ていたので、問題集(koiwaclub)をもっとやり込むことを中心に考えました。

やったこと

koiwaclub の SAP問題集

前回もやりましたが計5周くらいしました。
https://aws.koiwaclub.com/exam/sap/

その他

  • 【読書】AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説
  • 【公式】Exam Readiness: AWS Certified Solutions Architect – Professional
  • 【公式】BlackBelt Online(YouTube中心に)
  • 【公式】サンプル問題の復習
  • 【公式】模擬試験の復習

特に勉強したこと(苦手分野)

  • オンプレとAWSの接続(BGP、パブリック/プライベートVIF、静的/動的ルート、IPv6、DX、DXGW、VPN
  • ネットワーク周り(複数リージョン/AZでのVPC接続、VPCピアリング、中央VPC、TransitVPC、TransitGW、VPCエンドポイント)
  • Active Directoryでのアカウント管理、認証認可
  • アカウント制御やOrganization(アカウント、権限、コスト管理、SCP・一括請求、AssumeRole)
  • CloudFormation(クロススタック、マルチアカウント管理、ServiceCatalogとの組み合わせ)
  • 権限の委任手順(クロスアカウントアクセス、Saasサービスなどほかアカウントに対して)
  • EC2のインスタンスタイプ
  • ログ保存(CloudWatch Logs、CloudTrail)
  • API Gateway、Lambda エラー時のトラブルシューティング
  • セキュリティ、鍵管理 KMS、CloudHSM
  • コスト管理(Badgets、Cost Explorer、コスト配分タグ)
  • 静的/動的コンテンツのCloudfront振り分け(ALB/CF/EC2)

本試験

今日受けた合格分に関して。
解いたときの印象は、

  • 40% => 正解
  • 20% => たぶん正解
  • 20% => どっちか分からない
  • 20% => 不明

という感じ。20%くらいは初見の問題で他の80%は問題集などで見たパターンでした。

スコアの862点は良すぎかなと思います。
これまであと20点の壁を超えられなかったのに、ここに来てこれまでのAWS試験で一番点数高いのは嬉しいような不思議な気持ちです。
年末年始にSAA本から読み直してSAP本や問題集は毎日コツコツやっていって、普段AWS触らなくても地道にコツコツでやっていたのが良かったと思います。

まとめ

去年の2/14にアソシエイト3つ目のSOAを取ってるので、SAP取るのに1年かかった結果になってしまいました。
7月くらいにギア上げて8月まで受けて年末に再度ギアをあげてという感じだったので、もっと効率性を求めないといけなかったなあと反省しています。

何度も受けているので今回もまたダメかなあと思いながら終了ボタンを押しましたが、合格の文字が見えたときはやればできるんだなあとちょっと感慨深くなりました。
クラウド資格は次AWSのDOPかGCPのアソシエイトも受けてみようかなと考えてますが、年末から張り詰めていたので一旦それをほどきたいです。

2020年10月 振り返り

結果

ブログ

目標:月 8 回(週2回)更新
結果:月 0 回 更新

読書

目標:月 1 冊
結果:月 0 冊

反省点など

ぜんぶ反省です。

来月に向けて

11月も立て込みそうなので12月から本気出せるように・・・

2020年9月 振り返り

結果

ブログ

目標:月 8 回(週2回)更新
結果:月 9 回 更新

読書

目標:月 1 冊
結果:月 2 冊

反省点など

Vueもさわれたし勉強会もいくつか参加できたので、久しぶりに良い内容だったかなと思います。

来月に向けて

そんな忙しくなければSAPの勉強も再開したいですが、その前にいろいろ今後に向けてやりたいこと整理する期間にしようかなと考えています。

【イベント】UX MILK All Night

9/12-13に行われた UX MILK All Night を視聴したので、見たセッションの気になったことなどをメモします。
アーカイブもあるのであまり詳しくしない程度にとどめたいと思います。

f:id:jotaki:20200921181854p:plain

目次

A1-2 : UXデザイナーが作るサービスの業務フロー設計

受託型の業務フロー設計、PoC時のUXデザイン手法について
スピーカー:高橋一成さん(株式会社オロ)
まとめnote:UXデザイナーが作るサービスの業務フロー設計 @ UX MILK All Night

前提

UXデザインはユーザーを理解するところから始まる

チャートでの設計手法

システム中心の書き方の3つの手法

  • アクティビティ図 => ユーザーのシステム上での行動を把握しやすい
  • ユースケース図 => システムでできることが把握しやすい
  • シーケンス図 => データの流れが把握しやすい

今回のフローチャートはユーザーの行動が中心の書き方。

UXフロー図

  1. ステークホルダーを書く
  2. それぞれの行動を書く
  3. ステークホルダーが表示する画面を書く
  4. 機能やシステムの振る舞いを書く
  5. パーツとしてならべる
  6. 矢印を使ってフローをつくる

アクティビティ図はシステムの分岐視点になるが、UXフロー図はユーザー体験中心の視点の図ができる。
ステークホルダーや関係ツール全体の行動や振る舞いを一覧化することで

  • 予算感が見える
  • フェーズが立てられる

こともメリット。PoCなど全体が見えづらいプロジェクトに適している。

  • ユーザーの行動を追いながら
  • ユーザーのタッチポイントを考えながら
  • 必要な機能を確認しながら

などリアルな行動を意識しながら書くと良い。

プロジェクトの進め方

サービス全体からアプローチ版(PoCの場合はこちらが多い)

  1. [UXフロー図]サービス全体をイメージする
  2. [UXフロー図]必要なフローや機能を見つける
  3. [UXフロー図]機能・画面・フローを考える
  4. ワイヤーフレーム・実装]ワイヤーフレーム・モックを作る
  5. ワイヤーフレーム・実装]機能・画面フローを調整する

ユーザーの理解からアプローチ版

  1. [インタビュー・ペルソナ・エクスペリエンスマップ]ユーザーの行動を観察する
  2. [インタビュー・ペルソナ・エクスペリエンスマップ]ユーザーのインサイトを見つける
  3. [インタビュー・ペルソナ・エクスペリエンスマップ]ユーザーの課題を見つける
  4. ワイヤーフレーム・機能実装]サービスのアイデアを考える
  5. ワイヤーフレーム・機能実装]機能・画面・フローを考える

感想

受託でPoC案件が前提の話だったのでいまいる会社に近い感じもあり熱心に聞けました。
UX設計やります、っていっても1つではないアプローチの方法があってそれを実践できるようにしたいなと思いました。

A1-3.5 : 受託制作におけるデザインシステム

受託制作における汎用的なデザインシステムについての知見
スピーカー:石原隆志さん(GrowGroup株式会社)
スライド:Design system for Client Work - Speaker Deck

デザインシステムを作った経緯

事業規模拡大、理念体系の変更により時間をつくったり、共通認識となる旗が必要と感じたため。

デザインシステムの導入

デジタルプロダクトの目的を達成するために首尾一貫したルールで編成された、お互いに関連付けられたパターンとその実践方法。
吉幾三。こういうのオンラインだと難しそうですね・・・
今回は受託制作の会社の場合のため、汎用性を持たせること、どこまでの自由度があるのかなどの共有が難しかった。

これらの課題に対して

  • デザインシステムに関する勉強会、ミーティングの実施
  • デザイナーのコーディングスキルの習得(Udemyなど中心に)
  • クロージングミーティングの開催
  • 社内で運用システム、フロー(委員会)を構築
  • ツールの拡充
  • ドキュメントの充実化

などできるだけスキルレベルに依らず使うようにするためハードルを下げる施策を行った。

感想

自分も2人や20人の受託Web制作会社で今まで社内ツール作るのに頓挫した光景を見る経験を何度もしているので、めちゃくちゃしっかりやっててすごいなと思いました。

A1-4 : UXデザインにおける眼と手と動きの解像度を上げる技

眼と手と動きの解像度を上げる方法
スピーカー:安藤幸央さん(株式会社エクサ)
スライド:UX MILK All Night 2020 (Yukio Andoh)

  • 中心視野はかなり狭い
    • 視野の移動をなるべくさせない
  • 白黒・色反転・左右反転・補助線・比較でゲシュタルト崩壊を防ぐ

手(指)

  • 体験の解像度を下げる(おじさんでも爪を伸ばしてみる)
  • 人間は35,000/1日、選択している(2秒に1回)
    • 選択を分解して人の体験を分析する(コーヒーと角砂糖)
    • Netflix は登録なしで見れるように

動き

なぜUIアニメーションさせるのか

  • 画面や要素が切り替わったことを知らせる
  • 変化をより把握しやすいものにする
  • 小さなものにも注意を促す注目をしてもらう
  • 動きによって楽しみを感じてもらう
  • 正しい情報構造の理解を手助けする

人間は情報を順繰りに渡される方が理解しやすい

オブジェクトを触わってから

  • 50~100msあとにアニメーション開始
  • 300~400msでUIアニメーション
  • 50~100msあとにアニメーション停止

すると動きを知覚しやすい

感想

話慣れてるなー感がすごかったです。
なぜUIアニメーション必要なのか、自分は極力必要ないならしない方向に持っていってしまいますが、理論化、言語化して提示くださったので、その方法で考えていきたいと思いました。

A1-5 : しなくていいUX

スマートロックのUXについて
スピーカー:神谷郁さん(Qrio株式会社)
スライド:しなくていいUX - Speaker Deck

しなくていいUXとは?

  • ユーザーが抱えている負の体験を「しなくていい」
  • ユーザーが製品を使う上で余計な体験を「しなくていい」

「ユーザーが抱えている負の体験を」「これまでよりもスマートな体験で」解決するアプローチ => 課題解決のアプローチと近い
AmazonUber、サマリーポケットの例

Qrio LockのUXデザイン

ユーザーが抱えている負の体験を「しなくていい」
=> 本来したいことに時間を使える
=> 家を出たらカギが閉まって家に帰ってきたらカギが開いてほしい

出かける前 / 出かける時 / 外出中 / 帰宅した時 / 在宅中 のステージごとに課題・不便を抽出

ユーザーが製品を使う上で余計な体験を「しなくていい」
=> 余計な階層を辿らなくていい
=> 新しい技術を覚えなくていい
=> セットアップに時間をかけなくていい

セットアップに対して「自分でもできる」感を訴求
・貼り付けるだけで使える訴求
・既存設備に取り付けられる訴求

感想

先ほどの解像度のセッションもですが、不自由・負の部分の洗い出しを行ってから設計するということで、ハードウェア・ソフトウェア関係ないのかなと感じました。
カギをかけない人はいない、って言っていてビクッとしました。

A1-8 : インクルーシブデザインとUX

インクルーシブデザインでできることについて
スピーカー:佐野実生さん(株式会社コンセント)

インクルーシブデザインとは

  • インクルーシブデザイン => デザインプロセスに多様な人を巻き込む 手法
  • ユニバーサルデザイン => すべての人が利用できるデザインである 状態
  • アクセシビリティ => すべての人がアクセスできる 状態

多様な人 は特定の誰かではなく、みんなのことを指す。
極端ユーザーからの顕在ニーズを抽出すして未来の当たり前をつくること。

例)未来の当たり前

特定の環境や制限のある状態は誰にでも当たり前にあり得る。

インクルーシブデザインチームの取り組み&実体験

どうすれば伝わるだろう?という問いかけを意識する

  • 画面に頼らない説明をする
  • コピペ最高
  • 字幕はあるに越したことはない

感想

画面共有のココ問題、自分もリモートになって感じました。
UDトーク、噛んじゃいけないプレッシャーもありそうですがめっちゃよかったです。
本当に言っている通りで倍速で追いやすいですし、自分にとっては一番良いインクルーシブデザインの例でした。

A2-4 : システム開発でデザイナーは何をすればいい?

システム開発の要件定義・設計フェーズにおいてデザイン思考をどのように取り入れてるか
スピーカー:高見祐介さん(株式会社電通国際情報サービス
スライド:UXMILKallnight_システム開発でデザイナーは何をすればいい?

不確実性を下げる

要求定義・要件定義・基本設計・詳細設計で2つの思考

  • システム思考(全体・抽象化志向) => 物事を全体的&体系的にとらえ、多くの視点から構造化し可視化する
  • デザイン思考(部分・具体化志向) => 完成的なアプローチで観察、発想、試作を何度も繰り返し共創する

フェーズ別のアプローチ

  • 要求定義 => ペルソナ・カスタマージャーニーマップマップなど仮説
  • 要件定義 => UI設計書をつくる(デザイナーが)
  • 設計 => 対象ユーザの決定とユーザビリティテスト

実施したアクションの合意形成(クライアントと伴走することが大事)

  1. 画面イメージを検討し、該当業務プロセスで必要とされる機能を洗い出す
  2. 早い段階からUI画面のレイアウトと仕様項目のイメージをつかむ
  3. 画面遷移と発生イベントを優先的に確認する

デザイナーががんばること

要求・要件定義フェーズから参画しましょう

感想

開発会社の方なので他の方とはちょっと毛並みが違って面白かったです。
「正しいものを正しく作る」まわりの話をデザイナーさんが意識しているとこのような解釈方法になるんだという新しい発見がありました。

A2-7 : 複雑性と難易度の高いサービスリニューアルにおけるサービスデザイン

CULTIBASE のサービスデザインについて
スピーカー:瀧知惠美さん(株式会社ミミクリデザイン)
スライド:複雑性と難易度の高いサービスリニューアルにおけるサービスデザイン - Speaker Deck

サービスデザインの特徴的なアプローチ

This is Service Design Doing サービスデザインの実践 より

  • 人間中心
    • 関わる人の体験を考慮する
  • 共働的であること
    • 関係者が積極的に関与する
  • 反復的であること
    • プロセスは探索・改善・実験の繰り返し
  • 連続的であること
    • サービスを行動の連続として捉える
  • リアルであること
    • 現実世界でリアルに調査、実験する
  • ホリスティック(全体的)な視点
    • サービスと企業全体まで含めた視野をもつ

利害関係者を巻き込んだ「共創」を大事にしたい
=> 「同感的にかかわり」ではなく「共感的かかわり」(1人称視点+2人称視点)

サービスデザインで大事にしていること

  • 「ユーザーにとっての理想」と「自分たちが目指す理想」を徐々に折り合いをつけていく
  • 1人称視点でと3人称視点でこれまで培われたサービスの特色を大事にする
  • 既存ユーザ・新規会員・社内メンバーとのコミュニケーション

サービスデザイン(リニューアル)の難しさと取り組み方

リニューアルが失敗する要因 => 一新したことで既存の価値が損なわれることが一般的
なぜそうなりやすいかというと、既存・新規の2つのユーザーに考慮し、既存・新規の2つのサービスを動かさないといけないから

  • 2つのユーザーへの対応方法
    • 既存ユーザーと新規ユーザー両者にとって快適なあり方の探求
    • 既存ユーザー+新規ユーザー2人のペルソナを作成
  • 2つのサービスへの対応方法
    • リニューアル前とリニューアル後のスムーズな接続の設計
    • リニューアル後の世界観へ徐々に移行させていく

一新する(renewal)ではなく、洗練させる(refine)。

感想

サービスという範囲がわりと広いものだと思っているのですが、リニューアルの話は一般的なWebサイトでも通じることがあるかなと思いました。(要求・要件にもよりますが)

A3-2 : 良いUXを実現するために、まずはチーム内にデザインを浸透させている話

Qiitaなどを提供するIncrementsでUXデザインを浸透させている話
スピーカー:綿貫佳祐さん(Increments株式会社)
note:UX MILK ALL Night - 良いUXを実現するために、まずはチーム内にデザインを浸透させている話|綿貫 佳祐 / Ateam, Increments|note

なぜ「チーム内」か

  • 優れたUXデザイナーはチームに「UXと向き合う文化」を導入している
  • デザインは「デザイナーだけでやるもの」ではないと思っている
  • 組織にこれまであまりデザイナーがいなかった

取り組み

デザインスクラムというエンジニアがデザインの勉強する取り組みを実施

  • サービスの立ち上げの調査や企画
  • Figmaを使って自分でUI作成

良い変化

  • デザイナーの考えが分かるようになった
  • 一連の流れが理解できるようになった
  • UIにまで踏み込んだので制作する際の勘所が良くなった

苦労したこと

  • 実務ですぐに何か成果が出るかというと、出ない

感想

スライドがめちゃめちゃ見やすかったです。
QiitaのUIも段々良くなってきていますが、もっとよくなればいいなあと思います。

A3-10 : 1人でこっそり始めるUXデザイン

UXデザインを身近な所からはじめてみましょう、というお話
スピーカー:鈴木毅さん(株式会社メンバーズ)

何から始めればいい?

ユーザー調査 => ユーザビリティ調査

  • インパクトが大きい
  • テクニカルスキルがなくてもできる
  • 制作者は始めやすい

具体的な始め方

  • 準備
    • 協力者を探そう
  • 実査
    • イントロ
    • 事前インタビュー
    • タスク実施
    • 事後インタビュー
  • 分析
    • 有効さ・効率・満足度
  • 共有

感想

一人ではじめる、なのでスモールスタートで参考書や書籍に書いてあることは全部やろうとしないでいいんじゃないかと言っていてなるほどなと思いました。
確かにUXの書籍に書いてある内容を実践しようとするには、仰々しい部分もあるかなと思うので・・・

全体の感想

自分はエンジニアで登壇されている方はデザイナーの方が多いと思いますが、そういう職種の垣根を超えて仕事をしているのだなという発見と刺激を受けました。
「共創」「伴走」や「負の体験を取り除く」「不自由から学ぶ」のような近しいキーワードもセッション間で見受けられ、デザインする対象がハード/ソフトに関わらず、制作の考え方が勉強になるイベントでした。

ゆっくり見たいもの見たい派なのと、朝型なので今回アーカイブ形式を購入してみましたが、セッション内容的にとても満足でした。

【読書メモ】ウェブタイポグラフィ - 美しく効果的でレスポンシブな欧文タイポグラフィの設計

前回の オブジェクト指向UIデザイン に続いて、同じ時期に話題になっていたウェブタイポグラフィを読みました。

目次

  • はじめに:わたしたちは皆タイポグラファ
  • 1章:読まれるための組版
  • 2章:タイポグラフィのディテール
  • 3章:フォントの選択と使用
  • おわりに

章立てはシンプルですが各章でボリュームあります。
対象としてはIAやデザイナー、エンジニアということで、HTMLやCSSに関してはある程度の基礎が分かっていると楽しく読み進められるかなと感じるレベルかなと思います。

ポイント

はじめに

ウェブですばらしいのは、さまざまな形を取れること、そして読み手がニーズに合わせてそれを形づくれることです。これは弱みではなく強みであり、バグではなく機能です。

ウェブデザイナーには柔軟性が求められるのです。ウェブデザインは読み手の緩急王に順応するものであるべきで、読み手がニーズに合わせてデザインを調整することが不可欠です。

これは特にタイポグラフィに限った話ではなくウェブのプレゼンテーション全体の話だと思うのですが、自分もこういう考え方で良い妥協点を見つけれる人がウェブのデザインがうまい人かなと思っています。

1章:読まれるための組版

読むということ

インタフェースデザインの心理学 にもあったサッカードなどの話。
ただそれよりも詳しい内容 中心視では一度に4、5文字しか読めないが脳はすべてのテキストに焦点が合っている。

フォントサイズの単位

主に em rem ch px がある。

ただし基本的には、ページと一緒に要素を拡大縮小したい場合は rem を使用し(グローバルなサイズ設定)、コンポーネント内で拡大縮小したい場合は em を使用します(ローカルサイズ設定)。

段落のデザイン

可読性のバランスを支えるのは以下の3つ。

  • カラム幅(行の長さ)
  • 文字サイズ
  • 行間
カラム幅

一般的な印刷物は1行45〜75文字で設定されている。
画面で読むには行が長め(最大100文字)でも悪影響は出ない。ただし読み手は短めの行を好む。
スマホは1行で42文字がおおむねちょうどよい。
和文の場合はこれらの文字数の半分強を目安にする)

文字サイズ

段落にはデフォルトの文字サイズを使用する。
各デバイスメーカーは適切な初期サイズとして16pxを採用。
アクセント付きの文字をベースにデザインしたフォントはxハイトが低いので、同じ16pxでも他のフォントに比べて小さめになる場合も。

行間

行の高さは文字サイズとカラム幅に合わせる。
line-height: は単位無しで指定する(自分は単位無し= em で指定だと勘違いしていました)
フォントによって調整が必要だが1.4を設定するところからスタートする。(和文は1.7程度から)

快適な行間を設定するにはカラーのの均一化とカラーに対して心地よい黒みの量にすることを目指す。

  • フォントのストロークが太い => カラーが濃くなりがち => 行間をやや広げて重さを減らす
  • 幅が広く隙間がある、xハイトが小さい => カラーは薄くなりがち => 行間をやや狭めて重みをもたす

レスポンシブな段落

目からテキストまでの距離と適正フォントサイズ
Size Calculator

とはいえテキストは過度に大きすぎても読みにくくなるのでプロトタイプをなるべく作りましょう/プロトタイプのコンテンツもできるだけ実際のデータ(に近いもの)をいれた上で行いましょう

2章:タイポグラフィのディテール

記号、符号、アクセント

  • さまざまなスペース
    • ノーブレーク   /ヘア   /シンスペース   がある
  • アクセント記号を勝手に消さない
    • 特に人の名前は礼儀を欠くことになる
  • 適切な約物を使用する
  • その他
    • エリプシスは3つのピリオドではなく …
    • 乗算記号はアルファベットの x ではなく ×

階層とスケール

タイプスケール(あらかじめ定義された文字サイズのセット)を意識する。選択肢が制限されるため、組版に規律と一貫性をもたらすことができる。

  1. レファレンス(小) => 注釈など
  2. リーディング(中) => 本文
  3. ディスプレイ(大) => 見出しなど

最も小さいサイズを先に決めてから大きいサイズを選ぶ。
ModularscaleSimple Scale を使うとかんたんに試せる

デフォルトの文字サイズの場合、スマートフォンでは問題ないが、PCなど大きな画面ではコントラストとインパクトが減少してしまう
この場合、別のスケールセットをつくるのではなく、メディアクエリを使用して端末サイズをemで分岐してあげる

意味とセマンティクス

見出し

見出しの強調はスペーシングだけでそれなりにうまくできるはず。足りない場合にスタイルやウェイトの違いをもたす
CSSではh1〜h6までスタイルを指定する。デザインにない場合(h5やh6)にもh4と同じスタイルを当てておく。
レディング(行間)は狭くする

テキストまわり
  • はじまりを明確にする
    • 空白スペースやドロップキャップ
  • リードはリードらしく大きな文字にしたりする
  • リスト項目が少なく数行だけの場合は、項目感のスペーシングを防ぐ
  • アンダーラインでは強調しない
    • リンクと慣習上リンクとみなされるため
  • リンクは明確かつ控えめにする
    • アンダーラインを第一選択肢に
    • アンダーラインなしの場合は周囲とのコントラスト比を3:1にする(かなり明らかにする必要性)

テーブル

p.144 に実際のサンプルがあるが、たしかに見やすく感じる

  • テーブルは引き伸ばさない
  • 装飾や色付けは最小限に留める
  • テキストは左揃え、数字は右揃え、見出しはデータに揃える
  • 余白を利用してグループ化と分離を行う
  • 数値にテーブル用ライニング数字と一貫した精度を適用し、繰り返す($マークなど)を省略する

ラッキングとカーニング

  • レタースペーシングは慎重かつ例外的に
    • 特別に理由がない限りは小文字をレタースペーシングしない
      • 読み手が単語として把握するのが難しくなる
    • 大文字や数字が連続する場合はレタースペーシングする
    • 大きいボールドの幅広フォントは軽く詰める
    • 字間を広げる場合は合字を無効に

見出しとインパク

タイポグラフィの2つの役割

  • 小説 => 没頭させること => 読む
  • 広告看板 => 割り込むこと => 見る

ディスプレイテキストはまず見られてから読まれるテキスト

バーティカルリズムを適用する

参考: なぜタイポグラフィにおいてVertical Rhythm(バーティカルリズム)は重要な手法なのか? | POSTD

ページのバーティカルリズムは、本文の行の高さを指定した時点で設定されます。本文テキストを16px、行の高さを21pxとした場合、縦方向のスペースの基本単位は21pxになります。ページのバーティカルリズムを持たせるには、マージンやほかのテキストの行の高さなどを含むすべての縦方向のスペーシングを21の倍数にしてください。

配置と構成

モバイルファーストの哲学を採用する
画面が小さいので必然的に優先順位と階層の扱いが大事になる

メインのテキストブロックをななめ読みできるようにする

  1. 全体的な読む体験は最初のななめ読みで決まるので、可能な限りひと目で注意を引き込むようにする
  2. 小見出しは明確に識別でき、理解しやすいものにする
  3. 左側の端を明確にすることで、ページを下方に進む際の視覚的な手すりを読み手に提供する

3章:フォントの選択と使用

フォントが画面にレンダリングされる仕組み

画面はピクセルと呼ばれる極めて小さい光の点の面滅を放射します。

ラップトップやデスクトップの多くは、約140ppiの画面解像度を備えています。アップルのRetinaディスプレイなどの高解像度画面でも400ppi以下です。一方のプリンターは、比較的安価なレーザープリンターでも600dpiの解像度があり、プロ仕様のデジタルプリンターではx2,438dpiもあります。

オペレーティングシステムにはテキストレンダリングエンジンが備わっていて(複数備えていることもあります)、それぞれのウェブブラウザがどのレンダリングエンジンを使用するかをコントロールしています。

→ つまり同じOSでもブラウザによってテキストの見た目が大きく異る可能性がある。

フォントはベクターでデザインされラスタライズされて表示される。ラスタライズされるときにエイリアス/グレースケールスムージング/サブピクセルアンチエイリアスアンチエイリアス処理がある。
ただこのそれぞれの処理には何らかの欠点があったり、向いてない端末が出てきてしまう。
そのときに使うのがヒンティング。
参考) ヒンティング - 印刷用語集
Verdana、Geogia、Arialなどの主要なウェブ用のフォントはすべてのサイズで可読性が高くなるようにヒンティングの調整がされている。

マイクロソフトは正確さよりも鮮明さを優先させるというスタンス(へぇ〜となりました)

ウェブデザイン全般に言えることですが、デバイス間ですべてが同じようにレンダリングされることを期待してはいけません。自分の選択をベースに、何かがただ違って見えるだけなのか、または質が低下しているのかを評価します。

実際的及び実用的考慮事項

  • すぐにフォントを選択しない
    • どのフォントを使用するかは、特定の要件、文脈、成約、信頼性、そして最後は好みで決まる。
      • 美的判断より実用的な要件を先に考慮する。
  • ウェブサイトの性質をよく理解する
    • 今後複雑な機能を要求されるか
    • 読み手を没頭させるのか、流し読みで十分なのか
  • 必要な文字が揃っている書体を選択する
    • アクセント、約物が用意されているか
  • 必要なスタイルが書体に備わっているか
  • フォントのパフォーマンスを考慮する
  • ブランド要件に対して現実的に対応する

本文書体の決定

  • 読み手とテキスト感の摩擦を取り除く
    • 堅牢な書体の選択
    • アクティブなテクスチャとむらのないカラーでスムーズに読めるようにする
      • 読み手が長い朗読の聞き手だとすると、好奇心をそそりながらも、うんざりさせない程度に声に変化をつけた朗読(この朗読者の声のバリエーション = 書体のテクスチャ = 書体のコントラスト、フロー、サイズ)
      • Museo Sans と FS Emeric の例。わかりやすかった。
    • テキストに沿った書体を選ぶ
      • 文章の特徴をつかみ、テキストが醸し出す雰囲気をうまく表す言葉と考え、その感じやムードをデザインに取り込む必要がある
    • 自分の好みを信じる(!)

ディスプレイテキストの書体を選ぶ

  • かしこまらず、押しつけず、ありふれたものにせず
    • 書体を通じて感覚に働きかける
      • ディスプレイテキストは「読む」前に「見る」
      • 信頼性やトーン、コンテンツに対する先入観を刺激する
      • モフモフの子猫が大好き
    • さまざまなディスプレイ書体を試す
      • 働き者、個性派。柔軟性よりも個性を重視する
    • ディスプレイテキストにディスプレイスタイルを使用する

ウェブフォントを使用する

ペイロードレンダリングタイミングの2点を最適化する必要がある。

  • WOFF は TTFとOTFのラッパー。WOFF2は圧縮最適化した新しいフォーマットだがすべての環境でサポートされていないのでフォールバックを用意する。
  • @font-face でWebフォント指定していても、フォントは必要なときのみ(該当するセレクタが存在するときのみ)ダウンロードされる。
  • ペイロードの軽減
    • 使用するフォント数の制限(特にアジア圏のフォント)
    • 必ずWOFF2オプションを提供(平均30%の節約)
  • ページのレンダリングタイミングを最適化する
    • FOIT = flash of invisible text = 見えないテキストによるちらつき
    • FOUT = flash of unstyled text = スタイリング前のテキストによるちらつき
    • font-display: を使用してブラウザの振る舞いを調整
  • 重要なフォントはプリロードする
  • フォントイベントでウェブフォント戦略を微調整する

感想

ウェブのタイポグラフィでも、古いときから使われている技術やルールをかなり大事にするべきなのだなと感じた。ウェブはウェブなので、、が通じるとこがもっと多いと思ってました。
自分の悪い癖だと思うのですが、文字をひとつのデザインや見せ方として捉えている部分があって、そういう手癖でやっていたこと(本文でわりとレタースペーシング入れる、テーブルの横幅100%など)は見づらいよと書かれており反省しました。。

最初に入った会社で朗文堂通ってたタイポグラフィ詳しい方にWebだけではなく文字周りの知識をある程度は教えて頂いたのですが、最近は特にデザインもする機会もなく忘れかけていた分野だったので若干なつかしさを覚えました。
結構この分野って知識の他に日々文字を眺める機会が誰でもあると思うのですが、それを見てどう感じてということの繰り返しで身につける系のスキルかなとも思っていて、文字詰めとかも最初はなんとなくでやっていたけど、やっていくにつれて覚えていけた感があります。
本書で触れている行間の設定なども結局デザイナーの目がものをいう部分も多々にあるんだなと思いつつ、カラーなどの概念を知らないでなんとなくいい感じを脱するためには学んだほうが良い知識が揃っていました。

イギリスの リチャード・ラターさん が著者で、監訳は 鈴木丈さん が行っていますが、日本語の場合はうんぬんかんぬんも補足しないといけないこともあるのでタイポグラフィ関係の翻訳めちゃ大変そうだな・・・と思いました。

この本に関してではないですが、やっぱり和文で扱い方が全く異なることもあると思うので、そこにフォーカスした本も読んでみたいなと思いました。
ただ ウェブ × タイポグラフィ でも割と狭い世界な印象なのでなかなか難しいのかなとも思います。

ほか参考