Tweet
Tweet

Slide 1

Slide 1 text

古いWINDOWSアプリケーションのデザイン改善 その進め⽅と考慮事項を（事例交えて）ご紹介 SIer/情シス向け「ITとデザインは仲良し︕」シリーズ 第5回 2021/07/15

Slide 2

Slide 2 text

2 今⽇のスピーカの紹介 2 ۚ ੒఩ 3PZ,JN 69&OHJOFFS$&0PG'JYFM *OD 商社マン プログラマー ITコンサルタント/アーキテクト プロダクト オーナー アプリ開発者/システムアーキテクト UXデザイナー、サービスデザイナー グランスフィア株式会社 （現 GMOシステムコンサル ティング株式会社） 大林コーポレーション （株） BEA Japan Oracle Japan EMC Japan Agentec株式会社 NCデザイン＆コンサルティング 株式会社 （現 NCDC株式会社） Fixel株式会社 ΩϟϦΞ 5年 10年 10年

Slide 3

Slide 3 text

3 今⽇のスピーカの紹介 3 ۚ ੒఩ 3PZ,JN 69&OHJOFFS$&0PG'JYFM *OD 営業 テクノロジー デザイン 経営 ΩϟϦΞ 5年 10年 10年 ある程度は、俯瞰できます︕ ΩϟϦΞ

Slide 4

Slide 4 text

今⽇の内容が役⽴つと思われる聴者 l 古いWindowsベースのシステムを持っており、リニューアルを検討 している⽅ l Windowsアプリケーションのウェブアプリケーション化、SaaS化 を検討している⽅ l 上記のようなシステムのデザイン改善を担当しているデザイナー l その他 l 既存システムのデザインが古い、使い勝⼿が悪いなどの課題を持っている⽅ l 情シスやSIerに所属しており、デザインに対して課題を持っている⽅

Slide 5

Slide 5 text

今⽇話す内容 ① 現状と動機︓なぜリニュアルを考えているか︖ ② リニュアルプロジェクトの概要（デザインの視点から） ③ リニュアルにおける考慮事項（事例を交えて） ④ ラップアップ

Slide 6

Slide 6 text

① 現状と動機 なぜリニュアルを考えているか︖

Slide 7

Slide 7 text

始める前に︓ あなたのUIに改善が必要か否かを判断する とても簡単で、直感的な方法 をお伝えします！

Slide 8

Slide 8 text

答えは︓ Googleにて「Ugly UI」で検索し、なぜか見慣れた感じがするなら、 迅速な対応が必要！

Slide 9

Slide 9 text

もしこんなUIを使っているなら、リニューアルが必要でしょう︕ まさか、 今はこんなのは もうないでしょうが、 ⾒た⽬の時代感。

Slide 10

Slide 10 text

もしこんなUIを使っているなら、リニューアルが必要でしょう︕ 業務AAA 業務EEE 業務BBB 業務FFF 業務CCC 業務GGG 業務DDD 業務HHH 全ての画⾯が似ていて、 ほぼ区別がつかない

Slide 11

Slide 11 text

もしこんなUIを使っているなら、リニューアルが必要でしょう︕ 取り敢えず、必要な項⽬は表⽰した︕ • UIが整列されていない • データがグルーピングされていない ⼀⾒整理されているように⾒えるけど、 決まったグリッドにただ嵌めているだけ

Slide 12

Slide 12 text

もしこんなUIを使っているなら、リニューアルが必要でしょう︕ この画⾯は冗談ですが、 作業単位にウィンドウを いっぱい開いてしまい、 ユーザーが迷⼦になる︕

Slide 13

Slide 13 text

もしこんなUIを使っているなら、リニューアルが必要でしょう︕ タブが多すぎる、 万能のダイアログ

Slide 14

Slide 14 text

もしこんなUIを使っているなら、リニューアルが必要でしょう︕ • データのグルーピングが 不適切 • データを詰め込み過ぎ • ボタンが多すぎ、配置が 不適切、影響範囲がわか らない

Slide 15

Slide 15 text

デザイン改善の⼀例 Before

Slide 16

Slide 16 text

デザイン改善の⼀例 After

