ITにおけるデザイン活用の課題と対応策ーデザインシステムでできること

Roy Kim
ITにおけるデザイン活⽤の課題と対応策
デザインシステムでできる事
Session 01

Fixel Inc. All rights reserved.
プロフィール
l FixelのUXデザイナー兼代表取締役
l デロイト、アビーム、BEA、オラクル、EMCなどでITコンサルタントとアーキ
テクトを経験
l B2B、B2EシステムのUX/UIデザインを⾏う
l 趣味でMac/iOSのアプリ開発
2
金成哲
Roy Kim

UXの改善で
新規契約数を増やす︕
ヒューマンテクノロジーズ
Case 01
4

アウトライン
お客様
• ヒューマンテクノロジーズ
企業向けクラウド勤怠管理サービス「KING OF TIME」を提供。
国内トップシェアで歴史があるサービス。
依頼内容
• 競合サービスに勝てるUXに変え、新規利⽤企業を増やしたい。
背景
① 競合サービスが増え、無償トライアル期間で⽐較されると採択さ
れにくくなっている。
② 多機能なため始めて使う際の分かりやすさ、操作性などUX⾯での
改善を必要と考えていた。
5

実施内容
プロセス・期間
6
［フェーズ 0］
パートナー選定
UI改善プロジェクト
UX改善プロジェクト
約2カ⽉約9カ⽉約3カ⽉
1stリリース 2ndリリース

実施内容
7
① 提案コンペ（6社） UX改善のための計画と改善案の提案コンペ
② トライアル
プロジェクト（3社）
既存サービスの改善を短期ワークショップ形式で⾏
い、プロトタイピングと簡易ユーザーテストまで実
施。その後の改善の⽅針と計画を提案しパートナー
に選定された。
実施内容

実施内容
8
① 現状分析画⾯遷移・レイアウトやUI要素の分析、競合⽐較
② UI改善案検討分析を踏まえUI部品/画⾯レイアウトなどを検討
③ 評価検証機能⾯、実装⾯などから検証と調整
④ 実装時の技術サポート新UIの実装⽅法に関する技術⽀援
⑤ リリース後評価リリース後の評価、次フェーズ計画
実施内容

実施内容
元の画⾯
9

実施内容
フェーズ1の成果物など
• サービスのメタファー（イ
10
UI改善後の画⾯・ビジュアルデザイン

実施内容
11
① 既存ユーザーへの調査インタビュー調査、課題の抽出
② UX改善案検討
UX/UI改善⽅針、ワイヤーフレーム検討、
ビジュアルデザイン調整、プロトタイピング
③ 評価検証ユーザーテストを⾏い評価と改善
④ 実装時の技術サポート新UIの実装⽅法に関する技術⽀援
実施内容
2ndリリース

実施内容
12
ナビゲーションの改善
テーブル表⽰の改善配⾊の改善その他・各画⾯の改善

UXデザインの効果
13
ビジネスの課題を意識したUXデザインは有効
ゴールが明確であれば、戦略も⽴てやすい
しかし、既存ユーザーからは慣れていたUIが変わることに
対する反対の声があった
Step by Stepのアプローチが必要
Done Is Better Than Perfect!
v 新規契約獲得数が70%アップ︕ ※前年⽐

デザインだけの改善で
海外案件獲得
⽇本発グローバル企業の情シス
Case 02
14

アウトライン
お客様
• 世界に散在する400社の系列社を持つ⽇本企業
• ⽇本をベースに多国・多⽂化圏に業務⽤システムを提供する情シス部
⾨
依頼内容
• ２週間の短期間で既存ワークフローシステムのデザイン改善
背景
① 既存ワークフローシステムをアメリカの関連会社に提案したけど、
使い勝⼿の悪さや分かりにくさを理由に断られる
② ４週間後に再度提案のチャンスがあるので、そこまでできる改善を急
いで実施したい ⇒ デザインに使えるのは２週間︕
15

