2024.03.21

デザイン制約とその解決方法

井駒遥香
UXPin Inc 担当
このエントリーをはてなブックマークに追加

はじめに

みなさん、こんにちは。UXPinの井駒です。今回は「デザイン制約」についてお話しします。デザイン制約は、どんな企業規模であろうとプロジェクトとその成果に少なからず影響を与えます。このブログでは、シニアデザイナーにとって身近な課題である「デザイン制約」について掘り下げます。

また、本記事では、UXPin Mergeを使ってプロトタイピングの制約をなくし、優れたユーザー体験を提供するための方法もご紹介しますので、ぜひ最後までご覧ください!

目次

「デザイン制約」ってなに?

デザイン制約とは、デザインプロセスにおいて、内的要因や外的要因によって課される制限や制約のことです。この「制約」は最終製品に影響を与えるため、組織の全員が制約について認識し、毎回各プロジェクトの開始前にその制約についてしっかりと考えることが非常に重要です。

デザイン制約は大きく分けると以下のようなものがあります:

  • 技術的制約:製品の技術スタックとエンジニアリングのチームによるもの
  • 金銭的制約:部門予算やプロジェクト予算
  • 法規制の制約:従う必要がある法律
  • 組織の制約:文化、構造、方針、官僚主義
  • 自主規制:各デザイナーのワークフローとクリエイティブな意思決定
  • 才能の制約:デザイナーのスキルや経験、プロとしての欠点
  • プロジェクト独自の制約:時間、予算、利用可能なチームメンバーなど、プロジェクトに関連する制約

これらをさらに詳しく調べ、チームメンバーやステークホルダーのデザイン制約への対処法について見ていきましょう。

1.技術的制約

技術的な制約は、デザイナーが創造的で革新的な限界をどこまで押し広げられるかを左右するため、デザインプロジェクトに大きな影響を与えます。

以下に技術的制約の例を挙げてみましょう:

  • デバイスとOS(オペレーティングシステム)の制限:iOSとAndroidの制約、画面サイズ、処理能力など
  • アクセシビリティの制約:音声コントロールとスクリーンリーダーがデザイン決定に与える影響
  • 性能の制約:ユーザー帯域幅/インターネット接続、製品サーバー、および技術スタックの影響
  • 統合とAPI:外部サービスからの制限とAPI要件
  • 技術スタックの制約:フロントエンドとバックエンドの技術によるデザインプロセスへの影響

2.金銭的制約

金銭的制約は、人材、ツール、ユーザーリサーチ、プロジェクトスコープ、テクノロジーなど、デザインプロセスの多くの分野に影響を与えます。多くの人は金銭的制約を「障害」と見なす一方で、ブートストラッピングや回避策を通して創造的思考やデザインイノベーションが促されることがよくあります。

金銭的制約がデザインプロセスに与える影響には、以下のようなものがあります:

  • 各分野(リサーチ、ワイヤーフレーム、プロトタイピング、インタビュー、テストなど)の範囲が制限される
  • イテレーションとテストの回数が制限される
  • デザイナーが使うツールが限定される
  • デザインチームの規模とスキルレベルが決まる

3.法的および規制上の制約

法的制約は、UXプロジェクトに関してコンテンツとユーザーデータに最も影響を与えます。法律は国によって変わるため、デザイナーは法律顧問やステークホルダーからのアドバイスに頼ることになります。

法的制約がデザインに与える影響は以下のようなものがあります:

  • プライバシー法:デザイナーが収集するデータ、収集方法、ユーザーへの法的通知、許可を得る方法などを規定する法律で、特に欧州連合(EU)の一般データ保護規則(GDPR)やカリフォルニア州消費者プライバシー法(CCPA)などがある。
  • アクセシビリティに関する法律: デザイナーは、さまざまな障がいがあるユーザーのために法的に利用しやすいUI(ユーザーインターフェース)にする。(例:米国のADA(Americans with Disabilities Act :障がいを持つアメリカ人法))
  • 知的財産法:文字、画像、動画などのオリジナル作品の著作権。さらに、デザイナーは競合他社やブランドの知的財産、商標、その他の法的保護を侵していないかを考慮しなければならない。
  • 業界独自の規制:金融や医療など、プライバシーやセキュリティに関する法律があり、ログインや認証の手順など、デザインに大きな影響を与える業界もある。

4.組織的制約

組織的制約とは、会社の他の部分によってデザインに課される制約を指します。多くは組織の価値観、文化、会社のビジョン、他部門との利害の競合に関係します。

組織的制約の例としては、以下のようなものがあります:

  • 時間的制約:ステークホルダーが設定する締め切りは、デザイナーのデザインアイデアの調査やプロトタイプの作成、テストの実施法に影響を与えることがある。
  • ブランドガイドライン:組織のブランドは、スタイルやメッセージの決定に影響を与える。
  • マーケティングとビジネス目標:デザイナーは、「顧客のニーズ」と「組織の目標」とのバランスをとらなければならないことがよくある。
  • デザインシステムの制約:利用可能なコンポーネント、デザイン原則、スタイルガイド、ガイドライン、デザインシステムガバナンスは、デザイナーが製品を作成する方法に影響を与える。
  • 組織のサイロ化:連絡や連携がきちんとなされないと、進捗を妨げるサイロ化につながり、これによって重複作業、遅延、デザインドリフト、不整合、その他の摩擦につながることがよくある。
  • デザインの価値:組織がUX部門をどのように認識しているかがリソースの配分や賛同に影響を与えてしまい、デザイナーができることが制限される可能性がある。

