Download as PDF, PPTX
Uploaded byYoshiki Hayama
PDF, PPTX2,096 views
言われたままつくるんじゃない！ BtoB業務システムのUIを"ユーザー中心"にするリアルな現場のデザインプロセス - NOT DESIGN SCHOOL 2025年4月16日
2025年4月16日（水）NOT DESIGN SCHOOLさまの「言われたままつくらない！ BtoB業務システムのUIを"ユーザー中心"にするリアルな現場のデザインプロセス」のスライドです。UIデザイナーはどこまで要件定義にふみこめるのでしょうか。BtoB業務システムのUIデザインにおいて、クライアントや情報システム部門、プロダクトオーナーによる要件定義をうけとって「色つけ」するだけがUIデザイナーの役割になってしまう、という嘆きも耳にします。要件定義のままにデザインしたところ、ユーザーからは「業務に合っていない」「使いものにならない」と言われてしまう、というケースもいまだ散見されます。BtoB業務システムのUIデザインとは、画面のデザインではなく、"業務フロー"のデザインそのものです。UIデザイナーに求められることは、ユーザーの業務とドメイン知識（業界知識）を理解したうえで、"業務フロー"そのものの再構築にふみこんで提案し、新しい"業務フロー"の具現化としてのUIを組み立てていくことです。BtoB業務システムのUIデザイナーの"リアルな"実務で求められるデザインプロセスを学びます。
Recommended
![UXデザインのはじめの一歩を体験しよう！ ユーザーインタビューの基本 [第2版] | UXデザイン実践セミナー 第2回](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2f20221209-creekandriver-ux-workshop-2-221207181804-b44d3cb7-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More Related Content
What's hot
Similar to 言われたままつくるんじゃない！ BtoB業務システムのUIを"ユーザー中心"にするリアルな現場のデザインプロセス - NOT DESIGN SCHOOL 2025年4月16日
More from Yoshiki Hayama
言われたままつくるんじゃない！ BtoB業務システムのUIを"ユーザー中心"にするリアルな現場のデザインプロセス - NOT DESIGN SCHOOL 2025年4月16日
- 1.⾔われたままつくるんじゃない︕BtoB業務システムのUIを "ユーザー中⼼” にするリアルな現場のデザインプロセス12025年4⽉16⽇（⽔） NOT DESIGN SCHOOL代表取締役CEO / HCD-Net認定 ⼈間中⼼設計専⾨家⽻⼭ 祥樹 @storywriterハッシュタグは#NOTds⽻⼭パートは画⾯キャプチャ投稿OK︕配信のチャットでいっしょに盛りあがってね
- 2.
- 3.
- 4.
- 5.
- 6.⽻⼭ 祥樹 @storywriter6⽇本ウェブデザイン株式会社代表取締役CEO使いやすいプロダクトをつくる専⾨家HCD-Net認定 ⼈間中⼼設計専⾨家Web業界に25年、AIシステムのプロダクトマネージャーとUXデザインを7年主な実績など2009年 ⽇経パソコン 企業サイトランキング2009⽇本の主要企業696サイト中、ユーザビリティ／アクセシビリティ分野で第3位2011年 Webユーザビリティランキング2011 企業サイト編⽇本の⼤⼿企業150サイト中、第4位主な専⾨分野ユーザーエクスペリエンス、⼈間中⼼設計、情報アーキテクチャ、アクセシビリティ、ライター
- 7.
- 8.
- 9.
- 10.
- 11.11要件定義にしたがってデザインをおこして 要件定義• 『部品表』画⾯にボタンを追加したい。• ユーザーから 「新しい部品を追加するとき、いちいちマスタ登録画⾯に移動するのが⾯倒だ」 という要望が多くある。• そこで画⾯遷移なしにマスタ登録がしやすいよう、マスタ登録をモーダルで出せるようにする。⾃社プロダクト• クラウド⽣産管理システム 『まいたけ』• 個別受注⽣産の製造業むけ
- 12.12ワイヤーフレーム部品表検査装置本体製品名1数品番 図番 品名数 形式⼨法1 HO-25 M2056 フレーム 1 SU-1 402 AL-26 M2038 端⼦ボックス 1 120x153 C-556 A076 底板 1部品追加マスタ 部品表 ⼯程表受注 実績部品マスタ登録123-1製番部品表検査装置本体製品名1数品番 図番 品名 数 形式⼨法1 HO-25 M2056 フレーム 1 SU-1 402 AL-26 M2038 端⼦ボックス 1 120x153 C-556 A076 底板 1部品追加マスタ 部品表 ⼯程表受注 実績部品マスタ登録123-1製番部品マスタ登録品番図番品名購⼊品購⼊区分登録こんな感じ
- 13.13デザインするなら、どれがよいでしょうか案1. ⾔われたまま美しく 案2.重要なボタンなので強調 案3. 主動線をジャマしない部品表検査装置本体製品名1数部品追加マスタ 部品表 ⼯程表受注 実績部品マスタ登録123-1製番品番 図番 品名 数 形式⼨法1 HO-25 M2056 フレーム 1 SU-1 402 AL-26 M2038 端⼦ボックス 1 120x153 C-556 A076 底板 1部品表検査装置本体製品名1数部品追加マスタ 部品表 ⼯程表受注 実績部品マスタ登録123-1製番品番 図番 品名 数 形式⼨法1 HO-25 M2056 フレーム 1 SU-1 402 AL-26 M2038 端⼦ボックス 1 120x153 C-556 A076 底板 1部品表検査装置本体製品名1数部品追加マスタ 部品表 ⼯程表受注 実績部品マスタ登録123-1製番品番 図番 品名 数 形式⼨法1 HO-25 M2056 フレーム 1 SU-1 402 AL-26 M2038 端⼦ボックス 1 120x153 C-556 A076 底板 1
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.20要件定義• 『部品表』 画⾯にボタンを追加したい。•ユーザーから 「新しい部品を追加するとき、いちいちマスタ登録画⾯に移動するのが⾯倒だ」 という要望が多くある。• そこで画⾯遷移なしにマスタ登録がしやすいよう、マスタ登録をモーダルで出せるようにする。⾃社プロダクト• クラウド⽣産管理システム 『まいたけ』• 個別受注⽣産の製造業むけユーザーの本当のニーズは「部品をスムーズに登録したい」 ではなく 「部品をいちいちマスタ登録しないで部品表をつくりたい」マスタ登録が必須の仕様がそもそも適切でない。
- 21.部品表検査装置本体製品名1数部品追加マスタ 部品表 ⼯程表受注実績部品マスタ登録123-1製番部品表検査装置本体製品名1数部品追加マスタ 部品表 ⼯程表受注 実績部品マスタ登録123-1製番部品マスタ登録品番図番品名購⼊品購⼊区分登録21「そもそもマスタ必須の仕様をやめさせる」が正しいデザインです品番 図番 品名 数 形式⼨法1 HO-25 M2056 フレーム 1 SU-1 402 AL-26 M2038 端⼦ボックス 1 120x153 C-556 A076 底板 1
- 22.
- 23.
- 24.
- 25.
- 26.26次の線分は “ものさし” となる線分に⽐べて⻑いですか︖短いですか︖ものさし
- 27.
- 28.28次の⾊は “ものさし” となる⾊に⽐べて濃いですか︖薄いですか︖ものさし
- 29.部品表検査装置本体製品名1数部品追加マスタ 部品表 ⼯程表受注実績部品マスタ登録123-1製番部品表検査装置本体製品名1数部品追加マスタ 部品表 ⼯程表受注 実績部品マスタ登録123-1製番部品表検査装置本体製品名1数部品追加マスタ 部品表 ⼯程表受注 実績部品マスタ登録123-1製番29どのデザインが好ましいでしょうか︖プロダクトだけを⾒ていて、なぜわかるのですか︖品番 図番 品名 数 形式⼨法1 HO-25 M2056 フレーム 1 SU-1 402 AL-26 M2038 端⼦ボックス 1 120x153 C-556 A076 底板 1品番 図番 品名 数 形式⼨法1 HO-25 M2056 フレーム 1 SU-1 402 AL-26 M2038 端⼦ボックス 1 120x153 C-556 A076 底板 1品番 図番 品名 数 形式⼨法1 HO-25 M2056 フレーム 1 SU-1 402 AL-26 M2038 端⼦ボックス 1 120x153 C-556 A076 底板 1
- 30.
- 31.
- 32.
- 33.
- 34.34BtoB業務システムのUIデザインはしばしばクライアント、プロマネ注1、PO注2、PdM注3から要件定義をうけとって“⾊つけ” するだけがUIデザイナーの役割になってしまうという嘆きも⽿にします注1: プロマネ= プロジェクトマネージャー、PMとも 注2: PO = プロダクトオーナー 注3: PdM = プロダクトマネージャー
- 35.
- 36.
- 37.
- 38.38UIデザイナーに求められることはユーザーの業務と業界知識を理解したうえで“業務フロー” そのものの再構築にふみこんで新しい “業務フロー”を具現化するUIを組み⽴てることです
- 39.
- 40.
- 41.
- 42.
- 43.これまでのシステム開発の根本的な問題点43要件定義でユーザーが 「ほしいもの」 を訊いていませんか︖ユーザーが「ほしい」 と⾔ったものユーザーをしあわせにするもの
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.現場の “エンドユーザー” に話を聞いて、観察する68現場の“エンドユーザー” に話を聞いて、そして観察するようにしましょう。現場にくりかえし「なぜですか」 と⾏動の⽬的を訊く。そして業務を観察することで、正しくニーズを特定できます。
- 69.エンドユーザーの「⾏動」を調べよう69現場の 「代表者」 にヒアリングするのではなく、エンドユーザーの「当事者」 を調べよう。「代表者」 の意⾒は 「推測」 が混ざる。
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93.
- 94.要件定義のミーティングで落としどころを探すとき94要件定義のミーティングで、お客様と落としどころを探すときも「ゴムのユーザー」 になりやすいシーンです。「きっと」 や「たぶん」 を積み重ねて要件を定めてはいませんか。ユーザーはきっとこう使うたぶんこんなニーズもあるなかなか議論が収束しないな・・・。
- 95.
- 96.
- 97.
- 98.
- 99.
- 100.
- 101.
- 102.
- 103.
- 104.
- 105.
- 106.
- 107.
- 108.
- 109.
- 110.
- 111.
- 112.
- 113.
- 114.114UIをデザインするためにはまず “業務” がどうなされているのか知って“業務”をどう改善するかをデザインします
- 115.
- 116.
- 117.
- 118.
- 119.
- 120.
- 121.
- 122.
- 123.
- 124.
- 125.
- 126.オブジェクト指向UI126UIデザイン⼿法としてよく参照されるのが 「オブジェクト指向UI（OOUI）」です。オブジェクトとは、ユーザーが操作する対象の 「もの」のことです。たとえば、写真編集アプリを使うとき、写真⾃体が 「オブジェクト」 になります。その写真（オブジェクト）に対して 「編集」 「削除」 「共有」 といった操作（アクション）をする、という考え⽅でUIデザインを整理します。企業で⽇常的に使われるBtoB業務システムなど、ユーザーが「UIに慣れる」ことでより⾃由に効率的に使えるようになるプロダクトに向いたデザイン⼿法です。
- 127.オブジェクト指向UI127ユーザーが操作する対象である 「オブジェクト」 を中⼼にUIデザインを進める。オブジェクト指向UIデザイン──使いやすいソフトウェアの原理,上野 学, 2020 をもとに翻案ユーザー写真編集アプリ オブジェクト写真アクション編集削除共有操作する対象写真編集削除共有
- 128.
- 129.モードレスとモーダル129モーダル特定の操作が完了するまで他の操作ができない状態モードレスユーザーが特定の操作中でも他の操作を続けられる状態オブジェクト指向UIデザイン──使いやすいソフトウェアの原理, 上野 学,2020 をもとに翻案商品A 商品Bホーム 商品 おすすめ 会計送信するキャンセルメールを送信してよろしいですか︖
- 130.タスク指向UI130OOUIの対極として 「タスク指向UI」 があります。ユーザーが⾏いたい「タスク」 に焦点を当ててデザインを整理します。たとえばウィザードのように⼀連の⼿続きが決まって流れていくUIだったり、ボタンのラベルが 「イタリア料理店を探したい」 「中華料理店を探したい」 のように 「動作」 を⽰す⾔葉でつくります。タスク指向UIは、そのプロダクトとユーザーが⼀期⼀会であったり、⽉に1回しか使わないなど、ユーザーが操作に慣れることが永遠にないケースで有効に機能します。タスク指向UIは流れが固定されるために、BtoB業務システムのような “毎⽇使うシステム” では、慣れたユーザーにとってはまどろっこしくてしかたない、ということが起こります。
- 131.
- 132.132要件定義にしたがってデザインをおこして 要件定義• 新機能として『確定申告』 を、税務の知識がないユーザーでもかんたんにできるようにしたい︕⾃社プロダクト• クラウド会計システム 『かえんたけ』• 個⼈事業主むけ
- 133.
- 134.事例: freee確定申告134引⽤: https://www.freee.co.jp/accounting/individual/「はいか いいえを選んでください」とは︖︖︖
- 135.事例: freee確定申告135freee確定申告は完全に 「タスク指向UI」としてつくられています。なぜ OOUIではなく、タスク指向UI が採⽤されたのでしょう︖『確定申告』 は年に1回しかしない業務で、概念も⽇常⽣活に馴染みがないために、ユーザーが何年経ってもなかなか慣れることがありません。そのため OOUI のようにユーザーの主体性に委ねると、ユーザーはゴール（申告完了）までたどりつくことができません。『確定申告』 はユーザーにとってつねに⼀期⼀会の業務と理解したほうがよく、そのため タスク指向UI のほうがむいている業務となります。
- 136.
- 137.137UIデザイナーに求められることはユーザーの業務と業界知識を理解したうえで“業務フロー” そのものの再構築にふみこんで新しい “業務フロー”を具現化するUIを組み⽴てることです⼤事なことなので2回⾔いました
- 138.
- 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.
- 145.
- 146.あるウェブサイトのCMS146道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院ページ数カスタムフィールド数20,000 ページ200フィールド新規記事の登録タイトルサブタイトル公開⽇meta description年⽉ ⽇ カレンダープレビューmeta keywordsog:titleog:description本⽂⼀覧ページのサムネイル画像選択...og:image選択...カテゴリ1関係する商品▼カテゴリ2▼カテゴリ3▼商品A 商品B 商品C商品D 商品E⼀覧ページのテキストふつうにつくるとこうなる →コンテンツの管理画⾯
- 147.
- 148.
- 149.これはまだわかる149ニュース記事道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビュー本⽂ドラフトを保存送信して公開 下書きの破棄
- 150.ページ構造が複雑になった150ニュース記事道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビュー本⽂画像選択...ドラフトを保存送信して公開 下書きの破棄
- 151.ページ構造が複雑になった151ニュース記事道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビュー本⽂画像選択...ドラフトを保存送信して公開 下書きの破棄⼊⼒と出⼒の対応が分割された。「本⽂」と「画像」って別なの︖あ、そう・・・
- 152.サイトの他の箇所に表⽰される152ニュースリリース⼀覧（年別に全件表⽰）ニュース記事ニュース記事ニュース記事!!!道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビュー本⽂⼀覧ページのサムネイル画像選択...⼀覧ページのテキスト画像選択...ドラフトを保存送信して公開 下書きの破棄
- 153.サイトの他の箇所に表⽰される153ニュースリリース⼀覧（年別に全件表⽰）ニュース記事ニュース記事ニュース記事!!!道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビュー本⽂⼀覧ページのサムネイル画像選択...⼀覧ページのテキスト画像選択...ドラフトを保存送信して公開 下書きの破棄ふつうに⾒える範囲の外も更新されるようになった。⼊⼒と出⼒が 1︓n の関係になった。他のページにも出るの︖どこに影響するのかわからない・・・
- 154.カテゴリにより出たり出なかったりする要素154!!!学⻑あいさつ交通アクセス施設案内ニュースリリース⼀覧（年別に全件表⽰）ニュース記事ニュース記事!!!道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビュー本⽂⼀覧ページのサムネイル画像選択...カテゴリ▼⼀覧ページのテキスト画像選択...ドラフトを保存送信して公開 下書きの破棄
- 155.カテゴリにより出たり出なかったりする要素155!!!学⻑あいさつ交通アクセス施設案内ニュースリリース⼀覧（年別に全件表⽰）ニュース記事ニュース記事!!!道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビュー本⽂⼀覧ページのサムネイル画像選択...カテゴリ▼⼀覧ページのテキスト画像選択...ドラフトを保存送信して公開 下書きの破棄どんなカテゴリがあるのか、どの要素がカテゴリに影響されるのか、サイト全体の構造理解が必要になった。このカテゴリを選ぶとどのページのどこに反映されるわけ︖
- 156.⾃社サイトの外に表⽰される156!!!学⻑あいさつ交通アクセス施設案内ニュースリリース⼀覧（年別に全件表⽰）ニュース記事ニュース記事!!!道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビューog:titleog:description本⽂⼀覧ページのサムネイル画像選択...og:image選択...カテゴリ▼⼀覧ページのテキスト画像選択...ドラフトを保存送信して公開 下書きの破棄
- 157.⾃社サイトの外に表⽰される157!!!学⻑あいさつ交通アクセス施設案内ニュースリリース⼀覧（年別に全件表⽰）ニュース記事ニュース記事!!!道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビューog:titleog:description本⽂⼀覧ページのサムネイル画像選択...og:image選択...カテゴリ▼⼀覧ページのテキスト画像選択...ドラフトを保存送信して公開 下書きの破棄og:imageって何・・・︖⾃社サイトで⾒えている範囲だけでなく、ウェブ全体のエコシステムの理解がいるようになった。
- 158.他社サービスと連携する158!!!学⻑あいさつ交通アクセス施設案内ニュースリリース⼀覧（年別に全件表⽰）ニュース記事ニュース記事!!!道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビューog:titleog:description本⽂⼀覧ページのサムネイル画像選択...og:image選択...カテゴリ▼⼀覧ページのテキスト画像選択...utmパラメータドラフトを保存送信して公開 下書きの破棄
- 159.他社サービスと連携する159!!!学⻑あいさつ交通アクセス施設案内ニュースリリース⼀覧（年別に全件表⽰）ニュース記事ニュース記事!!!道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビューog:titleog:description本⽂⼀覧ページのサムネイル画像選択...og:image選択...カテゴリ▼⼀覧ページのテキスト画像選択...utmパラメータドラフトを保存送信して公開 下書きの破棄utmパラメータって何・・・︖もうムリ・・・外部システムという、⽬に⾒えない部分の理解も必要になった。
- 160.
- 161.
- 162.視認性162BtoB業務システムは、⼊⼒項⽬が多くなりやすい。「⾒づらい」 「パッと⾒て⼊⼒しなければならない量が多そうに感じる」 という視覚からの負荷がある。•多くなるほど、それらが影響する範囲の複雑度が増す。• 多くなるほど、可読性が悪くなる。• 多くなるほど、ユーザーは息苦しさを感じる。
- 163.これはちゃんと⾒える163道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビュー本⽂ドラフトを保存送信して公開 下書きの破棄
- 164.こうなるとグレーの矩形に⾒えている164道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビューog:titleog:description本⽂⼀覧ページのサムネイル画像選択...og:image選択...カテゴリ⼀覧ページのテキスト画像選択...utmパラメータドラフトを保存送信して公開 下書きの破棄道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇ カレンダープレビューog:titleog:description本⽂⼀覧ページのサムネイル画像選択...og:image選択...カテゴリ⼀覧ページのテキスト画像選択...utmパラメータドラフトを保存送信して公開 下書きの破棄なんかボヤけた四⾓形の「かたまり」が並んでる・・・
- 165.じつはスクロールバーの⻑さも⾒ている165道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇カレンダープレビューog:titleog:descriptionog:image選択...道⽞坂⼤学ニュースリリースニュース記事学科・コース学⽣⽣活⼊試情報就職情報⼤学院新規記事の登録タイトルサブタイトル公開⽇年 ⽉ ⽇ カレンダープレビュー本⽂ドラフトを保存送信して公開 下書きの破棄スクロールバー短っ︕⼊⼒項⽬めっちゃ多くね︕︖
- 166.
- 167.
- 168.
- 169.
- 170.
- 171.
- 172.
- 173.
- 174.まとめ1741. BtoB業務システムのUIデザインとは、画⾯のデザインではなく “業務フロー”のデザインそのもの。2.UIデザイナーはユーザーの業務と業界知識を理解したうえで、 “業務フロー”そのものの再構築にふみこんで、新しい “業務フロー” を具現化するUIを組み⽴てることが求められる。3. UIはユーザーの “業務フロー” を定義する。だからこそ 「こうしたら今よりもっと業務がうまくいく」 というUIをデザインする。4. ユーザーを理解するには、現場に訪問すること。ユーザーにくりかえし 「なぜですか」 と⾏動の⽬的を訊く。業務を観察する。
- 175.
- 176.
- 177.⽻⼭のプレゼンのアレ が、LINEスタンプになりました︕スタンプ名︓ハーミィ（CSS編） 作者名︓⽻⼭祥樹https://store.line.me/stickershop/product/1228201/jaWeb・CSSネタ全40種類