実施内容
実施内容
• 短期間で既存システムをUXデザイナーに説明し、習得させる
• 営業、プロダクトオーナー、エンジニア、UXデザイナーがブレインス
トーミングに参加。その結果を受けてUIデザイナーがビジュアルデザ
イン作成
• PC版からスマホ版に順に対応
16
実装
1週⽬（PC版） 2週⽬（スマホ版）
既存システム理解
（3時間）
UIデザイン作成
（3⽇）
ブレインストーミング
（4時間）
既存システム理解
（1時間）
UIデザイン作成
（2⽇）
ブレインストーミング
（3時間）

実施内容
元の画⾯
17

実施内容
ブレインストーミング資料
18

実施内容
改善後の画⾯デザイン
19

実施内容
Before / After
20

UXデザインの効果
21
デザインスプリントの⼿法を変更して適⽤し、
「短納期＆サーバー側は変更不可」という制約の下でも
⼤幅なデザイン改善ができた
結果的にアメリカの案件が取れた
社内で「なぜそれができたか︖」をレポートすることになり、
UXデザインへの興味が⾼まった
デザインの評判がよく、製品全体に同デザインを適⽤するこ
とになった

なぜ今、デザインなのか︖

なぜ今UXデザイン︖
23
新しい
他にない
多機能
⾼機能
⾼級感/信頼性
↕
安い
付加価値
⼯業商品のライフサイクル

なぜ今UXデザイン︖
24
新しい
他にない
多機能
⾼機能
⾼級感/信頼性
↕
安い
付加価値
⼯業商品のライフサイクル
• 多くの商品がこの段階まで進んでいる
• 付加価値の提供のため、視点が商品から
⼈に移る
AI/IoT Cloud
Computing
SNS, Game,
その他のサービス
ERP等パッケージ
App

UXデザイン︓Why?
l ⽕付け役
• アップルのiPhone
• Mac
25
(私が考える)
⽕付け役の⼈と製品

商品の価値基準が変わった
26
商品スペック使⽤者経験＜

新しい価値提供⼿段としてのUXデザイン
27
「UXデザインがビジネスの
成敗の（重要な）要因」

「UXの要件」を意識しよう
l 機能・⾮機能要件だけでは対
応できない課題がある
l システムの要件定義の際から
UXの要件を意識して定義する
ようにする
28
UXの要件
機能要件
⾮機能要件
システム・サービスの要件

UXデザインの業務システムへの期待効果
ü 作業員の負荷を下げる
ü 業務ミスを防ぐ
ü 作業効率を上げる
ü セキュリティーのリスクを下げる
ü 対顧客サービスの質が向上する
ü 企業のコストを低減する
ü システム実装・改修費⽤を下げる
29

業務系のシステムこそ、最初の効果が出やすい︕
30
品質
時間
初回UXデザインプロジェクト
の効果が最も⼤きい
フェーズ#1 フェーズ#2
User eXperience

デザイン導⼊の課題と
今までの（Fixelの）対応策

⼤⼿SIer、⼤企業のIT部⾨の現状
32
2011年 2018年
既存製品のデザイン
を改善してほしい
新規サービスを
⼀緒に考えてほしい
⾃社にUXデザインの⼈材を育て
たい・部署を作りたい
UXデザインの部署もできたけど、ど
うやって広げればいいか︖
今ここ︕

ITにおけるデザイン導⼊の⽅法
l 外部のデザイナー・デザイン会社に作業を依頼する
• 既存ITプロセスのどの段階でデザインを依頼するか︖
• どのような成果物か期待できるか︖
• 該当プロジェクトにおいてデザインはどれくらいの価値があるか︖
ü どこまで投資すべきか︖
ü 価値をどうやって測るか︖
l ⾃社内にデザインチームを新設する
• チームメンバーをどう構成するか︖どう育てるか︖
• デザインチームとITチームとのコラボレーションはどうするか︖
• どうやって組織にデザインを浸透させるか︖
• デザインチームの価値をどうやって⾒せるか︖
33

デザイン導⼊に対して今までやって来たこと
1. デザインに求める価値とその測定⽅法を明確にする
2. デザインを意識した新しいITプロセスを定義して実践する
3. デザインの成果物をITに合わせて再定義する
4. エンジニアにUXデザインの知識を教える
34

