Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Fixel Inc.
July 20, 2021

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

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

Fixel Inc.

July 20, 2021
Tweet

More Decks by Fixel Inc.

Other Decks in Design

Transcript

  1. 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年
  2. 3 今⽇のスピーカの紹介 3 ۚ ੒఩ 3PZ,JN 69&OHJOFFS$&0PG'JYFM *OD 営業 テクノロジー

    デザイン 経営 ΩϟϦΞ 5年 10年 10年 ある程度は、俯瞰できます︕ ΩϟϦΞ
  3. 弊社にデザイン改善を依頼するお客様の主な課題 l 内部的な課題 l 既存の技術スタックがそろそろ寿命・・・。 l ⻑い間、場当たり的に拡張しており、既存UIでは限界を感じている l モバイル端末への対応は⼀応できているけど、既存システムとの⼀貫性、使い勝⼿・分かりやすさの ⾯での再考が必要になった

    l 外部からの課題 l ユーザーからのデザインに対する要求レベルが⾼くなって来た l 企業・プロダクトレベルのリブランディングを⾏い、⼀貫性のあるデザインにしたい l より優れたUIでマーケティング、営業のフェーズで競合に⽐べて優位に⽴ちたい l 時代に合わせて、SaaS化、クラウドへのシフト、ウェブアプリケーションへの対応が必要になった
  4. 事前に知っておくこと、その1 l デザイン改善のためにはプロダクトオーナー、デザイナー、エンジニアの密なコラボ レーションが必要 l 改善後の技術基盤によって、考慮事項、デザイン作業のボリュームが変わる l Native Application ⇒

    Native Application l Native Application ⇒ Web Application l Native Application ⇒ Cloud Platform (SaaS) l ⼀過性の改善ではなく、⻑期に渡って有効な体制を作るのが⼤事 l 基本的に、「あなたが考えているよりは、複雑で⼤がかりな作業」になる
  5. 事前に知っておくこと、その2 反復 コンテキスト分析 ジャーニーマップ 作成 メンタルモデル 分析 プロトタイプ作成 ユーザーテスト 評価と改善

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

    ゴールと範囲の 設定 分析フェーズ 実証フェーズ 評価基準の検討 計画フェーズ ペルソナ定義 UXデザインの⼀般的プロセス UXデザイン改善 (画⾯・機能の⾒直し) これらのタスクを 次ページでは ⼀つの⽮印で表現する
  7. デザイン改善プロジェクトの全体図(Big Bang Style) 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 •

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

    ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 実施 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン (画⾯・機能の⾒直し) 評価・継続 全体計画作成 (KGI/KPIの定義) デザインガイドライン 作成 ビジュアルデザイン UIコンポーネント作成 新しい技術基盤の構築 実装・テスト リリース フィード バック対応 実行順 実行順 フィード バック対応 効果測定 と評価 デザイナー エンジニア 担当
  9. 計画フェーズ︓Windowsアプリケーションのバージョンアップの場合 l 古いWindowsアプリケーションの場合、既存コードからの制約が⼤きな影 響要因となる l ネイティブアプリケーションの改善の場合、事前の技術的確認が⼤事︕ l フロント以外の部分が分離できるのであれば既存コードの再利⽤も可能 l 分離が難しい場合、かつ既存コードを使う必要がある場合は、フロント実装

    に採⽤可能な技術が制限される l 場合によっては、3rd PartyのUIライブラリーの導⼊を検討する必要がある l それによって、デザインの制限が⽣じる l デザインする画⾯のベース、使えるUI部品のスタイル・種類が変わる l カスタムUI作成におけるコスパを考慮し、実装可能なUIとそうでないUIを区分 して意識する必要がある 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 全体計画作成 (KGI/KPIの定義)
  10. 計画フェーズ︓Windowsから他の技術基盤に移⾏する場合 l SaaS化、クラウド対応の場合、 l 技術スタック全体を⾒直す必要がある l デザインだけでなく、技術的⽀援が必要になり、アーキテクチャ設計から始 める事になる。 l ウェブアプリケーション化の場合、

    l フロント実装技術の選択が必要 l サーバー側の実装の再利⽤率を確認 l フロントとサーバーのインタフェース定義・実装 l 上記、⼆つの場合は l 既存システムからの制約が少なく、⽐較的に⾃由にデザイン可能 l UIの構成・画⾯遷移⽅式、操作⽅式など、全般的なリデザインが必要 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの 課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 全体計画作成 (KGI/KPIの定義)
  11. 実施フェーズ︓エンジニアとデザイナーとのコラボレーションが⼤事 l 制限事項を⾒極め、デザインを改善する時期 l 新しく採⽤した技術スタックでできることとできないことを明確にする 必要がある l 簡単に実装できる部分とそうでない部分の⾒極めが⼤事 l 再利⽤可能なUIの部品と画⾯レイアウト、画⾯遷移、操作パターンなど

    をデザイナーとエンジニアが協⼒して短期間で定義する必要がある l デザイナーとエンジニア間にUIに対する共通認識を築くことが⼤事 l 上記で定義したデザインパターンを利⽤して、各機能ごとの画⾯に展開 l エンジニアは並⾏して新しい開発基盤・インフラを構築する 実施 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン (画⾯・機能の⾒直し) 新しい技術基盤の構築
  12. 実施フェーズ︓再利⽤可能なデザインアセットの作成と管理の開始 l ⼀過性ではなく、組織の資産としてのデザインを作る l プロダクトのブランドに合ったビジュアルデザインの実施 l デザインガイドラインと再利⽤可能なUI部品と画⾯パターンを 作成 l コードと同じ考え⽅でデザインガイドラインとデザインアセッ

    ト・UIコンポーネントを管理・再利⽤する仕組みや体制を作る l 上記を利⽤してフロント実装を⾏うことで、⼯数削減と品質向 上はもちろん、デザインの⼀貫性を獲得する l 必要に応じて、他プロダクトへの横展開を検討する 実施 デザインガイドライン 作成 ビジュアルデザイン UIコンポーネント作成 実装・テスト
  13. デザイン改善プロジェクトの概要(Agile Style) 計画 既存課題の整理 • ビジネスの課題 • 営業からの課題 • ユーザーからの

    課題 • 技術的課題 • デザインの改題 優先順位の定義 技術的制約の確認 デザイン⽅針決定 実施 プログラム管理 ブランディングデザイン 技術的フィジビリティ確認 UXデザイン #1 (画⾯・機能の⾒直し) 評価・継続 全体計画作成 (KGI/KPIの定義) ビジュアル デザイン #1 UXデザイン #2 (画⾯・機能の⾒直し) ビジュアル デザイン #2 新しい技術基盤の構築 実装・テスト 実装 マイル ストーン#1 マイル ストーン#n リリース フィード バック対応 実行順 実行順 リリース UIコンポーネント作成・共有 デザインガイドライン作成・改善 ( デザインシステム作成を推奨) デザイナー エンジニア 担当
  14. 構造設計用ソフトウェア(Native to Native) 背景 • 20年程度前に作成した社内むけの専⾨家システム • 使い勝⼿が悪く、新しい機能要件や改善要件が溜まってきたので リニュアルを⾏うことに 課題

    • 主要機能(エンジン)がMFCで作成され、かつフロントのコード と混じっていて、分離が困難 • プロジェクトの予算と期間を考慮しても、エンジンに該当する部 分の再利⽤は必須 • しかし、MFCではモダンな感じのデザインを実現することが難し い 対応 • MFC基盤の3rd PartyのUIライブラリー(BCG Control)を導⼊ • UIライブラリーの機能を最⼤限活⽤・カスタムUIの作成は避ける • デザインガイドラインの作成・提供とUI実装に対するデザインレ ビューを随時実施して品質担保 Before After
  15. 半導体製造装置のUI改善 (Native to Native) 背景 • 古い⾒た⽬で使い勝⼿の悪い制御画⾯を刷新したい • 視線の移動が多いので操作が疲れる(ミスも起きやすい) 課題

    • 20年前の業界標準のデザインガイドラインがあり、業界のほと んどのプロダクトがそれに準拠している。それをどう⾒直すか︖ • XAMLなど、新しいフロント実装技術に関する経験が少ない 対応 • デザインガイドラインの裏の理由を理解した上で、モダンなUI に変更 • フロント実装のサンプル提供 得られた効果(具体的な数値等は⾮公開) • リリースご好評が得られた • 社内の他の⽣産装置にも展開し、会社としてデザイン統⼀を進め ることに Before After
  16. 3DCADソフトのUI改善 (Native to Native) 背景 ・新機能の追加に際だって、リボンUIを試してみたい ・ダークモードにも対応したい 課題 ・リボンUIに既存のツールバーのアイコンなどをどう⼊れ込むか ・既存ユーザーへの衝撃を最⼩限にしながら進めたい

    対応・ ・ダークモードに必要な配⾊ルールの⾒直し ・アイコンの全般的な⾒直し ・ショートカットを覚えなくても使えるように、UIレイアウトの全 般的な再構成 ・ゆっくり、時間をかけて進める⽅式を取る 得られた効果(具体的な数値等は⾮公開) ・メインメニューサブメニューの構成を⾒直して使いやすく ・アイコンにも程よく説明を追記して、初⼼者をフォロー ・今⾵のデザインを取り⼊れて積極販売が出来るようになった Before After
  17. コールセンター (Native & Web to Web) 背景 ・電話応対のために10個のシステムを使う必要がある ・システム毎に使い⽅がバラバラで、データ照会の⽅法も異なる ・電話応対及びその後の処理の効率性を上げ、トレーニングにかかる時

    間と費⽤を低減したい 課題 ・異なる多数のシステムの統合し、統⼀したUIを提供 ・同じデータが様々な異なる業務で使われており、⾒る基準が異なる 対応 ・SOAのアーキテクチャの導⼊、業務分析、データ整理を⾏う ・業務の特徴を考慮した統⼀されたUIのデザインとそれに従ったデータ 関連APIの再設計 得られた効果 ・1画⾯で動的に遷移する処理が可能に ・1件の電話対応が平均4分から2分に短縮される Before After
  18. PLMパッケージのUI改善 (Native to Web to Native) 背景 ・既存UIが古くなり、Web化とともにデザイン改善をしたい 課題 ・画⾯の数が多く、区別がつかない。

    ・たくさんのウィンドウを開いてしまい、ユーザーが迷⼦になる ・検索条件が複雑かつカスタマイズできるけど、難しい 対応 ・ウェブのデザイン⽂法に合わせて新しいレイアウトを提⽰ ・コンテキストメニューをなくして、機能を明⽰的なUIで表現 ・⼀部の機能だけを分離し、ウェブ化してユーザーの反応を確認 ・ウェブの機能拡⼤&ネイティブアプリもウェブと同様のデザイン に変更 得られた効果(具体的な数値等は⾮公開) ・ユーザーからの⾼評価 ・他のパッケージ製品にも同様のデザインを展開 Before After
  19. 調達管理システムのUI改善 (Native to Cloud to Web) 背景 ・DXの⼀環として全社システムのクラウド移⾏ ・AzureとSharepointの機能を活⽤し、ローコードで業務システムを作成 課題

    ・外部パートナーに使ってもらうための画⾯のUXが悪いとの指摘を受けた ・しかしSharepointのListには表現の限界があり、UXの改善に限界がある ・同様の問題は他の業務システムでも発⽣する可能性がある 対応 ・実装の制限を無視して、最適のUXをデザインする ・SharepointのListなどの機能からできることとできないことを確認 ・カスタムウェブフロント実装を決め、デザインシステムで標準化する 得られた効果(具体的な数値等は⾮公開) ・ユーザーからの⾼評価 ・他の業務システムに対してもよいUXを低下で提供できる基盤ができる Before After
  20. 考慮すべき点の纏め l 異なる⽂法に注意︕ l ファンクションキーの使⽤ ⇒ 別の⼿段を提供することを検討 l 複数のウィンドウの⽴ち上げ ⇒

    避ける l コンテキストメニュー(右クリック)を多⽤している ⇒ 避ける l 巨⼈の肩に乗る l 対象プラットフォームの有名デザインガイドラインを参照する l 既存システムからの制限を元に、どれに対応できるか確認 l できるだけ、最新のデザインガイドラインに準拠するようにする。 l ⾞輪の再発明を避ける l 3rd PartyのUIライブラリーを検討する(カスタマイズは必須)
  21. 考慮すべき点の纏め l IAはとても⼤事︕ l データを適切にグルーピングする l ⽤語・表現を⾒直す ⇦ 最も安価で有効なUX改善⽅法の⼀つ︕ l

    デザイン改善の⽬的を明確に l 定義されていない問題は解けない l 問題定義を間違えると回答も間違える l 継続は⼒也 l デザインガイドラインと再利⽤できるU部品を作成する ⇒ デザインシステムを作成 l フロントチームを別途設けることを検討する(デザイナーを含める)
  22. 今⽇の内容のサマリー l プロジェクトの観点から l ⽬的と要件を明確に l 上記から、UX要件を明確にする l 技術的制約を確認し、採⽤できる外部ライブラ リーなどの選択を慎重に

    l マイルストーンを定義。 l Small Startでできるか、Big Bangかを選択す る。 l Big Bangはできるだけ避ける l デザイナーとエンジニアの密なコラボを⾏える 体制を作る UX要件定義 システム要件定義 機能要件 ⾮機能要件 新しいタスクとして 認識しましょう︕
  23. 今⽇の内容のサマリー l デザインの観点から l プラットフォームに適したデザイン⽂法の置き換えを検討し、ルール化する l 既存システムのUIの理由をしっかり理解する l 単純な置き換えではなく、⽬的を考慮した最善の対応策を検討する l

    余計な機能を⾒つけて、排除する︕ l 与えられた条件の上で、使⽤可能なデフォルトのUI部品を把握し、できるだけそれ を活⽤ l カスタムUIはその必然性を検討して慎重に作成を判断 l ウェブ、モバイル、ネイティブアプリの共存を考慮したデザインにする l デザインガイドライン・デザインシステムの作成と共有を推奨 l デザインは⼀過性ではない時代。再利⽤できる部品を揃えることで、継続的な改善に 備える