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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Slide 3

Slide 3 text

UXデザインの事例紹介

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Fixel Inc. All rights reserved. 実施内容プロセス・期間 7 ［フェーズ 0］パートナー選定［フェーズ 1］ UI改善プロジェクト［フェーズ 2］ UX改善プロジェクト約2カ⽉約9カ⽉約3カ⽉ ① 提案コンペ（6社） UX改善のための計画と改善案の提案コンペ ② トライアルプロジェクト（3社）既存サービスの改善を短期ワークショップ形式で⾏い、プロトタイピングと簡易ユーザーテストまで実施。その後の改善の⽅針と計画を提案しパートナーに選定された。実施内容 1stリリース 2ndリリース

Slide 8

Slide 8 text

Fixel Inc. All rights reserved. 実施内容プロセス・期間 8 ［フェーズ 0］パートナー選定［フェーズ 1］ UI改善プロジェクト［フェーズ 2］ UX改善プロジェクト約2カ⽉約9カ⽉約3カ⽉ ① 現状分析画⾯遷移・レイアウトやUI要素の分析、競合⽐較 ② UI改善案検討分析を踏まえUI部品/画⾯レイアウトなどを検討 ③ 評価検証機能⾯、実装⾯などから検証と調整 ④ 実装時の技術サポート新UIの実装⽅法に関する技術⽀援 ⑤ リリース後評価リリース後の評価、次フェーズ計画実施内容 1stリリース 2ndリリース

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Fixel Inc. All rights reserved. 実施内容プロセス・期間 11 ［フェーズ 0］パートナー選定［フェーズ 1］ UI改善プロジェクト［フェーズ 2］ UX改善プロジェクト約2カ⽉約9カ⽉約3カ⽉ ① 既存ユーザーへの調査インタビュー調査、課題の抽出 ② UX改善案検討 UX/UI改善⽅針、ワイヤーフレーム検討、ビジュアルデザイン調整、プロトタイピング ③ 評価検証ユーザーテストを⾏い評価と改善 ④ 実装時の技術サポート新UIの実装⽅法に関する技術⽀援実施内容 2ndリリース

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

さらなる課題

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

より根本的な質問

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

デザインシステムの紹介

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

Fixel Inc. All rights reserved. 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

Slide 71

Slide 71 text

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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