1. デザインに求める価値とその測定⽅法の定義
l 各プロジェクトでUXデザインに求めるものを明確にする
• 考慮すべきUXの特徴
• 達成すべきUXのレベル
l KGI/KLI明確に定義し、それのビジネス価値を計算してデザイ
ンへの投資額を決める ⇒ ROIの算出
35
UX Honey Comb
対象システムの特徴
を考慮して定義する
多くの業務システム
が求めるレベル

例︓先ほどの事例を振り返ると、
l Case 1
• フェーズ１
ü KGIは新規契約数
ü R: 新規契約１件の平均予想利益 x 契約増加数
ü I︓UXデザインとフロント実装に投資した⾦額
• フェーズ２
ü KGIは既存顧客アンケートにおける満⾜度
ü R: 既存契約者の継続によって予想される利益
ü I︓UXデザインとフロント実装に投資した⾦額
l Case 2
• KGI: 案件獲得
• R: 新規案件獲得時の利益
• I︓UXデザインとフロント実装に投資した⾦額
36

反復
2. デザインがマージされたプロセスの定義
37
コンテキスト分析
ジャーニーマップ
作成
メンタルモデル
分析
プロトタイプ作成ユーザーテスト
評価と改善
ゴールと範囲の
設定
分析フェーズ実証フェーズ
l プロジェクトのゴール・要件に応じて上記のプロセスを適切に調整
評価基準の検討
計画フェーズ
ペルソナ定義
UXデザインの⼀般的プロセス

UXデザイン × ウォータフォールプロセス
l ITプロセスの「要件定義」及び「基本設計」フェーズの⼀部を
UXデザインのタスクでリプレースできる
38
要件定義基本設計詳細設計実装テスト
コンテキスト分析
ジャーニーマップ
作成
メンタルモデル
分析
プロトタイプ作成ユーザーテスト
評価と改善
ゴールと範囲の
設定
評価基準の検討
計画フェーズ
ペルソナ定義

UXデザイン × アジャイルプロセス
l タスクの⼀部としてデザインを受け⼊れ、常に次のイテレーション向けのデ
ザインを⾏う
l 各リリースにユーザーテストができるコードを追加し、常いユーザーテスト
ができている状態にする
l 各イテレーションから得られた情報に基づき、次回のデザイン作業に反映し
つつ、既存機能の改善を⾏う
39
デザイン
実装
デザイン
基盤作成実装
デザイン
イテレーションイテレーションイテレーション
リリースリリース
テ
ス
ト
テ
ス
ト
デ
ザ
イ
ン
デ
ザ
イ
ン
コンテキスト
分析
ジャーニー
マップ
作成
メンタルモデ
ル
分析
プロトタイプ
作成
ユーザーテス
ト
評価と改善
ゴールと範
囲の設定
評価基準の
検討
計画フェーズ
ペルソナ定義
プラニングフェーズ
実装フェーズ

l ITが必要とする資料とUXデザインの成果物の精度は異なる
• ⽬的が異なるので、当たり前
l UXデザインの成果物から情報の損失なくITに必要なインプッ
トとするのは難しい
l プロジェクト単位（企業単位）でデザインとITの接点としての
⽂書の体系と内容の調整が必要
40
IT
Project
UXD
⽤語と成果物を合わせる

l ITが必要とする資料とUXデザインの成果物の精度は異なる
• ⽬的が異なるので、当たり前
l UXデザインの成果物から情報の損失なくITに必要なインプッ
トとするのは難しい
l プロジェクト単位（企業単位）でデザインとITの接点としての
⽂書の体系と内容の調整が必要
41
IT
Project
UXD
⽤語と成果物を合わせる
それでも⽋落する情報があるので、
UXデザインのプロセスにエンジニ
ア側のリーダーを参加させ、デザイ
ンにおけるコンテキスト共有を⾏う

4. エンジニアにUXデザインの知識を教える
l UXデザインは論理的な思考と⼈に
対する理解があれば誰でもできる
• 美的センスが必要な部分はごく⼀部で、それ
は専⾨家（ビジュアルデザイナー）に任せれ
ばいい
• ユーザーに対する理解・配慮がもっと⼤事
l UIデザインの裏のロジックも
学習できる
• 作る必要はない。評価できればいい
• 参考︓http://www.slideshare.net/ksc1213/ui-45852142
l 最初はUXデザイナーと⼀緒に経験を
積み、⾃⽴して⾏くように誘導する
42
論理的思考が必要な部分
美的センスやツールのスキルが必要な部分

