「古いWINDOWSアプリケーションのデザイン改善」セミナー資料

2021年7月15日（木）14時に行ったセミナーの資料です。

Transcript

1. 古いWINDOWSアプリケーションのデザイン改善 その進め⽅と考慮事項を（事例交えて）ご紹介 SIer/情シス向け「ITとデザインは仲良し︕」シリーズ 第5回 2021/07/15
2. 2 今⽇のスピーカの紹介 2 ۚ ੒఩ 3PZ
   ,JN 69
   &OHJOFFS
   
   $&0
   PG
   'JYFM *OD 商社マン プログラマー ITコンサルタント/アーキテクト プロダクト オーナー アプリ開発者/システムアーキテクト UXデザイナー、サービスデザイナー グランスフィア株式会社 （現 GMOシステムコンサル ティング株式会社） 大林コーポレーション （株） BEA Japan Oracle Japan EMC Japan Agentec株式会社 NCデザイン＆コンサルティング 株式会社 （現 NCDC株式会社） Fixel株式会社 ΩϟϦΞ 5年 10年 10年
3. 3 今⽇のスピーカの紹介 3 ۚ ੒఩ 3PZ
   ,JN 69
   &OHJOFFS
   
   $&0
   PG
   'JYFM *OD 営業 テクノロジー デザイン 経営 ΩϟϦΞ 5年 10年 10年 ある程度は、俯瞰できます︕ ΩϟϦΞ