Slide 17

Slide 17 text

デザイン改善の⼀例 Before After ここでは、このような変化は デザイン改善と捉えません。 ※デザインそのものは変えず、 基盤技術のアップグレードだけをしたケース

Slide 18

Slide 18 text

弊社にデザイン改善を依頼するお客様の主な課題 l 内部的な課題 l 既存の技術スタックがそろそろ寿命・・・。 l ⻑い間、場当たり的に拡張しており、既存UIでは限界を感じている l モバイル端末への対応は⼀応できているけど、既存システムとの⼀貫性、使い勝⼿・分かりやすさの ⾯での再考が必要になった l 外部からの課題 l ユーザーからのデザインに対する要求レベルが⾼くなって来た l 企業・プロダクトレベルのリブランディングを⾏い、⼀貫性のあるデザインにしたい l より優れたUIでマーケティング、営業のフェーズで競合に⽐べて優位に⽴ちたい l 時代に合わせて、SaaS化、クラウドへのシフト、ウェブアプリケーションへの対応が必要になった

Slide 19

Slide 19 text

②リニュアルプロジェクトの概要 主にデザインの視点から

Slide 20

Slide 20 text

事前に知っておくこと、その１ l デザイン改善のためにはプロダクトオーナー、デザイナー、エンジニアの密なコラボ レーションが必要 l 改善後の技術基盤によって、考慮事項、デザイン作業のボリュームが変わる l Native Application ⇒ Native Application l Native Application ⇒ Web Application l Native Application ⇒ Cloud Platform (SaaS） l ⼀過性の改善ではなく、⻑期に渡って有効な体制を作るのが⼤事 l 基本的に、「あなたが考えているよりは、複雑で⼤がかりな作業」になる

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

事前に知っておくこと、その２ 反復 コンテキスト分析 ジャーニーマップ 作成 メンタルモデル 分析 プロトタイプ作成 ユーザーテスト 評価と改善 ゴールと範囲の 設定 分析フェーズ 実証フェーズ 評価基準の検討 計画フェーズ ペルソナ定義 UXデザインの⼀般的プロセス UXデザイン改善 （画⾯・機能の⾒直し） これらのタスクを 次ページでは ⼀つの⽮印で表現する

Slide 23

Slide 23 text

デザイン改善プロジェクトの全体図（Big Bang Style） 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 実施 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン （画⾯・機能の⾒直し） 評価・継続 全体計画作成 （KGI/KPIの定義） デザインガイドライン 作成 ビジュアルデザイン UIコンポーネント作成 新しい技術基盤の構築 実装・テスト リリース フィード バック対応 実行順 実行順 フィード バック対応 効果測定 と評価 デザイナー エンジニア 担当

Slide 24

Slide 24 text

デザイン改善プロジェクトの概要（Big Bang Style） 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 実施 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン （画⾯・機能の⾒直し） 評価・継続 全体計画作成 （KGI/KPIの定義） デザインガイドライン 作成 ビジュアルデザイン UIコンポーネント作成 新しい技術基盤の構築 実装・テスト リリース フィード バック対応 実行順 実行順 フィード バック対応 効果測定 と評価 デザイナー エンジニア 担当

Slide 25

Slide 25 text

計画フェーズ︓Windowsアプリケーションのバージョンアップの場合 l 古いWindowsアプリケーションの場合、既存コードからの制約が⼤きな影 響要因となる l ネイティブアプリケーションの改善の場合、事前の技術的確認が⼤事︕ l フロント以外の部分が分離できるのであれば既存コードの再利⽤も可能 l 分離が難しい場合、かつ既存コードを使う必要がある場合は、フロント実装 に採⽤可能な技術が制限される l 場合によっては、3rd PartyのUIライブラリーの導⼊を検討する必要がある l それによって、デザインの制限が⽣じる l デザインする画⾯のベース、使えるUI部品のスタイル・種類が変わる l カスタムUI作成におけるコスパを考慮し、実装可能なUIとそうでないUIを区分 して意識する必要がある 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 全体計画作成 （KGI/KPIの定義）

Slide 26

Slide 26 text

計画フェーズ︓Windowsから他の技術基盤に移⾏する場合 l SaaS化、クラウド対応の場合、 l 技術スタック全体を⾒直す必要がある l デザインだけでなく、技術的⽀援が必要になり、アーキテクチャ設計から始 める事になる。 l ウェブアプリケーション化の場合、 l フロント実装技術の選択が必要 l サーバー側の実装の再利⽤率を確認 l フロントとサーバーのインタフェース定義・実装 l 上記、⼆つの場合は l 既存システムからの制約が少なく、⽐較的に⾃由にデザイン可能 l UIの構成・画⾯遷移⽅式、操作⽅式など、全般的なリデザインが必要 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 全体計画作成 （KGI/KPIの定義）

Slide 27

Slide 27 text

実施フェーズ︓エンジニアとデザイナーとのコラボレーションが⼤事 l 制限事項を⾒極め、デザインを改善する時期 l 新しく採⽤した技術スタックでできることとできないことを明確にする 必要がある l 簡単に実装できる部分とそうでない部分の⾒極めが⼤事 l 再利⽤可能なUIの部品と画⾯レイアウト、画⾯遷移、操作パターンなど をデザイナーとエンジニアが協⼒して短期間で定義する必要がある l デザイナーとエンジニア間にUIに対する共通認識を築くことが⼤事 l 上記で定義したデザインパターンを利⽤して、各機能ごとの画⾯に展開 l エンジニアは並⾏して新しい開発基盤・インフラを構築する 実施 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン （画⾯・機能の⾒直し） 新しい技術基盤の構築

Slide 28

Slide 28 text

実施フェーズ︓再利⽤可能なデザインアセットの作成と管理の開始 l ⼀過性ではなく、組織の資産としてのデザインを作る l プロダクトのブランドに合ったビジュアルデザインの実施 l デザインガイドラインと再利⽤可能なUI部品と画⾯パターンを 作成 l コードと同じ考え⽅でデザインガイドラインとデザインアセッ ト・UIコンポーネントを管理・再利⽤する仕組みや体制を作る l 上記を利⽤してフロント実装を⾏うことで、⼯数削減と品質向 上はもちろん、デザインの⼀貫性を獲得する l 必要に応じて、他プロダクトへの横展開を検討する 実施 デザインガイドライン 作成 ビジュアルデザイン UIコンポーネント作成 実装・テスト

Slide 29

Slide 29 text

評価・継続︓プロジェクトの効果測定と継続的な改善 l 継続的な改善ができる体制と仕組みを作る l 各種指標の確認とユーザーアンケートなどを通して、最初の ゴールに達成しているかを確認 l ⾜りない部分及び追加のユーザーや営業からフィードバックを 検討し、更なる改善または次にステップに繋げる l 継続的な評価指標のモニタリングができる仕組みを作る l （必要に応じて）DevOps、DesignOpsと、それらを統合した ServiceOpsを推進する 評価・継続 フィードバック 対応 フィードバック 対応 効果測定と評価

Slide 30

Slide 30 text

デザイン改善プロジェクトの概要(Agile Style) 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 実施 プログラム管理 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン #1 （画⾯・機能の⾒直し） 評価・継続 全体計画作成 （KGI/KPIの定義） ビジュアル デザイン #1 UXデザイン #2 （画⾯・機能の⾒直し） ビジュアル デザイン #2 新しい技術基盤の構築 実装・テスト 実装 マイル ストーン#1 マイル ストーン#n リリース フィード バック対応 実行順 実行順 リリース UIコンポーネント作成・共有 デザインガイドライン作成・改善 （ デザインシステム作成を推奨） デザイナー エンジニア 担当

Slide 31

Slide 31 text

③リニュアルにおける考慮事項 （事例を交えて）

Slide 32

Slide 32 text

構造設計用ソフトウェア（Native to Native） 背景 • 20年程度前に作成した社内むけの専⾨家システム • 使い勝⼿が悪く、新しい機能要件や改善要件が溜まってきたので リニュアルを⾏うことに 課題 • 主要機能（エンジン）がMFCで作成され、かつフロントのコード と混じっていて、分離が困難 • プロジェクトの予算と期間を考慮しても、エンジンに該当する部 分の再利⽤は必須 • しかし、MFCではモダンな感じのデザインを実現することが難し い 対応 • MFC基盤の3rd PartyのUIライブラリー(BCG Control)を導⼊ • UIライブラリーの機能を最⼤限活⽤・カスタムUIの作成は避ける • デザインガイドラインの作成・提供とUI実装に対するデザインレ ビューを随時実施して品質担保 Before After

Slide 33

Slide 33 text

半導体製造装置のUI改善 (Native to Native) 背景 • 古い⾒た⽬で使い勝⼿の悪い制御画⾯を刷新したい • 視線の移動が多いので操作が疲れる（ミスも起きやすい） 課題 • 20年前の業界標準のデザインガイドラインがあり、業界のほと んどのプロダクトがそれに準拠している。それをどう⾒直すか︖ • XAMLなど、新しいフロント実装技術に関する経験が少ない 対応 • デザインガイドラインの裏の理由を理解した上で、モダンなUI に変更 • フロント実装のサンプル提供 得られた効果（具体的な数値等は⾮公開） • リリースご好評が得られた • 社内の他の⽣産装置にも展開し、会社としてデザイン統⼀を進め ることに Before After

Slide 34

Slide 34 text

3DCADソフトのUI改善 (Native to Native) 背景 ・新機能の追加に際だって、リボンUIを試してみたい ・ダークモードにも対応したい 課題 ・リボンUIに既存のツールバーのアイコンなどをどう⼊れ込むか ・既存ユーザーへの衝撃を最⼩限にしながら進めたい 対応・ ・ダークモードに必要な配⾊ルールの⾒直し ・アイコンの全般的な⾒直し ・ショートカットを覚えなくても使えるように、UIレイアウトの全 般的な再構成 ・ゆっくり、時間をかけて進める⽅式を取る 得られた効果（具体的な数値等は⾮公開） ・メインメニューサブメニューの構成を⾒直して使いやすく ・アイコンにも程よく説明を追記して、初⼼者をフォロー ・今⾵のデザインを取り⼊れて積極販売が出来るようになった Before After

Slide 35

Slide 35 text

コールセンター (Native & Web to Web) 背景 ・電話応対のために10個のシステムを使う必要がある ・システム毎に使い⽅がバラバラで、データ照会の⽅法も異なる ・電話応対及びその後の処理の効率性を上げ、トレーニングにかかる時 間と費⽤を低減したい 課題 ・異なる多数のシステムの統合し、統⼀したUIを提供 ・同じデータが様々な異なる業務で使われており、⾒る基準が異なる 対応 ・SOAのアーキテクチャの導⼊、業務分析、データ整理を⾏う ・業務の特徴を考慮した統⼀されたUIのデザインとそれに従ったデータ 関連APIの再設計 得られた効果 ・1画⾯で動的に遷移する処理が可能に ・１件の電話対応が平均4分から2分に短縮される Before After

Slide 36

Slide 36 text

PLMパッケージのUI改善 (Native to Web to Native) 背景 ・既存UIが古くなり、Web化とともにデザイン改善をしたい 課題 ・画⾯の数が多く、区別がつかない。 ・たくさんのウィンドウを開いてしまい、ユーザーが迷⼦になる ・検索条件が複雑かつカスタマイズできるけど、難しい 対応 ・ウェブのデザイン⽂法に合わせて新しいレイアウトを提⽰ ・コンテキストメニューをなくして、機能を明⽰的なUIで表現 ・⼀部の機能だけを分離し、ウェブ化してユーザーの反応を確認 ・ウェブの機能拡⼤＆ネイティブアプリもウェブと同様のデザイン に変更 得られた効果（具体的な数値等は⾮公開） ・ユーザーからの⾼評価 ・他のパッケージ製品にも同様のデザインを展開 Before After

Slide 37

Slide 37 text

調達管理システムのUI改善 (Native to Cloud to Web) 背景 ・DXの⼀環として全社システムのクラウド移⾏ ・AzureとSharepointの機能を活⽤し、ローコードで業務システムを作成 課題 ・外部パートナーに使ってもらうための画⾯のUXが悪いとの指摘を受けた ・しかしSharepointのListには表現の限界があり、UXの改善に限界がある ・同様の問題は他の業務システムでも発⽣する可能性がある 対応 ・実装の制限を無視して、最適のUXをデザインする ・SharepointのListなどの機能からできることとできないことを確認 ・カスタムウェブフロント実装を決め、デザインシステムで標準化する 得られた効果（具体的な数値等は⾮公開） ・ユーザーからの⾼評価 ・他の業務システムに対してもよいUXを低下で提供できる基盤ができる Before After

Slide 38

Slide 38 text

建築関連パッケージのクラウド対応 (Native to Cloud & Native)

Slide 39

Slide 39 text

建築関連パッケージのクラウド対応 (Native to Cloud & Native)

Slide 40

Slide 40 text

CADソリューションのUI改善 (Native to….)

Slide 41

Slide 41 text

考慮すべき点の纏め l 異なる⽂法に注意︕ l ファンクションキーの使⽤ ⇒ 別の⼿段を提供することを検討 l 複数のウィンドウの⽴ち上げ ⇒ 避ける l コンテキストメニュー（右クリック）を多⽤している ⇒ 避ける l 巨⼈の肩に乗る l 対象プラットフォームの有名デザインガイドラインを参照する l 既存システムからの制限を元に、どれに対応できるか確認 l できるだけ、最新のデザインガイドラインに準拠するようにする。 l ⾞輪の再発明を避ける l 3rd PartyのUIライブラリーを検討する（カスタマイズは必須）

Slide 42

Slide 42 text

考慮すべき点の纏め l IAはとても⼤事︕ l データを適切にグルーピングする l ⽤語・表現を⾒直す ⇦ 最も安価で有効なUX改善⽅法の⼀つ︕ l デザイン改善の⽬的を明確に l 定義されていない問題は解けない l 問題定義を間違えると回答も間違える l 継続は⼒也 l デザインガイドラインと再利⽤できるU部品を作成する ⇒ デザインシステムを作成 l フロントチームを別途設けることを検討する（デザイナーを含める）

Slide 43

Slide 43 text

④ラップアップ

Slide 44

Slide 44 text

今⽇の内容のサマリー l プロジェクトの観点から l ⽬的と要件を明確に l 上記から、UX要件を明確にする l 技術的制約を確認し、採⽤できる外部ライブラ リーなどの選択を慎重に l マイルストーンを定義。 l Small Startでできるか、Big Bangかを選択す る。 l Big Bangはできるだけ避ける l デザイナーとエンジニアの密なコラボを⾏える 体制を作る UX要件定義 システム要件定義 機能要件 ⾮機能要件 新しいタスクとして 認識しましょう︕

Slide 45

Slide 45 text

今⽇の内容のサマリー l デザインの観点から l プラットフォームに適したデザイン⽂法の置き換えを検討し、ルール化する l 既存システムのUIの理由をしっかり理解する l 単純な置き換えではなく、⽬的を考慮した最善の対応策を検討する l 余計な機能を⾒つけて、排除する︕ l 与えられた条件の上で、使⽤可能なデフォルトのUI部品を把握し、できるだけそれ を活⽤ l カスタムUIはその必然性を検討して慎重に作成を判断 l ウェブ、モバイル、ネイティブアプリの共存を考慮したデザインにする l デザインガイドライン・デザインシステムの作成と共有を推奨 l デザインは⼀過性ではない時代。再利⽤できる部品を揃えることで、継続的な改善に 備える

Slide 46

Slide 46 text

最後に l デザイン改善のプロジェクトは思ったより⼤きなタスクになる可能性があります l しかし、あり得るリスクを理解した上で、順次進めればリスクは⼤きくなりません l デザイン改善のビジネスにおける効果は確実です。数字が証明します l デザインは避けて通れない存在になっています。この際に真剣に向き合ってみれば 如何でしょうか︖ ※その他の有⽤かもしれない資料︓https://speakerdeck.com/fixel_admin

Slide 47

Slide 47 text

MAKE DESIGN EASY SIer/情シスのデザインパートナー ありがとうございました︕