5.自主制約

デザイナー自身の制約としては、使用するデザインツール、タスクを完了するためにかかる時間、製品のデザインシステム使用の有無など、デザインプロセス中の選択肢やオプションに関連して生じます。

6.人材的制約

人材的制約とは、デザインチームが利用できる「スキル」と「スペシャリスト」に関するものです。管理者はお互いを補い合う人材を配置できるように、各デザイナーのスキルセットと専門知識を把握しておくことが重要です。人材的制約を理解することで、管理者は適切な人材を置いたり、特定のデザインプロジェクトのために専門業者を雇うタイミングを計ったりすることができます。

7.プロジェクト特有の制約

プロジェクトの制約が、他の場合は存在しない、あるいは組織にとって稀なデザイン上の問題を引き起こします。たとえば、デザイナーは慣れた時間枠よりも短い時間枠でプロジェクトを完了しなければならない可能性があると、望ましい結果を達成するのにワークフローを適応させたり、ツールを切り替えたりすることになります。

デザイン制約  - その解決方法

多くの組織では、制約の克服はDesignOpsの仕事です。DesignOpsチームは、部門のアウトプットと組織の価値を最大化するために、このような制約や障害を軽減しなければなりません。

この問題ベースのフレームワークで、組織が抱える最大の課題からデザイン制約を克服することができるでしょう。問題ベースのアプローチでは、具体的な問題とそれに関連する制約を解決することができるため、そのインパクトが大きくなります。

  • 問題の定義:市場投入までの時間短縮や、デザイナーの生産性向上など、どのような課題を解決しようとしているか。
  • 制約の特定:この問題に関連する制約、つまり予算、資源、時間、技術的な制約などをリストアップする。
  • 制約の優先順位付け:どの制約が最も重大かを判断し、それに従って優先順位をつける。
  • ソリューションのブレーンストーミング:適切な専門家、チームメンバー、ステークホルダーと会ってソリューションのブレーンストーミングを行い、可能性があるもののリストを作る。
  • ソリューションの評価:各アイデアの長所と短所を検討し、実現可能性が最も高く、潜在的な影響が最も大きいものを決定する。
  • ソリューションの選択:最良の結果をもたらすと思われるソリューションを選択し、実施するための計画を立てる。
  • テストと反復:ソリューションの効果を測る KPI (重要業績評価指標)を作成し、結果を最適化するために時間をかけて微調整する。遠慮なく、パフォーマンスの悪いアイデアは放棄して新しいアイデアは反復する。

UXPin Mergeで制約を減らす方法

従来のデザインワークフローや画像ベースのツールは、デザイナーに多くの制約をもたらします。特にプロトタイプの忠実度や機能性は、以下のような多くの問題を引き起こします:

●    ユーザーテストの範囲が限られる
●    デザインプロセス中にユーザビリティの問題を発見できない
●    問題解決の機会が少ない
●    ステークホルダーの理解度が低く、購買意欲に影響する
●    ビジネスチャンスを特定する能力が低い
●    デザイナーとデベロッパーの連携が不十分で、デザインのハンドオフが大変。

UXPin Mergeは、製品のコンポーネントライブラリをUXPinのエディタと同期させることで上記の問題やその他の問題を解決するします。デザイナーは、エンジニアが最終製品の開発で使用する同じUI要素をデザインプロセスで使えるようになります。

Mergeコンポーネントは完全にインタラクティブで、UXPin上でもレポジトリや最終製品とまったく同じように機能します

このインタラクティブ性によって、デザインチームはコンポーネント駆動のワークフローを利用できるようになり、プロジェクト範囲が拡大し、テストと反復が大幅にスピードアップします。

デザイナーとエンジニアは共通の言語を使用することができるため、サイロや運用上の制約をなくすことができ、ハンドオフは摩擦がなく、エンジニアがすでに同じコンポーネントライブラリを持っているため、ドキュメントや説明が少なくて済みます。

さらに、JSXをレンダリングするので、エンジニアは、コピー&ペーストだけでコンポーネントのプロップに適用できます。

上記のメリットに加えて、テストにおいての制約も大幅に減ります。ユーザビリティテスト参加者とステークホルダーは、最終製品と同じようにプロトタイプを操作できるため、反復して結果を改善するための有意義で実用的な結果を得られるのです。

まとめ

いかがだったでしょうか?今回は、「デザイン制約」についてお話しし、UXPin Mergeの仕組みと優れたユーザー体験を提供する方法、プロトタイピングでの忠実度の重要性とその影響について説明しました。

UXPinを活用して、現在抱えている製品開発においての悩みや課題を解決しませんか?

ご相談やご質問がございましたら、オンラインにてご案内させていただきます。以下のリンクからお問い合わせください。

DevOps Hubお問い合わせ

関連リンク

UXPin社寄稿ブログ記事一覧

UXPin製品情報

この記事の著者:井駒遥香

UXPin Inc 担当

コードベースデザインツール「UXPin」で営業を行いながら、公式コンテンツ(ブログ、Twitter、チュートリアル動画)の運営も行っている。


DevOps Hubのアカウントをフォローして
更新情報を受け取る

  • Like on Feedly
    follow us in feedly

関連記事

このエントリーをはてなブックマークに追加

お問い合わせ

DevOpsに関することなら
お気軽にご相談ください。

Facebook、TwitterでDevOpsに関する
情報配信を行っています。