先述した対応策に対する振り返り
l 個別プロジェクトにおける効果は確認済み
• 全社に広げるのは結構⼤変
l プロセスを変えることには努⼒と費⽤が必要
• ベストプラクティスがまだ不⾜している
l 専⾨家のサポートが必要
l デザインの学習には時間とコストがかかる
43

先述した対応策に対する振り返り
l 個別プロジェクトにおける効果は確認済み
• 全社に広げるのは結構⼤変
l プロセスを変えることには努⼒と費⽤が必要
• ベストプラクティスがまだ不⾜している
l 専⾨家のサポートが必要
l デザインの学習には時間とコストがかかる
44
効果はあるものの、それなりに⼤変︕

時間の経過に伴うデザイン品質の劣化
l 商品のライフサイクルとデザイン品質の変化
46
品質
時間
初回リリース
２回⽬リリース
３回⽬リリース

時間の経過に伴うデザイン品質の劣化
l 商品のライフサイクルとデザイン品質の変化
47
品質
時間
初回リリース
２回⽬リリース
３回⽬リリース
その場あたりの
改修・機能追加
初回デザインとは異なるデザイン
ポリシーによってデザインされる
もう最初のデザインの思想
なんて誰も知らない
その場あたりの
改修・機能追加
カオス︕

組織の壁によるデザイン品質の差
l システム単位でデザインの品質がバラバラ
48
品質
システムA システムB システムC システムD

ブランド構築に失敗
l サービス単位に異なるテイストのデザイン
49
品質
サービスA サービスB サービスC サービスD

ブランド構築に失敗
l サービス単位に異なるテイストのデザイン
50
品質
サービスA サービスB サービスC サービスD
UX品質の低下
ブランド構築失敗

デザイン導⼊後の課題
l 作ったデザインの品質をどうやって保つか︖
• ⼀つの製品の時間の経過によるデザインの⼀貫性を維持
• 複数のシステム・サービス間のデザインの⼀貫性を維持
l 「デザインを作る」だけではなく、「共有する」、「管理す
る」、「再利⽤する」ことへの考慮が必要
l デザインの深い知識がないエンジニアがデザインの品質を維持
しながら効率よく実装する⼿法が必要
51

こうはなれないか︖
l 企業からの理想は、デザインも商品扱いできればベストではな
いか︖
53
「今度作る新サービスに新しいデザインが必要ですね」
「あ、そう︖今あるものではダメなん︖」
「今のデザインの在庫ではちょっと、要件に合っているのがないです」
「じゃあ、１個買って」
「分かりました。今週中に買って適⽤します。」
「管理台帳にも記録して、他に必要な⼈達に共有してね」

こうはなれないか︖
l 企業からの理想は、デザインも商品扱いできればベストではな
いか︖
54
「今度作る新サービスに新しいデザインが必要ですね」
「あ、そう︖今あるものではダメなん︖」
「今のデザインの在庫ではちょっと、要件に合っているのがないです」
「じゃあ、１個買って」
「分かりました。今週中に買って適⽤します。」
「管理台帳にも記録して、必要な⼈達に共有してね」
なぜこうならないか︖

なぜデザインは難しいか︖
l デザインはまだまだ抽象度が⾼い
l ｢創造性の世界」との認識が強く属⼈性が⾼い
• プロセスや根底にある思いが明⽂化されることが少ない
• 共有できない。つまり、引き継げない、再現できない
l ITとのコラボ期間がまだ短い
55
アート＞デザイン＞コード＞商品

歴史は繰り返す
ITも⼀時期は芸術の領域に近かった
• 「コードは芸術か否か︖」と旺盛に議論していた時代もあった
ITは規模が⼤きくなりながら建築から多くのことを学んだ
• ウォーターフォルプロセス
• アーキテクチャー、モジュール、コンポーネントの再利⽤等、多くの概念・⽤
語を建築から学んで理論武装できた
• 個⼈のコードからみんなのコードへと、認識が変わって来た
デザインは今ITから「猛烈に」学んでいる
• シリコンバレーではITとデザインの⼤融合が発⽣中
ü デザインもコーディングもできる⼈の急増
• デザインがITに似て来ている
• デザインがより具体的でかつ管理可能なものに変わりつつある
56