4. 今⽇の内容が役⽴つと思われる聴者 l 古いWindowsベースのシステムを持っており、リニューアルを検討 している⽅ l Windowsアプリケーションのウェブアプリケーション化、SaaS化 を検討している⽅ l 上記のようなシステムのデザイン改善を担当しているデザイナー l その他 l 既存システムのデザインが古い、使い勝⼿が悪いなどの課題を持っている⽅ l 情シスやSIerに所属しており、デザインに対して課題を持っている⽅
5. 今⽇話す内容 ① 現状と動機︓なぜリニュアルを考えているか︖ ② リニュアルプロジェクトの概要（デザインの視点から） ③ リニュアルにおける考慮事項（事例を交えて） ④ ラップアップ
6. ① 現状と動機 なぜリニュアルを考えているか︖
7. 始める前に︓ あなたのUIに改善が必要か否かを判断する とても簡単で、直感的な方法 をお伝えします！
8. 答えは︓ Googleにて「Ugly UI」で検索し、なぜか見慣れた感じがするなら、 迅速な対応が必要！
9. もしこんなUIを使っているなら、リニューアルが必要でしょう︕ まさか、 今はこんなのは もうないでしょうが、 ⾒た⽬の時代感。
10. もしこんなUIを使っているなら、リニューアルが必要でしょう︕ 業務AAA 業務EEE 業務BBB 業務FFF 業務CCC 業務GGG 業務DDD 業務HHH 全ての画⾯が似ていて、 ほぼ区別がつかない
11. もしこんなUIを使っているなら、リニューアルが必要でしょう︕ 取り敢えず、必要な項⽬は表⽰した︕ • UIが整列されていない • データがグルーピングされていない ⼀⾒整理されているように⾒えるけど、 決まったグリッドにただ嵌めているだけ
12. もしこんなUIを使っているなら、リニューアルが必要でしょう︕ この画⾯は冗談ですが、 作業単位にウィンドウを いっぱい開いてしまい、 ユーザーが迷⼦になる︕
13. もしこんなUIを使っているなら、リニューアルが必要でしょう︕ タブが多すぎる、 万能のダイアログ
14. もしこんなUIを使っているなら、リニューアルが必要でしょう︕ • データのグルーピングが 不適切 • データを詰め込み過ぎ • ボタンが多すぎ、配置が 不適切、影響範囲がわか らない
15. デザイン改善の⼀例 Before
16. デザイン改善の⼀例 After
17. デザイン改善の⼀例 Before After ここでは、このような変化は デザイン改善と捉えません。 ※デザインそのものは変えず、 基盤技術のアップグレードだけをしたケース
18. 弊社にデザイン改善を依頼するお客様の主な課題 l 内部的な課題 l 既存の技術スタックがそろそろ寿命・・・。 l ⻑い間、場当たり的に拡張しており、既存UIでは限界を感じている l モバイル端末への対応は⼀応できているけど、既存システムとの⼀貫性、使い勝⼿・分かりやすさの ⾯での再考が必要になった l 外部からの課題 l ユーザーからのデザインに対する要求レベルが⾼くなって来た l 企業・プロダクトレベルのリブランディングを⾏い、⼀貫性のあるデザインにしたい l より優れたUIでマーケティング、営業のフェーズで競合に⽐べて優位に⽴ちたい l 時代に合わせて、SaaS化、クラウドへのシフト、ウェブアプリケーションへの対応が必要になった
19. ②リニュアルプロジェクトの概要 主にデザインの視点から
20. 事前に知っておくこと、その１ l デザイン改善のためにはプロダクトオーナー、デザイナー、エンジニアの密なコラボ レーションが必要 l 改善後の技術基盤によって、考慮事項、デザイン作業のボリュームが変わる l Native Application ⇒ Native Application l Native Application ⇒ Web Application l Native Application ⇒ Cloud Platform (SaaS） l ⼀過性の改善ではなく、⻑期に渡って有効な体制を作るのが⼤事 l 基本的に、「あなたが考えているよりは、複雑で⼤がかりな作業」になる
21. 事前に知っておくこと、その２ 反復 コンテキスト分析 ジャーニーマップ 作成 メンタルモデル 分析 プロトタイプ作成 ユーザーテスト 評価と改善 ゴールと範囲の 設定 分析フェーズ 実証フェーズ l プロジェクトのゴール・要件に応じて上記のプロセスを適切に調整 評価基準の検討 計画フェーズ ペルソナ定義 UXデザインの⼀般的プロセス
22. 事前に知っておくこと、その２ 反復 コンテキスト分析 ジャーニーマップ 作成 メンタルモデル 分析 プロトタイプ作成 ユーザーテスト 評価と改善 ゴールと範囲の 設定 分析フェーズ 実証フェーズ 評価基準の検討 計画フェーズ ペルソナ定義 UXデザインの⼀般的プロセス UXデザイン改善 （画⾯・機能の⾒直し） これらのタスクを 次ページでは ⼀つの⽮印で表現する
23. デザイン改善プロジェクトの全体図（Big Bang Style） 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 実施 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン （画⾯・機能の⾒直し） 評価・継続 全体計画作成 （KGI/KPIの定義） デザインガイドライン 作成 ビジュアルデザイン UIコンポーネント作成 新しい技術基盤の構築 実装・テスト リリース フィード バック対応 実行順 実行順 フィード バック対応 効果測定 と評価 デザイナー エンジニア 担当
24. デザイン改善プロジェクトの概要（Big Bang Style） 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 実施 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン （画⾯・機能の⾒直し） 評価・継続 全体計画作成 （KGI/KPIの定義） デザインガイドライン 作成 ビジュアルデザイン UIコンポーネント作成 新しい技術基盤の構築 実装・テスト リリース フィード バック対応 実行順 実行順 フィード バック対応 効果測定 と評価 デザイナー エンジニア 担当
25. 計画フェーズ︓Windowsアプリケーションのバージョンアップの場合 l 古いWindowsアプリケーションの場合、既存コードからの制約が⼤きな影 響要因となる l ネイティブアプリケーションの改善の場合、事前の技術的確認が⼤事︕ l フロント以外の部分が分離できるのであれば既存コードの再利⽤も可能 l 分離が難しい場合、かつ既存コードを使う必要がある場合は、フロント実装 に採⽤可能な技術が制限される l 場合によっては、3rd PartyのUIライブラリーの導⼊を検討する必要がある l それによって、デザインの制限が⽣じる l デザインする画⾯のベース、使えるUI部品のスタイル・種類が変わる l カスタムUI作成におけるコスパを考慮し、実装可能なUIとそうでないUIを区分 して意識する必要がある 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 全体計画作成 （KGI/KPIの定義）
26. 計画フェーズ︓Windowsから他の技術基盤に移⾏する場合 l SaaS化、クラウド対応の場合、 l 技術スタック全体を⾒直す必要がある l デザインだけでなく、技術的⽀援が必要になり、アーキテクチャ設計から始 める事になる。 l ウェブアプリケーション化の場合、 l フロント実装技術の選択が必要 l サーバー側の実装の再利⽤率を確認 l フロントとサーバーのインタフェース定義・実装 l 上記、⼆つの場合は l 既存システムからの制約が少なく、⽐較的に⾃由にデザイン可能 l UIの構成・画⾯遷移⽅式、操作⽅式など、全般的なリデザインが必要 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 全体計画作成 （KGI/KPIの定義）
27. 実施フェーズ︓エンジニアとデザイナーとのコラボレーションが⼤事 l 制限事項を⾒極め、デザインを改善する時期 l 新しく採⽤した技術スタックでできることとできないことを明確にする 必要がある l 簡単に実装できる部分とそうでない部分の⾒極めが⼤事 l 再利⽤可能なUIの部品と画⾯レイアウト、画⾯遷移、操作パターンなど をデザイナーとエンジニアが協⼒して短期間で定義する必要がある l デザイナーとエンジニア間にUIに対する共通認識を築くことが⼤事 l 上記で定義したデザインパターンを利⽤して、各機能ごとの画⾯に展開 l エンジニアは並⾏して新しい開発基盤・インフラを構築する 実施 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン （画⾯・機能の⾒直し） 新しい技術基盤の構築
28. 実施フェーズ︓再利⽤可能なデザインアセットの作成と管理の開始 l ⼀過性ではなく、組織の資産としてのデザインを作る l プロダクトのブランドに合ったビジュアルデザインの実施 l デザインガイドラインと再利⽤可能なUI部品と画⾯パターンを 作成 l コードと同じ考え⽅でデザインガイドラインとデザインアセッ ト・UIコンポーネントを管理・再利⽤する仕組みや体制を作る l 上記を利⽤してフロント実装を⾏うことで、⼯数削減と品質向 上はもちろん、デザインの⼀貫性を獲得する l 必要に応じて、他プロダクトへの横展開を検討する 実施 デザインガイドライン 作成 ビジュアルデザイン UIコンポーネント作成 実装・テスト
29. 評価・継続︓プロジェクトの効果測定と継続的な改善 l 継続的な改善ができる体制と仕組みを作る l 各種指標の確認とユーザーアンケートなどを通して、最初の ゴールに達成しているかを確認 l ⾜りない部分及び追加のユーザーや営業からフィードバックを 検討し、更なる改善または次にステップに繋げる l 継続的な評価指標のモニタリングができる仕組みを作る l （必要に応じて）DevOps、DesignOpsと、それらを統合した ServiceOpsを推進する 評価・継続 フィードバック 対応 フィードバック 対応 効果測定と評価
30. デザイン改善プロジェクトの概要(Agile Style) 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 実施 プログラム管理 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン #1 （画⾯・機能の⾒直し） 評価・継続 全体計画作成 （KGI/KPIの定義） ビジュアル デザイン #1 UXデザイン #2 （画⾯・機能の⾒直し） ビジュアル デザイン #2 新しい技術基盤の構築 実装・テスト 実装 マイル ストーン#1 マイル ストーン#n リリース フィード バック対応 実行順 実行順 リリース UIコンポーネント作成・共有 デザインガイドライン作成・改善 （ デザインシステム作成を推奨） デザイナー エンジニア 担当
31. ③リニュアルにおける考慮事項 （事例を交えて）
32. 構造設計用ソフトウェア（Native to Native） 背景 • 20年程度前に作成した社内むけの専⾨家システム • 使い勝⼿が悪く、新しい機能要件や改善要件が溜まってきたので リニュアルを⾏うことに 課題 • 主要機能（エンジン）がMFCで作成され、かつフロントのコード と混じっていて、分離が困難 • プロジェクトの予算と期間を考慮しても、エンジンに該当する部 分の再利⽤は必須 • しかし、MFCではモダンな感じのデザインを実現することが難し い 対応 • MFC基盤の3rd PartyのUIライブラリー(BCG Control)を導⼊ • UIライブラリーの機能を最⼤限活⽤・カスタムUIの作成は避ける • デザインガイドラインの作成・提供とUI実装に対するデザインレ ビューを随時実施して品質担保 Before After
33. 半導体製造装置のUI改善 (Native to Native) 背景 • 古い⾒た⽬で使い勝⼿の悪い制御画⾯を刷新したい • 視線の移動が多いので操作が疲れる（ミスも起きやすい） 課題 • 20年前の業界標準のデザインガイドラインがあり、業界のほと んどのプロダクトがそれに準拠している。それをどう⾒直すか︖ • XAMLなど、新しいフロント実装技術に関する経験が少ない 対応 • デザインガイドラインの裏の理由を理解した上で、モダンなUI に変更 • フロント実装のサンプル提供 得られた効果（具体的な数値等は⾮公開） • リリースご好評が得られた • 社内の他の⽣産装置にも展開し、会社としてデザイン統⼀を進め ることに Before After
34. 3DCADソフトのUI改善 (Native to Native) 背景 ・新機能の追加に際だって、リボンUIを試してみたい ・ダークモードにも対応したい 課題 ・リボンUIに既存のツールバーのアイコンなどをどう⼊れ込むか ・既存ユーザーへの衝撃を最⼩限にしながら進めたい 対応・ ・ダークモードに必要な配⾊ルールの⾒直し ・アイコンの全般的な⾒直し ・ショートカットを覚えなくても使えるように、UIレイアウトの全 般的な再構成 ・ゆっくり、時間をかけて進める⽅式を取る 得られた効果（具体的な数値等は⾮公開） ・メインメニューサブメニューの構成を⾒直して使いやすく ・アイコンにも程よく説明を追記して、初⼼者をフォロー ・今⾵のデザインを取り⼊れて積極販売が出来るようになった Before After
35. コールセンター (Native & Web to Web) 背景 ・電話応対のために10個のシステムを使う必要がある ・システム毎に使い⽅がバラバラで、データ照会の⽅法も異なる ・電話応対及びその後の処理の効率性を上げ、トレーニングにかかる時 間と費⽤を低減したい 課題 ・異なる多数のシステムの統合し、統⼀したUIを提供 ・同じデータが様々な異なる業務で使われており、⾒る基準が異なる 対応 ・SOAのアーキテクチャの導⼊、業務分析、データ整理を⾏う ・業務の特徴を考慮した統⼀されたUIのデザインとそれに従ったデータ 関連APIの再設計 得られた効果 ・1画⾯で動的に遷移する処理が可能に ・１件の電話対応が平均4分から2分に短縮される Before After
36. PLMパッケージのUI改善 (Native to Web to Native) 背景 ・既存UIが古くなり、Web化とともにデザイン改善をしたい 課題 ・画⾯の数が多く、区別がつかない。 ・たくさんのウィンドウを開いてしまい、ユーザーが迷⼦になる ・検索条件が複雑かつカスタマイズできるけど、難しい 対応 ・ウェブのデザイン⽂法に合わせて新しいレイアウトを提⽰ ・コンテキストメニューをなくして、機能を明⽰的なUIで表現 ・⼀部の機能だけを分離し、ウェブ化してユーザーの反応を確認 ・ウェブの機能拡⼤＆ネイティブアプリもウェブと同様のデザイン に変更 得られた効果（具体的な数値等は⾮公開） ・ユーザーからの⾼評価 ・他のパッケージ製品にも同様のデザインを展開 Before After
37. 調達管理システムのUI改善 (Native to Cloud to Web) 背景 ・DXの⼀環として全社システムのクラウド移⾏ ・AzureとSharepointの機能を活⽤し、ローコードで業務システムを作成 課題 ・外部パートナーに使ってもらうための画⾯のUXが悪いとの指摘を受けた ・しかしSharepointのListには表現の限界があり、UXの改善に限界がある ・同様の問題は他の業務システムでも発⽣する可能性がある 対応 ・実装の制限を無視して、最適のUXをデザインする ・SharepointのListなどの機能からできることとできないことを確認 ・カスタムウェブフロント実装を決め、デザインシステムで標準化する 得られた効果（具体的な数値等は⾮公開） ・ユーザーからの⾼評価 ・他の業務システムに対してもよいUXを低下で提供できる基盤ができる Before After
38. 建築関連パッケージのクラウド対応 (Native to Cloud & Native)
39. 建築関連パッケージのクラウド対応 (Native to Cloud & Native)
40. CADソリューションのUI改善 (Native to….)
41. 考慮すべき点の纏め l 異なる⽂法に注意︕ l ファンクションキーの使⽤ ⇒ 別の⼿段を提供することを検討 l 複数のウィンドウの⽴ち上げ ⇒ 避ける l コンテキストメニュー（右クリック）を多⽤している ⇒ 避ける l 巨⼈の肩に乗る l 対象プラットフォームの有名デザインガイドラインを参照する l 既存システムからの制限を元に、どれに対応できるか確認 l できるだけ、最新のデザインガイドラインに準拠するようにする。 l ⾞輪の再発明を避ける l 3rd PartyのUIライブラリーを検討する（カスタマイズは必須）
42. 考慮すべき点の纏め l IAはとても⼤事︕ l データを適切にグルーピングする l ⽤語・表現を⾒直す ⇦ 最も安価で有効なUX改善⽅法の⼀つ︕ l デザイン改善の⽬的を明確に l 定義されていない問題は解けない l 問題定義を間違えると回答も間違える l 継続は⼒也 l デザインガイドラインと再利⽤できるU部品を作成する ⇒ デザインシステムを作成 l フロントチームを別途設けることを検討する（デザイナーを含める）
43. ④ラップアップ
44. 今⽇の内容のサマリー l プロジェクトの観点から l ⽬的と要件を明確に l 上記から、UX要件を明確にする l 技術的制約を確認し、採⽤できる外部ライブラ リーなどの選択を慎重に l マイルストーンを定義。 l Small Startでできるか、Big Bangかを選択す る。 l Big Bangはできるだけ避ける l デザイナーとエンジニアの密なコラボを⾏える 体制を作る UX要件定義 システム要件定義 機能要件 ⾮機能要件 新しいタスクとして 認識しましょう︕
45. 今⽇の内容のサマリー l デザインの観点から l プラットフォームに適したデザイン⽂法の置き換えを検討し、ルール化する l 既存システムのUIの理由をしっかり理解する l 単純な置き換えではなく、⽬的を考慮した最善の対応策を検討する l 余計な機能を⾒つけて、排除する︕ l 与えられた条件の上で、使⽤可能なデフォルトのUI部品を把握し、できるだけそれ を活⽤ l カスタムUIはその必然性を検討して慎重に作成を判断 l ウェブ、モバイル、ネイティブアプリの共存を考慮したデザインにする l デザインガイドライン・デザインシステムの作成と共有を推奨 l デザインは⼀過性ではない時代。再利⽤できる部品を揃えることで、継続的な改善に 備える
46. 最後に l デザイン改善のプロジェクトは思ったより⼤きなタスクになる可能性があります l しかし、あり得るリスクを理解した上で、順次進めればリスクは⼤きくなりません l デザイン改善のビジネスにおける効果は確実です。数字が証明します l デザインは避けて通れない存在になっています。この際に真剣に向き合ってみれば 如何でしょうか︖ ※その他の有⽤かもしれない資料︓https://speakerdeck.com/fixel_admin
47. MAKE DESIGN EASY SIer/情シスのデザインパートナー ありがとうございました︕