言われたままつくるんじゃない！ BtoB業務システムのUIを"ユーザー中心"にするリアルな現場のデザインプロセス - NOT DESIGN SCHOOL 2025年4月16日
2 likes1,120 views
2025年4月16日（水）NOT DESIGN SCHOOLさまの「言われたままつくらない！ BtoB業務システムのUIを"ユーザー中心"にするリアルな現場のデザインプロセス」のスライドです。 UIデザイナーはどこまで要件定義にふみこめるのでしょうか。BtoB業務システムのUIデザインにおいて、クライアントや情報システム部門、プロダクトオーナーによる要件定義をうけとって「色つけ」するだけがUIデザイナーの役割になってしまう、という嘆きも耳にします。要件定義のままにデザインしたところ、ユーザーからは「業務に合っていない」「使いものにならない」と言われてしまう、というケースもいまだ散見されます。 BtoB業務システムのUIデザインとは、画面のデザインではなく、"業務フロー"のデザインそのものです。UIデザイナーに求められることは、ユーザーの業務とドメイン知識（業界知識）を理解したうえで、"業務フロー"そのものの再構築にふみこんで提案し、新しい"業務フロー"の具現化としてのUIを組み立てていくことです。 BtoB業務システムのUIデザイナーの"リアルな"実務で求められるデザインプロセスを学びます。
![[222]neural machine translation (nmt) 동작의 시각화 및 분석 방법](https://cdn.slidesharecdn.com/ss_thumbnails/222neuralmachinetranslationnmt-171016102621-thumbnail.jpg?width=560&fit=bounds)
![[우리가 데이터를 쓰는 법] 좋다는 건 알겠는데 좀 써보고 싶소. 데이터! - 넘버웍스 하용호 대표](https://cdn.slidesharecdn.com/ss_thumbnails/3-160416163055-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to 言われたままつくるんじゃない！ BtoB業務システムのUIを"ユーザー中心"にするリアルな現場のデザインプロセス - NOT DESIGN SCHOOL 2025年4月16日 (20)
More from Yoshiki Hayama (20)
言われたままつくるんじゃない！ BtoB業務システムのUIを"ユーザー中心"にするリアルな現場のデザインプロセス - NOT DESIGN SCHOOL 2025年4月16日
- 1. ⾔われたままつくるんじゃない︕ BtoB業務システムのUIを "ユーザー中⼼” にする リアルな現場のデザインプロセス 1 2025年 4⽉16⽇（⽔） NOT DESIGN SCHOOL 代表取締役CEO / HCD-Net認定 ⼈間中⼼設計専⾨家 ⽻⼭ 祥樹 @storywriter ハッシュタグは #NOTds ⽻⼭パートは 画⾯キャプチャ 投稿OK︕ 配信のチャットで いっしょに 盛りあがってね
- 3. 「チャット」で盛りあがろう︕ 3 さいしょに「チャットに投稿する練習」をしています︕ 今回はどうしようかなと思いまして・・・ VTuber の “儒烏⾵亭らでん” が好きです。メンシも⼊ってる。
- 6. ⽻⼭ 祥樹 @storywriter 6 ⽇本ウェブデザイン株式会社 代表取締役CEO 使いやすいプロダクトをつくる専⾨家 HCD-Net認定 ⼈間中⼼設計専⾨家 Web業界に25年、AIシステムのプロダクトマネージャーとUXデザインを7年 主な実績など 2009年 ⽇経パソコン 企業サイトランキング2009 ⽇本の主要企業696サイト中、ユーザビリティ／アクセシビリティ分野で第3位 2011年 Webユーザビリティランキング2011 企業サイト編 ⽇本の⼤⼿企業150サイト中、第4位 主な専⾨分野 ユーザーエクスペリエンス、⼈間中⼼設計、情報アーキテクチャ、アクセシビリティ、ライター
- 11. 11 要件定義に したがって デザインをおこして 要件定義 • 『部品表』 画⾯にボタンを追加したい。 • ユーザーから 「新しい部品を追加するとき、いちいちマ スタ登録画⾯に移動するのが⾯倒だ」 という要望が 多くある。 • そこで画⾯遷移なしにマスタ登録がしやすいよう、マス タ登録をモーダルで出せるようにする。 ⾃社プロダクト • クラウド⽣産管理システム 『まいたけ』 • 個別受注⽣産の製造業むけ
- 12. 12 ワイヤーフレーム 部品表 検査装置本体 製品名 1 数 品番 図番 品名 数 形式⼨法 1 HO-25 M2056 フレーム 1 SU-1 40 2 AL-26 M2038 端⼦ボックス 1 120x15 3 C-556 A076 底板 1 部品追加 マスタ 部品表 ⼯程表 受注 実績 部品マスタ登録 123-1 製番 部品表 検査装置本体 製品名 1 数 品番 図番 品名 数 形式⼨法 1 HO-25 M2056 フレーム 1 SU-1 40 2 AL-26 M2038 端⼦ボックス 1 120x15 3 C-556 A076 底板 1 部品追加 マスタ 部品表 ⼯程表 受注 実績 部品マスタ登録 123-1 製番 部品マスタ登録 品番 図番 品名 購⼊品 購⼊区分 登録 こんな 感じ
- 13. 13 デザインするなら、どれがよいでしょうか 案1. ⾔われたまま美しく 案2. 重要なボタンなので強調 案3. 主動線をジャマしない 部品表 検査装置本体 製品名 1 数 部品追加 マスタ 部品表 ⼯程表 受注 実績 部品マスタ登録 123-1 製番 品番 図番 品名 数 形式⼨法 1 HO-25 M2056 フレーム 1 SU-1 40 2 AL-26 M2038 端⼦ボックス 1 120x15 3 C-556 A076 底板 1 部品表 検査装置本体 製品名 1 数 部品追加 マスタ 部品表 ⼯程表 受注 実績 部品マスタ登録 123-1 製番 品番 図番 品名 数 形式⼨法 1 HO-25 M2056 フレーム 1 SU-1 40 2 AL-26 M2038 端⼦ボックス 1 120x15 3 C-556 A076 底板 1 部品表 検査装置本体 製品名 1 数 部品追加 マスタ 部品表 ⼯程表 受注 実績 部品マスタ登録 123-1 製番 品番 図番 品名 数 形式⼨法 1 HO-25 M2056 フレーム 1 SU-1 40 2 AL-26 M2038 端⼦ボックス 1 120x15 3 C-556 A076 底板 1
- 20. 20 要件定義 • 『部品表』 画⾯にボタンを追加したい。 • ユーザーから 「新しい部品を追加するとき、いちいちマ スタ登録画⾯に移動するのが⾯倒だ」 という要望が 多くある。 • そこで画⾯遷移なしにマスタ登録がしやすいよう、マス タ登録をモーダルで出せるようにする。 ⾃社プロダクト • クラウド⽣産管理システム 『まいたけ』 • 個別受注⽣産の製造業むけ ユーザーの本当のニーズは 「部品をスムーズに登録し たい」 ではなく 「部品をい ちいちマスタ登録しないで 部品表をつくりたい」 マスタ登録が必須の仕様 がそもそも適切でない。
- 21. 部品表 検査装置本体 製品名 1 数 部品追加 マスタ 部品表 ⼯程表 受注 実績 部品マスタ登録 123-1 製番 部品表 検査装置本体 製品名 1 数 部品追加 マスタ 部品表 ⼯程表 受注 実績 部品マスタ登録 123- 1 製番 部品マスタ登録 品番 図番 品名 購⼊品 購⼊区分 登録 21 「そもそもマスタ必須の仕様をやめさせる」 が正しいデザインです 品番 図番 品名 数 形式⼨法 1 HO-25 M2056 フレーム 1 SU-1 40 2 AL-26 M2038 端⼦ボックス 1 120x15 3 C-556 A076 底板 1
- 24. 24 “ものさし” を⾒つける
- 26. 26 次の線分は “ものさし” となる線分に⽐べて ⻑いですか︖ 短いですか︖ ものさし
- 28. 28 次の⾊は “ものさし” となる⾊に⽐べて 濃いですか︖ 薄いですか︖ ものさし
- 29. 部品表 検査装置本体 製品名 1 数 部品追加 マスタ 部品表 ⼯程表 受注 実績 部品マスタ登録 123-1 製番 部品表 検査装置本体 製品名 1 数 部品追加 マスタ 部品表 ⼯程表 受注 実績 部品マスタ登録 123-1 製番 部品表 検査装置本体 製品名 1 数 部品追加 マスタ 部品表 ⼯程表 受注 実績 部品マスタ登録 123-1 製番 29 どのデザインが好ましいでしょうか︖ プロダクトだけを⾒ていて、なぜわかるのですか︖ 品番 図番 品名 数 形式⼨法 1 HO-25 M2056 フレーム 1 SU-1 40 2 AL-26 M2038 端⼦ボックス 1 120x15 3 C-556 A076 底板 1 品番 図番 品名 数 形式⼨法 1 HO-25 M2056 フレーム 1 SU-1 40 2 AL-26 M2038 端⼦ボックス 1 120x15 3 C-556 A076 底板 1 品番 図番 品名 数 形式⼨法 1 HO-25 M2056 フレーム 1 SU-1 40 2 AL-26 M2038 端⼦ボックス 1 120x15 3 C-556 A076 底板 1
- 34. 34 BtoB業務システムのUIデザインはしばしば クライアント、プロマネ注1、PO注2、PdM注3 から要件定義をうけとって “⾊つけ” するだけが UIデザイナーの役割になってしまう という嘆きも⽿にします 注1: プロマネ = プロジェクトマネージャー、PMとも 注2: PO = プロダクトオーナー 注3: PdM = プロダクトマネージャー
- 37. 37 BtoB業務システムのUIは ユーザーの “業務フロー” を定義します 実務のプロであるユーザーに対してなお 「こうしたら今よりもっと業務がうまくいく」 UIをデザインしなければなりません
- 38. 38 UIデザイナーに求められることは ユーザーの業務と業界知識を理解したうえで “業務フロー” そのものの再構築にふみこんで 新しい “業務フロー” を具現化する UIを組み⽴てることです
- 43. これまでのシステム開発の根本的な問題点 43 要件定義でユーザーが 「ほしいもの」 を訊いていませんか︖ ユーザーが 「ほしい」 と ⾔ったもの ユーザーをしあわせに するもの
- 68. 現場の “エンドユーザー” に話を聞いて、観察する 68 現場の “エンドユーザー” に話を聞いて、そして観察するようにしましょう。 現場にくりかえし「なぜですか」 と⾏動の⽬的を訊く。 そして業務を観察することで、正しくニーズを特定できます。
- 69. エンドユーザーの「⾏動」を調べよう 69 現場の 「代表者」 にヒアリングするのではなく、エンドユーザーの 「当事者」 を調べ よう。「代表者」 の意⾒は 「推測」 が混ざる。
- 93. ゴムのユーザー 93 無意識のうちにステークホルダーに都合のよいユーザー像に寄ってしまう。 これを 「ゴムのユーザー」 と呼びます。 ステークホルダーの妄想とご都合を詰め込んだ 「実在しないユーザー」 です。
- 94. 要件定義のミーティングで落としどころを探すとき 94 要件定義のミーティングで、お客様と落としどころを探すときも 「ゴムのユーザー」 になりやすいシーンです。 「きっと」 や 「たぶん」 を積み重ねて要件を定めてはいませんか。 ユーザーはきっと こう使う たぶん こんなニーズもある なかなか議論が 収束しないな・・・。
- 100. 100 ⽬を覚ますにはどうすればいいか︖
- 104. 話 は 聞 か せ て も ら っ た
- 108. 108 現場を⾒に⾏く
- 114. 114 UIをデザインするためには まず “業務” がどうなされているのか知って “業務” をどう改善するかをデザインします
- 126. オブジェクト指向UI 126 UIデザイン⼿法としてよく参照されるのが 「オブジェクト指向UI（OOUI）」です。 オブジェクトとは、ユーザーが操作する対象の 「もの」 のことです。たとえば、写真編 集アプリを使うとき、写真⾃体が 「オブジェクト」 になります。その写真（オブジェク ト）に対して 「編集」 「削除」 「共有」 といった操作（アクション）をする、という 考え⽅でUIデザインを整理します。 企業で⽇常的に使われるBtoB業務システムなど、ユーザーが「UIに慣れる」ことで より⾃由に効率的に使えるようになるプロダクトに向いたデザイン⼿法です。
- 127. オブジェクト指向UI 127 ユーザーが操作する対象である 「オブジェクト」 を中⼼にUIデザインを進める。 オブジェクト指向UIデザイン──使いやすいソフトウェアの原理, 上野 学, 2020 をもとに翻案 ユーザー 写真編集アプリ オブジェクト 写真 アクション 編集 削除 共有 操作する対象 写真 編集 削除 共有
- 129. モードレスとモーダル 129 モーダル 特定の操作が完了するまで 他の操作ができない状態 モードレス ユーザーが特定の操作中でも 他の操作を続けられる状態 オブジェクト指向UIデザイン──使いやすいソフトウェアの原理, 上野 学, 2020 をもとに翻案 商品A 商品B ホーム 商品 おすすめ 会計 送信する キャンセル メールを送信して よろしいですか︖
- 130. タスク指向UI 130 OOUIの対極として 「タスク指向UI」 があります。ユーザーが⾏いたい 「タスク」 に 焦点を当ててデザインを整理します。たとえばウィザードのように⼀連の⼿続きが決 まって流れていくUIだったり、ボタンのラベルが 「イタリア料理店を探したい」 「中華 料理店を探したい」 のように 「動作」 を⽰す⾔葉でつくります。 タスク指向UIは、そのプロダクトとユーザーが⼀期⼀会であったり、⽉に1回しか使 わないなど、ユーザーが操作に慣れることが永遠にないケースで有効に機能します。 タスク指向UIは流れが固定されるために、BtoB業務システムのような “毎⽇使う システム” では、慣れたユーザーにとってはまどろっこしくてしかたない、ということが起 こります。
- 132. 132 要件定義に したがって デザインをおこして 要件定義 • 新機能として 『確定申告』 を、税務の知識がない ユーザーでもかんたんにできるようにしたい︕ ⾃社プロダクト • クラウド会計システム 『かえんたけ』 • 個⼈事業主むけ
- 134. 事例: freee確定申告 134 引⽤: https://www.freee.co.jp/accounting/individual/ 「はい か いいえ を選んでください」 とは︖︖︖
- 135. 事例: freee確定申告 135 freee確定申告は完全に 「タスク指向UI」 としてつくられています。なぜ OOUI ではなく、タスク指向UI が採⽤されたのでしょう︖ 『確定申告』 は年に1回しかしない業務で、概念も⽇常⽣活に馴染みがないため に、ユーザーが何年経ってもなかなか慣れることがありません。そのため OOUI のよ うにユーザーの主体性に委ねると、ユーザーはゴール（申告完了）までたどりつくこ とができません。 『確定申告』 はユーザーにとってつねに⼀期⼀会の業務と理解したほうがよく、その ため タスク指向UI のほうがむいている業務となります。
- 137. 137 UIデザイナーに求められることは ユーザーの業務と業界知識を理解したうえで “業務フロー” そのものの再構築にふみこんで 新しい “業務フロー” を具現化する UIを組み⽴てることです ⼤事なことなので 2回⾔いました
- 139. なぜ⼊⼒させられているのかわからない⼊⼒項⽬ 139 このシステムに 実績⼊⼒するように ⼯程A、1.5h ⼯程B、1.0h ・・・ いやこのデータ⾒ても なにをアクションすれば いいのか・・・ 上⻑、なにも ⾔ってこないね ⼊⼒も⾯倒だし てきとうでいいんじゃない 現場の上⻑ 担当者 現場の上⻑ 担当者 はーい 実績管理などの⼊⼒項⽬は、恩恵がエンドユーザーにはわかりづらいことがある。ま た現場の上⻑も具体的な改善アクションを起こせることはまれ。エンドユーザーに とってただ⾯倒なだけの形骸化した作業になってしまったり、現場の上⻑にとっては 持て余すだけの情報になってしまいがち。
- 140. 形骸化したユーザー体験のサイクルになる理由 140 実績⼊⼒する 何も恩恵が感じられない 具体的なアクションが浮かばない 担当者 現場の上⻑ 担当者 実績⼊⼒する 実績⼊⼒の恩恵を実感する 具体的なアクションをする 担当者 現場の上⻑ 担当者 担当者 1. 担当者が、⾃分が⼊⼒したデータによる恩恵を合理的な期間内に実感でき ない。（数ヶ⽉後などではダメ） 2. 現場の上⻑は、現場から⼊⼒された情報があがってきても、具体的な 『アク ション』 が起こせない。そのため担当者への恩恵が⽣まれない。 形骸化した サイクル あるべき サイクル
- 141. ああああ ああああ あああ さらに悪化したパターン 141 もっとxxxの数字や xxxの数字も集計 しろ︕ どひゃー なんだこの⼊⼒欄の 数は・・・ それ、ぜんぶ 「あ」って⼊⼒すれば 送信できるよ どひゃー なんだ この「あああ」しか ない帳票は・・・ お︕ ナイス情報 現場の上⻑ 担当者 担当者 現場の上⻑ あ 表題 ⽇付 作業内容 年 ⽉ ⽇ カ レ ン ダ ー ⼯程名 ⼯程に要した時間 反省点 項⽬A 項⽬B 項⽬C 項⽬D 項⽬E 運⽤が形骸化したり、不必要に項⽬を増やしたりした結果、まともなデータが⼊⼒ されなくなることがあります。そうなると現場の上⻑が改善アクションを起こすこともま まならならくなり、システムがますます形骸化して、放置されるようになります。 カテゴリ ああああ ああああ あああ
- 142. 理想のユーザー体験 142 ⼭⽥くん、ひとりで 仕事抱え込んでいる だろ。⼿伝うぞ。 ちゃんと実績を ⼊⼒しよう 実績⼊⼒ すればいいことが あるもんね 担当者 担当者 神上司 現場の上⻑ • 担当者が、⾃分がデータ⼊⼒した恩恵を（合理的な期間内に）実感するこ とができる。 • 現場の上⻑は⼊⼒された情報をもとに、具体的な 『アクション』 を起こして、担 当者に恩恵を実感させられる。 このシステムに 実績⼊⼒するように ⼯程A、1.5h ⼯程B、1.0h ・・・ 現場の上⻑ 担当者 はーい
- 143. 実績⼊⼒する 何も恩恵が感じられない 具体的なアクションが浮かばない 担当者 現場の上⻑ 担当者 配慮すべきポイント 143 担当者が、データ⼊⼒し た恩恵を（合理的な期 間内に）実感することを 助ける 現場の上⻑が⼊⼒され た情報をもとに、具体的 な 『アクション』 を起こす ことを助ける ポイント1 ポイント2 ユーザー体験の阻害を解決するために配慮すべきポイントは以下です。
- 144. 144 インターフェースの⼆重接⾯性
- 146. あるウェブサイトのCMS 146 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 ページ数 カスタムフィールド数 20,000 ページ 200フィールド 新規記事の登録 タイトル サブタイトル 公開⽇ meta description 年 ⽉ ⽇ カレンダー プレビュー meta keywords og:title og:description 本⽂ ⼀覧ページのサムネイル画像 選択... og:image 選択... カテゴリ1 関係する商品 ▼ カテゴリ2 ▼ カテゴリ3 ▼ 商品A 商品B 商品C 商品D 商品E ⼀覧ページのテキスト ふつうにつくるとこうなる → コンテンツの 管理画⾯
- 147. CMSの難しさ＝マンマシン・インタフェース 147 「対象を直接に操作するのではなく、なにかを介して操作する」のは ⼈間の認知には根本的に難しい。“インターフェースの⼆重接⾯性” と呼ぶ。 認知しやすい 認知しづらい 直接に触れる／⾒たまま 何かを介する／⾒たのと異なる 物理的 デジタル的
- 149. これはまだわかる 149 ニュース記事 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー 本⽂ ドラフトを保存 送信して公開 下書きの破棄
- 150. ページ構造が複雑になった 150 ニュース記事 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー 本⽂ 画像 選択... ドラフトを保存 送信して公開 下書きの破棄
- 151. ページ構造が複雑になった 151 ニュース記事 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー 本⽂ 画像 選択... ドラフトを保存 送信して公開 下書きの破棄 ⼊⼒と出⼒の対応が分割された。 「本⽂」と「画像」って 別なの︖ あ、そう・・・
- 152. サイトの他の箇所に表⽰される 152 ニュースリリース⼀覧 （年別に全件表⽰） ニュース記事 ニュース記事 ニュース記事 ! ! ! 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー 本⽂ ⼀覧ページのサムネイル画像 選択... ⼀覧ページのテキスト 画像 選択... ドラフトを保存 送信して公開 下書きの破棄
- 153. サイトの他の箇所に表⽰される 153 ニュースリリース⼀覧 （年別に全件表⽰） ニュース記事 ニュース記事 ニュース記事 ! ! ! 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー 本⽂ ⼀覧ページのサムネイル画像 選択... ⼀覧ページのテキスト 画像 選択... ドラフトを保存 送信して公開 下書きの破棄 ふつうに⾒える範囲の外も更新されるようになった。 ⼊⼒と出⼒が 1︓n の関係になった。 他のページにも出るの︖ どこに影響するのか わからない・・・
- 154. カテゴリにより出たり出なかったりする要素 154 ! ! ! 学⻑あいさつ 交通アクセス 施設案内 ニュースリリース⼀覧 （年別に全件表⽰） ニュース記事 ニュース記事 ! ! ! 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー 本⽂ ⼀覧ページのサムネイル画像 選択... カテゴリ ▼ ⼀覧ページのテキスト 画像 選択... ドラフトを保存 送信して公開 下書きの破棄
- 155. カテゴリにより出たり出なかったりする要素 155 ! ! ! 学⻑あいさつ 交通アクセス 施設案内 ニュースリリース⼀覧 （年別に全件表⽰） ニュース記事 ニュース記事 ! ! ! 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー 本⽂ ⼀覧ページのサムネイル画像 選択... カテゴリ ▼ ⼀覧ページのテキスト 画像 選択... ドラフトを保存 送信して公開 下書きの破棄 どんなカテゴリがあるのか、 どの要素がカテゴリに影響されるのか、 サイト全体の構造理解が必要になった。 このカテゴリを選ぶと どのページのどこに 反映されるわけ︖
- 156. ⾃社サイトの外に表⽰される 156 ! ! ! 学⻑あいさつ 交通アクセス 施設案内 ニュースリリース⼀覧 （年別に全件表⽰） ニュース記事 ニュース記事 ! ! ! 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー og:title og:description 本⽂ ⼀覧ページのサムネイル画像 選択... og:image 選択... カテゴリ ▼ ⼀覧ページのテキスト 画像 選択... ドラフトを保存 送信して公開 下書きの破棄
- 157. ⾃社サイトの外に表⽰される 157 ! ! ! 学⻑あいさつ 交通アクセス 施設案内 ニュースリリース⼀覧 （年別に全件表⽰） ニュース記事 ニュース記事 ! ! ! 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー og:title og:description 本⽂ ⼀覧ページのサムネイル画像 選択... og:image 選択... カテゴリ ▼ ⼀覧ページのテキスト 画像 選択... ドラフトを保存 送信して公開 下書きの破棄 og:imageって何・・・︖ ⾃社サイトで⾒えている範囲だけでなく、 ウェブ全体のエコシステムの理解がいるようになった。
- 158. 他社サービスと連携する 158 ! ! ! 学⻑あいさつ 交通アクセス 施設案内 ニュースリリース⼀覧 （年別に全件表⽰） ニュース記事 ニュース記事 ! ! ! 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー og:title og:description 本⽂ ⼀覧ページのサムネイル画像 選択... og:image 選択... カテゴリ ▼ ⼀覧ページのテキスト 画像 選択... utmパラメータ ドラフトを保存 送信して公開 下書きの破棄
- 159. 他社サービスと連携する 159 ! ! ! 学⻑あいさつ 交通アクセス 施設案内 ニュースリリース⼀覧 （年別に全件表⽰） ニュース記事 ニュース記事 ! ! ! 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー og:title og:description 本⽂ ⼀覧ページのサムネイル画像 選択... og:image 選択... カテゴリ ▼ ⼀覧ページのテキスト 画像 選択... utmパラメータ ドラフトを保存 送信して公開 下書きの破棄 utmパラメータって何・・・︖ もうムリ・・・ 外部システムという、⽬に⾒えない部分の理解も必要になった。
- 161. 161 視認性
- 162. 視認性 162 BtoB業務システムは、⼊⼒項⽬が多くなりやすい。 「⾒づらい」 「パッと⾒て⼊⼒しなければならない量が多そうに感じる」 という視覚か らの負荷がある。 • 多くなるほど、それらが影響する範囲の複雑度が増す。 • 多くなるほど、可読性が悪くなる。 • 多くなるほど、ユーザーは息苦しさを感じる。
- 163. これはちゃんと⾒える 163 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー 本⽂ ドラフトを保存 送信して公開 下書きの破棄
- 164. こうなるとグレーの矩形に⾒えている 164 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー og:title og:description 本⽂ ⼀覧ページのサムネイル画像 選択... og:image 選択... カテゴリ ⼀覧ページのテキスト 画像 選択... utmパラメータ ドラフトを保存 送信して公開 下書きの破棄 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー og:title og:description 本⽂ ⼀覧ページのサムネイル画像 選択... og:image 選択... カテゴリ ⼀覧ページのテキスト 画像 選択... utmパラメータ ドラフトを保存 送信して公開 下書きの破棄 なんかボヤけた 四⾓形の「かたまり」が 並んでる・・・
- 165. じつはスクロールバーの⻑さも⾒ている 165 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー og:title og:description og:image 選択... 道⽞坂⼤学 ニュースリリース ニュース記事 学科・コース 学⽣⽣活 ⼊試情報 就職情報 ⼤学院 新規記事の登録 タイトル サブタイトル 公開⽇ 年 ⽉ ⽇ カレンダー プレビュー 本⽂ ドラフトを保存 送信して公開 下書きの破棄 スクロールバー短っ︕ ⼊⼒項⽬ めっちゃ多くね︕︖
- 167. 167 それでは困る
- 170. ユーザーの⼼理負荷を下げる 170 ユーザーを、タスクごとに複数のグループに分けて、それぞれに専⽤の管理画⾯をつ くる。⾃分に関係あるところだけ⾒えるようにする。 タイトル 本⽂ 画像 選択... ニュースリリース⽤ タイトル 本⽂ 商品情報⽤ 関係する商品 商品A 商品B 商品C 商品D 商品E 広報部 マーケティング部
- 171. 171 まとめ
- 174. まとめ 174 1. BtoB業務システムのUIデザインとは、画⾯のデザインではなく “業務フロー” のデザインそのもの。 2. UIデザイナーはユーザーの業務と業界知識を理解したうえで、 “業務フロー” そのものの再構築にふみこんで、新しい “業務フロー” を具現化するUIを組み ⽴てることが求められる。 3. UIはユーザーの “業務フロー” を定義する。だからこそ 「こうしたら今よりもっと 業務がうまくいく」 というUIをデザインする。 4. ユーザーを理解するには、現場に訪問すること。ユーザーにくりかえし 「なぜで すか」 と⾏動の⽬的を訊く。業務を観察する。
- 177. ⽻⼭のプレゼンのアレ が、 LINEスタンプになりました︕ スタンプ名︓ハーミィ（CSS編） 作者名︓⽻⼭ 祥樹 https://store.line.me/stickershop/product/1228201/ja Web・CSSネタ 全40種類