なぜデザインは難しいか︖
l デザインはまだまだ抽象度が⾼い ➡ 具体化する
l ｢創造性の世界」との認識が強く属⼈性が⾼い
• プロセスや根底にある思いが明⽂化されることが少ない ➡ 明⽂
化する
• 共有できない。つまり、引き継げない、再現できない ➡ 仕組み
を作る
l ITとのコラボ期間がまだ短い ➡ 必要なツールを揃える
57
アート＞デザイン＞コード＞商品
［今起きていること］
デザインの抽象度を
落とし⾒える化する︕

例︓“Atomic Design” という⼿法の登場
UIデザインをページ単位ではなく
「コンポーネント単位」でとらえデザインする手法
58
UI要素を「原⼦・分⼦・有機体…」と
いった物理世界を構成する仕組みにな
らって構造化・部品化している。
それらを階層的に組み合わせることで、
⼤きなコンポーネントやページを作成
する考え⽅。
※Brad Frost⽒が提唱している考え⽅

Atomic Designの詳細
l ①原⼦ ②分⼦ ③有機体 ④テンプレート ⑤ページの5段階で構成。
l 原⼦ ︓ 最も抽象度が高いUI部品。様々な画⾯で再利用される。
l [原⼦ ➡ 分⼦ ➡ 有機体] の順でより具体的なUIコンポーネントになる。
l テンプレート ︓ 複数画⾯へ展開するためのページレイアウトの枠組
み。
l ページ ︓ 具体的な内容（テキストや画像、アイコンなど）が⼊った個別画⾯。
59

Atomic Designを使ったデザイン
ü Atomic Designの構造にならい、シンボルを⼊れ⼦構造で作る。
ü デザインの構造に合わせて、コンポーネントも実装する。
60
Atomic
Design
Sketch
の区分
対象要素サンプル
- Lv0
部品に紐づく属性など
※Sketchでの作業上定義する
原子
Atoms
Lv1
これ以上分解できない
最⼩単位の部品
分子
Molecules
Lv2
原⼦を組み合わせて作る
様々な画⾯やコンテキストで利⽤
できる汎⽤性のある部品
有機体
Organisms
Lv3
複数の原⼦・分⼦で構成
⽐較的複雑な部品

Atomic Designを⽤いるメリット
ü Atomic Designの分割⽅法でUIコンポーネントを設計することで、デザイン
上の構造と、コード上の構造を共通化できる。それにより効率的にデザイン
システム化ができる。
ü 最⼩単位のコンポーネントが独⽴しているため、部分的な修正がどう全体に
影響するかわかりやすく、全体の品質を崩さずデザインの改変が可能になる。
61

関連書籍の出版
62

ITとデザインのエコー環境⽐較
区分 IT デザイン
制作ツール IDE、各種エディタ Ps、Ai、Sketchなど
統合ツール各種UT、CIツールで⾃動化
履歴管理ツール Github、Subversionなど
共有ツール Github、Subversionなど Adobe Cloud︖
プロセス • ウォーターフォール、ア
ジャイル等。
• 実績・情報多数
• UXデザインとUIデザイン
を網羅したプロセスの不在
• 情報不⾜
関連情報⽂書体系、管理体制が整って
いる。資産管理ツールがある
共有⽂化 OSS Dribble︖（作品の公開であり、知識
の共有ではない）
63
l デザインには組織として活⽤されるためのツールが揃えていない
• 個⼈の作業を中⼼に捉えたツールが揃えてある状態

ジャイル等。
• 情報不⾜
64
これらのツールなしで、
ITのプロジェクトは管理で
きますか︖
ITのプロジェクトは管理で
きますか︖

ジャイル等。
• 情報不⾜
65
デザインのプロジェクトは
管理できますか︖
デザインのプロジェクトは
管理できますか︖

統合ツール各種UT、CIツールで⾃動化 ︖
履歴管理ツール Github、Subversionなど ︖
ジャイル等。
• 情報不⾜
︖
66
これらのツールがあると、少なくとも
コードと同じくらいの抽象度でデザイ
ンを管理することができる
これらのツールがあると、少なくとも
コードと同じくらいの抽象度で、
デザインを管理することができる

デザインシステムの紹介

デザインシステムとは
68
デザインシステムの構成
デザインガイドライン
＋
デザインポリシー
＋
UIコンポーネント
（パターンライブラリー）
＋
各種リソース
デザインシステムの価値
• デザインの⽅針とその背景などの情報が共有で
きるので、関係者全員がデザインに対して共通
の認識を持つことができる
• デザインの実装に必要な情報が網羅されている
• 複数のデザイナーが⼀貫性のあるデザインを効
率よく作成できる
• エンジニアの開発⽣産性と実装の品質が上がる
• デザイン資産を具体化して管理できるものにす
る

Salesforceのデザインシステム
l 3rd party サービスプロバイダー向
けのデザインガイドラインを公開
していたが、あまり効果がなかっ
たのでデザインシステムの提供に
⽅針転換
l Web、iOS、Android向けのデザイ
ンシステムを提供
l 実装技術に依存しない、UIコン
ポーネントを提供
l Localization、markupやスタイル
ガイドラインまで提供
69
Salesforce
Lightning Design System
https://www.lightningdesignsystem.com

IBMのデザインシステム
l SketchファイルによるUI Design KitとComponent Library Kitを提
供
l Vanila.jsとReact.js向けの実装を提供（Angula版は⾮公式）
l テーマがあって、サービス別にカスタマイズして使⽤
• Bluemix、Watson向けのテーマとその他汎⽤的なテーマがある
70
IBM Carbon Design System
http://carbondesignsystem.com

その他のデザインシステム
Alibabaのインターナルデスクトップ⽤のデザインシステム
71
ANT Design System
https://ant.design
U.S. Web Design Standards
https://standards.usa.gov
アメリカの政府機関のデザインシステム

デザインシステムの例
l プラットフォームレベルでUXの⼀貫性を維持するためのもの
72
Google Material Design
https://material.io/guidelines/material-
design/introduction.html
Microsoft Fluent Design System
https://ﬂuent.microsoft.com

⽇本企業のデザインシステム
73
Mercari UK
https://medium.com/mercari-uk/mercari-uks-new-look-design-system-2918964902d0

デザインシステムの⼀覧
Githubに公開されたデザインシステム⼀覧
74
Awesome Design Systems
https://github.com/alexpate/awesome-design-systems
Adele
https://adele.uxpin.com/
UXPinで運⽤するデザインシステム⼀覧

デザインシステム導⼊における課題

デザインシステム構築・運営における課題
l 初期コストがかかる
• デザインガイドの作成
• UI部品の作成
• デザインシステム公開のためのサイト構築
• デザイナーとエンジニアで構成されたチームが必要
l 継続的な運⽤が必要
• デザインシステムの専任チームが必要
l 結果的に現状は主に⼤⼿企業や有名サービスだけが
デザインシステムを構築・運営している
76

デザインシステム構築・運営における課題
l 初期コストがかかる
• デザインガイドの作成
• UI部品の作成
• デザインシステム公開のためのサイト構築
• デザイナーとエンジニアで構成されたチームが必要
l 継続的な運⽤が必要
• デザインシステムの専任チームが必要
l 結果的に現状は主に⼤⼿企業や有名サービスだけがデザインシ
ステムを構築・運営している
77
その対応策を２部で、
お話しさせていただきます︕

ITにおけるデザイン活用の課題と対応策ーデザインシステムでできること

ITにおけるデザイン活用の課題と対応策ーデザインシステムでできること

Recommended

Recommended

More Related Content

Similar to ITにおけるデザイン活用の課題と対応策ーデザインシステムでできること

Similar to ITにおけるデザイン活用の課題と対応策ーデザインシステムでできること (20)

More from Fixel Inc.

More from Fixel Inc. (6)

ITにおけるデザイン活用の課題と対応策ーデザインシステムでできること