ハイテクなデジタル製品におけるUXデザインの世界でも、ペンと紙は、Lo-Fi（低忠実度）のプロトタイプをサクッと作る選択肢として今でも好まれています。皆さんの思い込みとは裏腹に、UXチームはコンピューターから離れ、付箋やホワイトボード、メモ帳に書き込んだり、紙のプロトタイプに注釈を加えたりすることに多くの時間を費やしています。

デザイナーがコンピュータに向かう前に計画や準備をすればするほど、ワイヤーフレーム、モックアップ、プロトタイプをサッとデザインすることができます。そしてペーパープロトタイプは連携を促すことから、初期の UX デザイン思考プロセスの重要な部分であり、それでデザイナーは最小限のコストで多くのアイデアを検討できるようになるのです。

UXPin を使うことで、デザインチームと開発チームは、ペーパープロトタイプから忠実度の高いプロトタイプ作成にすぐに移行でき、それでデザインプロセスは大幅に加速されます。一貫性のある高品質なデジタル体験を構築しませんか。無料トライアルにサインアップして、UXPin のプロトタイピング機能をぜひお試しください！

ペーパープロトタイプとは

ペーパープロトタイプとは、デジタル製品を表す手描きの「スクリーン」を使ってアイデアを開発し、ユーザーフローをデザインするプロセスであり、ここではインタラクションデザインよりも、ハイレベルな UX（ユーザーエクスペリエンス）のテストを行います。

ペーパープロトタイプには機能がないことから、忠実度が低いため、ペーパープロトタイプのデザイナーがペーパープロトタイプを部門外で共有することはほとんどありません。

ペーパープロトタイプは、情報アーキテクチャをマッピングしてユーザーフローを可視化することを主な目的としています。

デザインチームは、よく机の上やフローの上に紙画面を並べて、実際のユーザーがどのようにナビゲートして最終的なゴールに到達するかを想像します。そのデザインは初歩的なもので、たいていは白黒でスケッチされ、コンテンツは見出しと行動喚起のリンクだけが読みやすいテキストで表示された限定的なものです。

また、スワイプやスクロールなどの基本的な機能をシミュレートするために、チームが厚紙を使って iPhone や Android のモックデバイスを作ることもあります。このようなモックデバイスを使うことで、デザイナーは自分のデザインが携帯電話の枠内でどのように見えるかを確認することもできます。‐ これはモバイルアプリのデザインの際には特に便利です。

紙のプロトタイプの主な利点はスピードですが、UI Stencils などのツールを使って、正確で見た目に美しい画面レイアウトをデザインするデザイナーもいます。これは、紙のプロトタイプをステークホルダーやテスト参加者に提示する予定がある場合に極めて重要です。

UXPinの旅は、Web Kitという同様のペーパープロトタイピング製品から始まりました。ペーパープロトタイプを自動的にワイヤーフレームに変換するデザインツールとペアになったペーパーパッドです。そして UXPin は、エンドツーエンドのプロトタイピングソリューションへと進化し、最初から制作可能なプロトタイプを作成できるようになりました。UXPinをぜひ無料でお試しください。

ペーパープロトタイプのデジタル化

reMarkable や Apple Pencil のようなツールを使えば、チームはアナログな紙の体験のようなスピードと多様性を楽しみながら、リモートで共同作業を行うことができます。

デジタルスケッチツールを使うことで、ペーパープロトタイプのプロセスは加速されます。デザイナーは、（画面を再描画することなく）より速やかに変更を加え、詳細なメモを添付し、完成したプロトタイプを UXPin のようなデザインツールにすぐにアップロードして、忠実度の高いプロトタイプを作成したり、ワイヤーフレームを作成したりすることができます。

ペーパープロトタイプがデジタル化されることで、紙やプラスチックのゴミも減って環境にも優しいですよね 。

ペーパープロトタイプのメリット・デメリット

スピードと柔軟性は別として、ペーパープロトタイプにはメリットもデメリットもあります。

以下の無料のeBook に載っているメリット・デメリットからいくつか挙げてみましょう（英語）

メリット：

• 速やかなイテレーション：１時間以上かけて完成させたデジタルモックアップよりも、５分で完成した紙のデザインを破棄する方が簡単。
• 低コスト：紙は安く、ツールやキットが追加されても破綻しない。
• 創造性の向上：鉛筆と紙の自由さで、実験と新しいアイデアが育まれる。デザインツールはデザインプロセスにおいて重要な役割を果たすが、デザインの初期段階では創造性を阻害する可能性がある。
• チーム構築：ペーパープロトプは、クリエイティブな環境でチームが一丸となれる貴重な機会となる。ペンと紙を使って作業することで、子供のようなエネルギーが引き出され、そこから絆が生まれ、同僚との関係が強くなる。
• 習得が一番ラク：誰もがアイデアをスケッチできるため、ペーパープロトタイプはマーケティング、開発、ステークホルダーなどの他部門を巻き込むのに最適な方法となる。
• ドキュメンテーション ：ペーパープロトタイプは優秀なドキュメンテーションとなる。例えばデザイナーは、プロジェクト全体を通して参照できるように、メモやアイデアのアウトラインを作ることができる。ペーパープロトタイプは優れた UX成果物である。

デメリット：

• ユーザーの反応がない：ユーザーからのフィードバックがないため、アイデアがうまくいくかどうかを知るのは難しく、ペーパープロトタイプを参加者とテストしたとしても、フィードバックは限られたものになると思われる。
• 不正確なフィードバック：UXチーム以外では、ペーパープロトタイプの解釈が大変である可能性があり、それで正確で意味のあるフィードバックが制限されてしまう。
• 潜在的に不要：UXPinのようなラピッドプロトタイピングツールでは、ペーパープロトタイプでデザインプロセスに不必要なステップが追加される可能性がある。UXPin にはあらかじめデザインシステムが用意されているため、デザイナーは忠実度の高い要素をドラッグ＆ドロップでサッとデザインして、作業用のプロトタイプを編集することができる。

１４日間のトライアルにサインアップして、UXPin を使って紙のデザインコンセプトを最終製品のように機能する高忠実度のプロトタイプにどれだけ早く変換できるかをぜひご覧ください。

ペーパープロトタイプを作るタイミング

Google のジェイク・ナップ氏は「ペーパープロトタイプは時間の無駄だ」と言っていますが、初期段階のコンセプト作りにはペーパープロトタイプが有効だと認めています。

一度紙からデジタルに移行したら、戻る理由はありません。新機能や製品の再デザインのために、紙のプロトタイプに戻るデザイナーもいるかもしれませんが、その場合でも、紙のプロトタイプまで戻る必要はないかもしれません。

とはいえ、紙のプロトタイプは初期段階の概念化に最適です。そのスピード、簡単さ、シンプルさにより、デザイナー以外の人も含むすべてのチームが利用でき、実験と創造性を育むことができます。‐ これはデジタルキャンバスでは実現できないことですですね。

また、ペーパープロトタイプは以下には理想的です：

• ブレーンストーミングのミーティングとセッション
• 初期段階での基本的な社内ユーザーテスト

ペーパープロトタイプの作り方

ペーパープロトタイプは、製品デザインの楽しみどころです。チームメンバーがブレインストーミングを行い、アイデアをスケッチする機会ですからね。

スケッチの綺麗さを気にする必要はありません。最高の UX デザイナーでも、別に素晴らしいスケッチアーティストというわけではないですし、そもそもこれは、自身のアイデアを視覚化して創造力を引き出すことが目標です。

ペーパープロトタイプの作成には、主に以下の３ステップがあります：

１．材料を準備する

紙、ペン、マーカー、付箋、はさみなどの材料を集めます。UI（ユーザーインターフェース）のスケッチに、ホワイトボードや大きな紙を使うのもいいかもしれません。

２．インターフェースをスケッチする

基本的な画面、UI、デザインの主要な構成要素を別々の紙に描き、そのスケッチを順番に並べることで、ユーザーの流れを表現します。

３．インタラクションのシミュレーションをする

ユーザーとのインタラクションの順序でスケッチをレイアウトします。ユーザーのアクションに基づいてスケッチを手動で切り替えてユーザー体験をシミュレーションし、フィードバックを集めてデザインを直していきます。

詳しいガイドについては、UXPinのプロトタイプに関する記事をご覧ください。

ペーパープロトタイプを作るための６つのヒント

1. プリンター用紙と安い鉛筆やペンを使う。罫線やラインが引いてあるノートは、多くの場合はデザイナーがたくさんのアイデアを練るよりも、線の間に描くことに気を取られて創造性が抑制されてしまう。
2. ウォーミングアップから始める！リラックスして流れに乗るには、数枚のスケッチが必要なこともある。クレイジーエイトは、同じ画面の多くのバージョンを素早くデザインするための素晴らしいペーパープロトタイプの手法であり、これを２，３ラウンド行うと、さらに発展させるアイデアがたくさん出てくるだろう。
3. モバイル優先型またはプログレッシブエンハンスメントのプロトタイプを作成する。最小のスクリーンから始めて、ビューポートを拡大縮小しながらレイアウトを調整する（これはモバイルと Web デザインに当てはまる）。拡大は、コンテンツを優先して、モバイルに変換されない複雑なデスクトップ用のレイアウトになるのが回避されることから、縮小よりもはるかに簡単である。補足: UXPinのオートレイアウトを使うと、自動的にデザインのサイズ、フィット、塗りつぶしがされることからモバイル優先型のデザインに便利な機能である。
4. １画面（１枚の紙）につき１枚のスケッチにこだわる。ペーパープロトタイプでは、紙片を順番に配置してユーザーフローを作成する必要があり、その入れ替えや、新しい画面の追加をしたりすることから、１枚の紙の上に複数の画面があると、このスピードと柔軟性が失われてしまう。
5. アイデアが浮かんだら反復する。目標は質ではなく量であり、紙でプロトタイプのアイデアをたくさん作ると、多くの場合、最終結果を得るために各アイデアから少しずつ取り出すことになる。これは、紙を使ったレゴ セットのようなものである。
6. ペーパープロトタイプがうまくいくには、計画を立てることが重要。十分な数のペン（黒の細いマーカーが最適）、紙、はさみ、のり、付箋、インデックスカード、テープ、厚紙、その他にもプロジェクトに必要と思われるものを用意する。ホワイトボードとマーカーも、ユーザーフローの概要を共同で描くのに最適。プロのアドバイス：ペーパープロトタイプを準備する仕事は、アート＆クラフト愛好家に割り当てる。どのチームにも少なくとも１人はいて、必要なものを十分すぎるほど揃えてくれるはず。

ペーパープロトタイプのテストと発表

UX部門外でペーパープロトタイプをテストして発表することは、常に厄介です。ステークホルダーやユーザビリティの参加者は、何が起こるかを「想像」しなければならないため、訳がわからなくなったり、提示しようとしている内容から焦点がそれる可能性があります。とはいえ、Jakob Nielsen の調査によると、ユーザビリティの問題の７５%は、ペーパープロトタイプのようなシンプルで忠実度の低いプロトタイプで特定できることが分かっています。

ペーパープロトタイプを発表してテストするためのヒントを以下に挙げてみましょう：

• 発表者以外の１人を「人間コンピュータ」または製品シミュレータ役に指名する：人間コンピュータ役の人は、スクロール、スワイプ、さまざまな画面への移動、その他の機能のシミュレーションをする。
• リハーサル：プレゼンターとシミュレーターが同期できるように、リハーサルは非常に重要。発表者は、シミュレータがプレゼンテーションに追いつくための適切なリズムを考案するといいかもしれない。
• 標準的なユーザビリティテストのベストプラクティスに従う – 「最低５人のユーザーを使ってテストを記録する」などの標準は、現在も適用されている。ユーザビリティの標準と実践方法に関する詳細については、当社のユーザビリティ・テスト・ガイド（無料）をこちらからダウンロード可能（英語）。
• ユーザーに紙のプロトタイプを渡して検査させる場合は、どこに注目して何をテストすべきかがわかるように、ガイダンスと注釈を必ず提供する。

UXPin でのプロトタイプ

モバイル アプリケーションを構築する場合でも、新しい Web サイトを構築する場合でも、UXPin でデザイナーは高度なプロトタイプを構築するためのツールを得られます。‐ 大抵の主要なデザインツールではこれができません。

でも本記事を鵜呑みにせず、１４日間の無料トライアルにサインアップして、次のプロジェクトでは UXPin の強力なプロトタイピング機能をぜひ実際にお試しください。

The post ペーパープロトタイプ： １０分でわかる実践ガイド appeared first on Studio by UXPin.

デザインシステムツールは拡張や維持がしやすくなるだけでなく、導入の促進につながります。いくつかの選択肢があるなかで、自社製品に適したツールを判断するにはどのようなポイントに気をつけるべきでしょうか。

ここでは、１０年以上にわたってデザインツールに携わるUXPinが、デザイナーとエンジニア向けのデザインシステムツールを７つご紹介します。

デザインシステムからUXPinにコンポーネントライブラリを追加して、コンポーネント駆動型プロトタイピングが持つインタラクティブ性をお楽しみください。自社コンポーネントを使うことでメンテナンスは容易になり、デザインとコードの「信頼できる唯一の情報源（Single source of truth）」として開発者と共有することができます。UXPin Merge へのアクセスのリクエストはこちら。

１．UXPin

UXPinは、ゼロから作成または既存のデザインシステムを使用して、構築、成長、拡張のためのツールと機能を提供します。

デザイナーは、インタラクティブコンポーネント、アセット、タイポグラフィ、カラーを保存してデザインシステムをゼロから作成できます。デザインシステムを構築後は、組織全体で共有し、アクセス許可の設定が可能です。 これは、ガバナンスの手順やプロトコルの管理にピッタリですね。

また、デザイナーは、デザインシステムのコンポーネントやアセットをキャンバス画面にドラッグ＆ドロップするだけで、簡単にレイアウトの構築を開始でます。外部ファイルやプラグインは必要ありません。UXPinはすべてが揃っており、チームはデザインシステムのドキュメントを見るためにツールを離れる必要がないため、最大限の一貫性と効率性を得ることができます。

さらに UXPinではStorybookでホストされているコンポーネントライブラリのようなエンジニアのための外部ドキュメントへの接続も簡単です。

デザインシステムが成熟してきたら、UXPin Mergeにアップグレードしてみましょう。UXPin Mergeでは、デザイナーが完全に機能するコードコンポーネントを使ってレイアウトを構築できるように、レポジトリからUXPinのエディタにデザインシステムを同期させることができます。

Mergeを使うと、デザイナーとエンジニアは同じコンポーネントを使用できるので、デザインシステムの「信頼できる唯一の情報源（Singe source of truth）」が構築されます。また、レポジトリの更新はUXPinのエディタに自動で同期され、デザイナーに新しいバージョンが通知されます。

さらに、UXPinのバージョン管理を使って、さまざまなバージョンのデザインシステムを切り替えることができ、プロジェクトやプロトタイプにに合わせて自由に色々なバージョンを使うことができます。

２．Zeroheight

Zeroheight は、組織全体で共有可能なデザインシステムのドキュメントをホストする中心的な存在です。Zeroheightは、UXPinのようにデザイナーがライブラリから直接コンポーネントを作成するのではなく、チームメンバーがダウンロードまたはインストールする必要があるデザインファイルをあなたがホストすることができます。

Zeroheightでは、コードスニペットでStorybookからデザインシステムのコンポーネントを埋め込むことができます。

Lightning、Polaris、Stacksと同様に、左側に「メインナビゲーション」があり、右側に「目次」にあるデザインシステムでの標準的なダッシュボードレイアウトです。この馴染みやすいレイアウトによって初めて使う人でも使いやすく、チームにとってもデザインシステムから探したいものを見つける際のナビゲーションとしても役に立ちます。

また、デザインシステムでのすべてのアセットはZeroheightに保存可能です。デザインシステムチームはチュートリアルや説明向けにYouTube、Vimeo、Loom、Google Driveの動画を埋め込むこともできます。

３．Supernova

Supernovaは Zeroheightの代わりになる優れたツールです。レイアウトや機能は似ていますが、機能面で言うとSupernovaの方が少し高めです。

Supernovaの最大の特徴として、デザインデータをどんな技術スタックのコードやアセットにも自動変換できる機能があることです。また、iOS、Android、React、Angular、Flutterのようなプロダクトフォーマットにデベロッパー向けのスターターテンプレートを含めることもできるので、エンジニアは常に正しいコードとアセットを確実に持つことができます。

SupernovaのVSCodeエクステンションは、多くの人に使われているIDE（Integrated Development Environment／統合開発環境）とデザインシステムを同期することができます。デベロッパーは必要なものをすべて1か所で入手可能です。また、Supernovaといくつかのデザインツールは同期可能なため、デザイナーはファイルのダウンロードやインポートをする必要がなくなります。

４．Storybook

Storybookは、コンポーネントを１つずつ構築および保存したいエンジニアに人気のツールです。他のデザインまたは開発ツールとも統合することができ、そのうちの1つがUXPinとの統合です。

MergeのStorybook統合により、ライブラリをUXPinのエディタに同期することができ、デザイナーとエンジニアは同じコンポーネントにアクセスすることができます。

Storybookのサンドボックス環境によって、エンジニアはステートやインタラクションなどの各コンポーネントに集中しやすくなります。また、ダッシュボードのレイアウトでStorybookのコンポーネントライブラリが整理・分類できるので、必要なものを簡単に見つけることができます。

Storybookは、新しいコンポーネントについてチームやステークホルダーと話し合い、公開前に意見や承認を得ることができるコラボレーションツールです。Chromaticアドオンを使うと、ブラウザ間でのビジュアルテストを自動化でき、QAチームからのフィードバックを集めることができます。

また、Storybookでは各UIコンポーネントの基本的なドキュメントが自動作成されますが、このドキュメントは、デザインシステムのガイドライン、使用方法、原則などを含めて編集することができます。

そして、Storybookはオープンソースのツールで無料であり、包括的なドキュメントに従うだけで始められます。ご参考までに、こちらのベストプラクティスと Storybookの例をご覧ください。

５．Pattern Lab

Pattern Labは、デザインシステムのコンポーネントを構築、表示、テスト、公開するためのオープンソースのフロントエンド環境です。このプラットフォームでは、パターンやテンプレートを構築するために “stitches together UI components”（UIコンポーネントをつなぎ合わせる）という、ブラッド・フロント氏の 「アトミックデザインの原則」が使われています。

また、HandlebarsまたはTwigsマークアップでのコンポーネント構築や、別のJSONファイルを使ったバリエーションの作成ができます。Pattern Lab が要素を自動分類し、ダッシュボードスタイルのUIに表示してくれるのです。

そしてユーザーは、ダッシュボードから各要素を検査し、マークアップとCSSクラス付きHTML言語を表示できます。また、各コンポーネントにドキュメントを含めることで、ユーザーに詳細な情報とコンテキストを提供することもできます。

カスタムデザインシステム管理ツールを構築している場合、Pattern Labはカスタマイズする上で最適な出発点といえるでしょう。

６．Adobe XD

Adobe XDには、デザインシステムを管理ための機能はありませんが、Zeroheight、Frontify、Zeplinなどのデザインシステムツールと統合することができます。

UXPinのように、デザイナーはドキュメントやスタイルガイドのコンテキストや指示がなくても、デザインシステムからコンポーネントライブラリやアセットを共有することができます。

ただ、成熟したデザインシステムにAdobe XDを使う際の問題点として、「デザイン」と「開発」で別々のコンポーネントがあり、一方はコードベース、もう一方はデザイナーがXDで使う画像ベースのものという状態です。また、デザインシステムを同期および管理するために追加でツールやプラグインも必要です。

７．Design System Manager – InVision

InVisionのDSM（Design System Manager）もまた多く使われているデザインシステムツールです。DSMはダッシュボードのレイアウトや直感的なナビゲーションは SupernovaやZeroheightと非常によく似ています。

DSMはInVisionのデザインツールと同期するため、デザイナーはデザインシステムからコンポーネントをドラッグ＆ドロップでレイアウトを構築できます。UXPinのように、デザインチームは１つのツールで完結するということですね。

また、InVision Inspectで、React、Vue、Angular、HTMLなどの一般的なフロントエンドフレームワークのコードスニペットを保存でき、Inspectは、コードとステートを持つサンプルコンポーネントを表示します。

ただ、SketchやInVision Studioを使っていない場合、DSMでは制限されることがあります。DSMの無料プランでは基本的な機能しか提供されておらず、デベロッパーとの統合やバージョン管理などのデザインシステムに不可欠な機能を利用するためにはエンタープライズプランにアップグレードが必要となるでしょう。

デザインシステム管理ツールに求めるもの

デザインシステム管理ツールは、デザイナーやエンジニアのために最適なUXを提供しなければいけません。ここでは、デザインシステム管理ツールを選ぶ際に覚えておくべきポイントをいくつかご紹介します。

バージョン管理

バージョン管理は、デザインシステムに重要な機能です。チームがバージョンを切り替えられるように、デザインシステムのリリースごとに新しいファイルを作成します。そして、デザインシステムのバージョン管理には、以下のような利点があります：

• チームの準備が整い次第、最新のデザインシステムに更新できる。- ワークフローの中断を防ぐ
• チームが同じファイルで同時に作業可能
• 時間の経過に伴う変更の追跡
• 各リリースの内容のチームへの通知
• バージョン間の切り替えが可能
• 不具合を発見した際に役立つ

バージョン管理についてもっと読む：デザインのためのバージョン管理 – なぜ設ける価値があるのか？

スタイルガイド

デザインシステムは、大抵デザイナーがコンポーネントやUIデザインに使うためのスタイルガイド（通常は PDF ）から始まります。スタイルガイドは、色のHEXコード、タイポグラフィのスケール、使い方、注意点など、デザインシステムのパターンや構成要素にコンテクストや指示を与えるものです。

コンポーネントストレージ

コンポーネントのサンプルは、インタラクティブでコードスニペットが含まれているため、デベロッパーにとっては最も便利なものであり、これは、エンジニアがコンポーネントがどのように動作するかを正確に確認できるので重要です。

アセットストレージ

ロゴや画像など、デザインシステムのアセット（資産）を全てコンポーネントライブラリやドキュメントと一緒に保管し、すべてを一箇所にまとめることが重要です。

ドキュメントとガイドライン

ドキュメンテーションは、あらゆるデザインシステムの中核ともいえます。このドキュメントで、ユーザーは以下のような製品をデザインするための原則やガイドライン得られます：

• ブランドのガイドライン
• デザイン原則
• コピーガイドライン
• デザインシステムガバナンス
• デザインとコードにおけるベストプラクティス
• デザインシステムでのアクセシビリティ
• リソース
• ツール

フィードバック

どんなデザインシステムでも、バグやエラーを発見するためにチームの意見や提案を取り入れることは覚えておきましょう。デザインシステムに「問い合わせページ」や「コメント欄」があることで、フィードバックを送信することができますね。

どのデザインシステム管理ツールを選ぶべきか

ここでご紹介したツールの比較はいかがだったでしょうか？実際に使ってみて、最適なデザインシステムのツールを選びましょう。インタラクティブプロトタイピングのスピードアップ、DesignOpsの拡張、チームの連携強化でお困りの方は、ぜひUXPin Mergeをお試しください。詳しくはこちらのページにて。14日間の無料トライアルはこちらから。

The post デザインシステム 管理ツール ７選 appeared first on Studio by UXPin.

デザインシステムのガバナンスを「急成長、創造性、柔軟性を阻むもの」だと考える人もいますが、デザインとユーザビリティの一貫性を維持しながら適切に実施することができれば、デザインシステムのガバナンスはスケーラビリティと創造性を促進できるのです。

いいデザインシステムのガバナンスは、成長や利益よりもユーザーを優先させることです。また、企業文化においてもチームメンバーが従い、受け入れるガバナンスのプロセスをどのように導入するかに重要な役割を果たします。

UXチームとエンジニアリングチームのツールは、デザインシステムのガバナンスにも影響を及ぼします。UXチームは、最終製品の変更に合わせてデザインツールの更新が必要にあり、プロセスが人的エラーにさらされることになるのです。

UXPin Merge を使えば、チームは２つの別々のデザインシステムのアップデートを心配する必要がありません。UXPin Mergeは、GitレポジトリやStorybook 統合（React、Revue、Angular、Emberなどとの接続が可能）のコードコンポーネントとエディタツールを同期し、別々のデザインシステムの必要性をなくし、ヒューマンエラーを軽減しますからね。

UXPinがデザインシステムのガバナンスを強化する方法をぜひコチラからご覧ください。

デザインシステムのガバナンスとは

デザインシステムのガバナンスとは、製品のデザインシステムを維持・更新するためのプロセスやプロトコルのことです。

例えば、アプリの終了アイコンを「X」から「ー」に変えるような小さな変更であっても、何段階もの承認と実施プロセスを経ないといけません。

デザインシステムのガバナンスは、以下のような目的を果たします：

• デザインとブランドの一貫性の維持
• ユーザビリティの問題につながる誤ったデザインの決定の防止
• チームメンバーへの、創造的な思考や、変更を試みる前の手持ちのツールでの問題解決の促進
• アクセシビリティを考慮した確実なアップデート
• 組織全体への変更点の周知
• デジタル製品およびデザインドキュメントの更新

効果的なデザインシステムのガバナンスがなければ、新しいコンポーネントの編集やアップデートは、ユーザビリティの問題や矛盾を生み出して製品の評判を落とすような「無法地帯」のようになる可能性があります。

デザインシステムの維持の課題

デザインシステムの維持には多くの課題があり、どの組織でも、デザインシステムの管理者またはチームがないといけません。。

ここでは、デザインシステム維持のための一般的な課題７つと、効果的なガバナンスモデルが不可欠である理由を見ていきます。

１．社内政治

残念ながら、うまくいっているデザインシステムであっても組織内の権力闘争から逃れられるわけではありません。経営者の力を使って、デザインシステムチームの最初の決定を覆してデザインの変更の推進や阻止に働くチームメンバーがいることだってあり得ますし。

その点ガバナンスは、経営陣やその他のステークホルダーにデザインの変更とその理由を十分に伝え、賛同と承認を得やすくしてくれます。

２．複数のチームや部署からのインプットの管理

デザインシステムは、UXやエンジニアリングチームだけのものではなく、企業のデザインシステムは、製品チームやその他のステークホルダーが共有しています。

このようなインプットをすべて管理するのは、適切なガバナンスシステムがなければ大変です。

３．デザインシステムは、よく後付けやサイドプロジェクトになる。

多くの企業、特に設立間もないスタートアップ企業では、製品のデザインシステムは優先事項ではなく、UXデザイナーが暇な時や週末に行うサイドプロジェクトで、成長需要との整合性を保つために細々とやっています。

このような環境では、デザインシステムは乱用されやすく、誤ったデザイン決定が行われがちです。ガバナンスが不十分なため、UX チームがユーザビリティの問題を修正するのに変更を元に戻さなければならないといったこともよくあります。

４．お粗末なコミュニケーション

部署間、チーム間、個人間の適切なコミュニケーションがなければ、例えば２つのチームが同じ作業を別々に行うことになったり、「他の人がやっている」と思い込んで肝心のユーザビリティの変更が忘れられたりなど、デザインシステムはバラバラになってしまいます。

そこでデザインシステムのガバナンスによって、組織全体のコミュニケーションが促され、誰もが最新の情報を得ることができるのです。

５．チームメンバーの消極的な姿勢

製品のデザインシステムに難色を示すチームは、気に入った部分だけ選んで、あとは「より良いデザイン方法」を開発します。新しいメンバーや、デザインシステムの構築に携わっていない人が、「自分の方がうまくやれる」と思い込んでしまい、他の人の努力を台無しにしてしまうのです。

このような消極的な姿勢は、製品の使い勝手や一貫性に影響を与えるだけでなく、要らぬ対立を生むことにもなりかねません。

そこで抑制と均衡が複数備わっているガバナンスモデルによって、デザインシステムがチームメンバーに乗っ取られるのを防ぎます。

６．変化に対する抵抗

時にはその逆もあります。システムは今のままでいいと考え、いかなる変更も跳ね除けてしまうデザインシステムの管理者もいます。デザインシステムは決して完全なものではなく、組織の成長のために進化しなければならない、進行中の作業なんですけどね。

７．「信頼できる唯一の情報源（Single source of truth）」のジレンマ

多くの企業が、UXデザイン、プロダクト、エンジニアリングを中心としたすべての部門間で単一のデータセットを扱うという、『信頼できる唯一の情報源（Single source of truth）』のジレンマに悩まされています。

UXチームはデザインツールを使い、エンジニアはコードを使い、プロダクトチーム（技術的なノウハウが乏しい場合が多い）はパワーポイント、PDF、紙など、あらゆる種類のツールを使って仕事をします。

このようにワークフローが分散しているため、『信頼できる唯一の情報源』の維持は大変であり、全員が最新の情報を得られるようにするために、追加のスタッフやリソースが必要になることも少なくありません。ガバナンスシステムがよくても、「信頼できる唯一の情報源」のジレンマは常に付いて回る課題なのです。

世界的な決済サービスの大手である PayPal は、『信頼できる唯一の情報源』のジレンマをUXPin Mergeで解決しました。同社は、UXPin Mergeを使って、Gitレポジトリからのコードコンポーネントで内部 UI（ユーザーインターフェース）のデザインシステムを構築し、それを維持しています。

デベロッパーが新しい変更を実施すると、UXPin のデザインエディターのコンポーネントが同時に更新されるため、デザイナーとエンジニアは常に同じデザインシステムで作業することができます。

デザインシステムのガバナンス規準の確立

デザインシステムの変更や更新が必要となる主なシナリオは４つあり、そのシナリオでは、プロトタイプの作成や修正を依頼したりする前に、チームが一連の質問やテストを行う提出プロセスが必要です。

• 新要素の導入：新しい要素を追加するためのワークフローを確立することで、デザインシステムの整合性を確保しながら、各チームメンバーには追加する機会が平等に与えられます。
  
  
• パターンの推進：パターンは、「１回限りのもの」と「新しいベストプラクティス」の２種類に分類され、チームは、この新しいパターンを推進する前に、現在利用可能なものと比較してテストしないといけません。
  
  
• パターンのレビューと適応：どのデザインシステムにも、リリース前にパターンをレビューする、少なくとも２名で構成されたチームが必要です。このレビュープロセスにより、新しい要素が現在のデザインシステムの規準と実践に合致していることが保証されます。
  
  
• デザインシステムのアップデートのリリース：チームは新しいアップデートの準備ができたときにリリースするのではなく、アップデートのリリーススケジュールのきちんと作らなければいけません。厳密なリリーススケジュールを設定することで、品質保証と文書化のプロセスを正しく実行できるようになります。

このサブミットプロセスを管理するには、変更が必要なステップを全てマッピングしたシンプルな決定木の使用が効果的です。

このInayaili de León氏による優れた例では、Canonicalチームが、コンセプトからリリースまでのシンプルな決定木に従って、新しいパターンをデザインシステムに追加する方法を示します。

彼女は、デザインシステムと同様、決定木も製品の進化に合わせて更新・改良していく作業であることを認めています。

ステップバイステップのガバナンスモデル例

デザインシステム・ガバナンスのアプローチには様々な方法がありますが、ここではデザインシステムの第一人者であるブラッド・フロスト氏 にヒントを得た１０個のステップからなるプロセスをご紹介します：

１．使えるものを使う

製品チームは、現在のコンポーネント・ライブラリを使ったソリューションを見つけるためにあらゆる努力を払わなければいけません。これは、デザインシステムが十分に文書化され、誰もがアクセスできるものでなければならないということであり、現在のデザインシステムが新しい要件を満たしていない場合、チームはステップ ２に進むことができます。

２．デザインシステム（DS）チームへの連絡

製品チームはDSチームに連絡し、問題と変更案について話し合います。この場合も、DSチームと製品チームは協力して既存のソリューションを探します。デザインシステムを熟知しているDSチームは、製品チームが見落としていたものを発見することもありますが、それでもソリューションが見つからない場合、チームはステップ３に進みます。

３．その変更が単発のものなのか、デザインシステムの一部なのかの判断

製品チームとDSチームは、その修正が一度限りのもの（スノーフレーク）なのか、デザインシステムの一部なのかを判断します。通常、一度限りの変更は製品チームが担当し、デザインシステムの変更はDSチームが担当しますが、いずれにせよ、チームは変更の優先順位を決め、スケジュールを立てる必要があります。

４．初期プロトタイピング

チームが製品の変更をプロトタイプにしてテストを実施します。

５．初回レビュープロセス

DSチームとプロダクトチームは、プロトタイプとテストの結果を確認します。両チームとも異論がない場合は次のステップに進み、変更点が不足していると判断した場合はプロトタイプとテストに戻ります。

６．UX および開発テスト

デザインが最初のレビューに合格すると、UXチームと開発チームに送られ、変更が UX（ユーザーエクスペリエンス）と技術要件を確実に満たしているようにするためにさらなるテストが行われます。

７．最終確認

プロダクトチームとDSチームが再度集まり、UXと開発でのテスト結果を確認します。両チームが満足すれば、次のステップに進みます。そうでない場合は、繰り返しテストを行います。

８．ドキュメント作成とリリーススケジュール

チームは新しい変更のドキュメント化や変更履歴（例：Github）の更新、さらにリリースのスケジュール化を行います。

９．変更点のリリース：変更点のリリース、バージョン管理ガイドラインに従った製品のバージョンアップ、全チームへの通知（Slack、Asana、Trello、Githubなど）を行います。

１０．品質保証

品質保証のため、製品チームが最終的な変更点を確認します。

この１０ステップのプロセスにより、先に説明したデザインシステムに共通する７つの課題をすべて軽減できることがおわかりいただけると思います。複数の抑制と均衡により、デザインシステムはその完全性を維持しながら、変更を組織全体に伝達することができるのです。

このプロセスは、デザインシステムの多くの課題を解決しますが、抑制と均衡は人的エラーを排除するものではありません。なのでチームには、「信頼できる唯一の情報源（Single source of turh）を提供するツールが必要です。

UXPinによるデザインシステムのガバナンスの強化

UXPin Merge が、デザインとコードの間のギャップを埋めて「信頼できる唯一の情報源」を作成することで、デザイナーとエンジニアは常に同じツールで作業できるようになります。

ベクターベースの一般的なデザインツールでは、この問題は解決されず、デザイナーとエンジニアは、同じシステムを別々に更新し、同期させないといけません。

UXPin はコードベースのデザインエディターであり、Git や Storybook を介してコードコンポーネントを同期させ、プロダクトチーム、UXデザイナー、デベロッパーが同じコンポーネントで作業できるようにするものです。

最後に、プロトタイプはコードベースであるため、製品のアップデートやデザインシステムの変更に要する時間が大幅に短縮されます。

優れたデザインシステムのガバナンスを育む唯一のデザインツールをお試しになりませんか？UXPin Merge を使えば、デザインシステムを最大限に活用し、デザインコンポーネントとコードコンポーネントを全て最新の状態に保つことができますよ！

The post デザインシステムの ガバナンス とは？ appeared first on Studio by UXPin.

デザイン会社のIDEOによれば、持続可能な長期的成長や成功する製品の特徴として、有用性（Desirability）、持続可能性（Viability）、実現可能性（Feasibility）が必ずあるといいます。

 デザイン思考 のプロセスでは、最も顧客の役に立つ製品や機能性を決めるために、リサーチ、つまり「デザインレビュー」を行います。このデザインレビューがうまくいけば、競合他社が解決していない問題を特定することができ、エンドユーザーとビジネスの双方に利益をもたらすでしょう。

しかし、デザインレビューは何から始めるべきでしょうか？競合における自社の強みはどうやって見つけるのでしょうか？そして、ユーザーや組織のために実行可能なビジネスモデルかはそのように判断するのでしょう？

本記事では、 デザイン思考 を概念化する段階でのリサーチと、以下３つの重要な基準を満たすアイデアを発掘する方法について見ていきます：

• 有用性（Desirability）
• 持続可能性（Viability）
• 実現可能性（Feasibility）

UXPinは、顧客に最高のユーザー体験を提供するための、高度なエンドツーエンドのデザイン、プロトタイピング、テストツールです。無料トライアルにサインアップして、UXPinでUXワークフローとデジタル製品デザインがどのように強化されるかをぜひお試しください。

デザインにおける有用性、持続可能性、実現可能性とは

有用性、持続可能性、実現可能性とは、アイデア、コンセプト、仮説を検証し、独自の価値提案（UVP （Unique Value Proposition）とも言う）があるかどうか、それを追求する価値があるかどうかを判断する デザイン思考 の方法論です。

この３つをすべてクリアしないと、リスクやコスト、失敗の可能性が高まってしまいます。有用性、持続可能性、実現可能性は、アイデアのリスク分析手法であり、イノベーションの芯の部分を見つけるためのツールキットであるとも言えるでしょう。

この方法論を適用することで、デザインコンセプトの弱点を突き止め、さらなるリサーチを重ねたり、アイデアを破棄して次のステップに進むことができるのです。

この方法論の由来

世界的なデザイン会社である IDEO は、２０００年代前半にアイデアをテストする方法として、『有用性』、『持続可能性』、『実現可能性』という デザイン思考 の手法を概念化しました。

IDEOは、最高のアイデアは、この３つの条件が満たされたときに成功すると考えました。逆を言えば、「素晴らしいアイデア」は、これら３つの基準のうち１つでも欠けているとうまくいかないことが多いのです。

では、この３つのレンズを通して、これらの３要素がどのように組み合わされているのかをみてみましょう。

有用性

デザイナーがまずチェックしないといけないのは、有用性 です。もし製品アイデアに市場価値がなく、誰もそれを欲しがらない、必要としないのであれば、それは売れませんよね。

また、有用性を調査することで、その商品が「欲しいもの」なのか「要るもの」なのかがわかります。

例えば、以下のようになります：

• 徒歩、公共交通機関、車、相乗りなどでの通勤が必要。
• 車通勤は便利で公共交通機関よりも快適かもしれないから、車通勤したい。

要るものとは、顧客にとってなくてはならないものであり、欲しい物とは、そのニーズを満たすための、より望ましい選択肢であることが多いです。どちらも「有用性」を満たすものですが、「欲しい」や「あったらいいな」よりも、「必要」という欲求を満たすものの方が、はるかに価値があります。

有用性のある製品を見つけるには、顧客を調査して、満たすことのできるペインポイント（「欲しいもの」と「必要なもの」）を特定しないといけません。

• 製品で問題が解決される人がいるか
• 競合他社は解決策を提示しているか
• もっといい考えはあるか
• そのアイデアは何がユニークなのか、なぜ競合他社ではなくそのアイデアを選ぶ人がいるのか
• その製品でエンドユーザーはどう思うか
• その製品は、使った人が誰かに話したくなるような有用性があるか
• その製品は、一度使ったら一生手放せないようなものか

有用性を調査する場合、そのアイデアをストレステストして、修正すべきギャップを見つけるという意図があります。ギャップが埋まれば埋まるほど製品は強くなり、ステークホルダーからの厳しい質問や顧客満足度にも耐えられるようになるのです。

持続可能性

持続可能性とは、その製品がビジネスとして成立しているかどうかを示すものです。たとえ世界で最も有用性のある製品があるとしても、それが高すぎたり、利益が出なかったりすれば、それは良いビジネスモデルとは言えませんからね。

本当に持続可能な製品アイデアは、短期的にも将来的にもビジネスとして意味があり、投資に対するプラスのリターンをより早く、より長く提供できるほど、デザインアイデアの持続可能性は高くなります。

持続可能性の素晴らしい例として、いかにしてコカ・コーラが１８８６年に生み出した飲料が、今でも世界で最も消費されている飲料の 1 つであり続けられるのかが挙げられます。その初期投資は、発明者に莫大な富をもたらし、１３５年以上経った今でも株主に信じられないほどの利益をもたらしていますよね。

また、持続可能性は、社会的、環境的なインパクト、つまりデザインの倫理的な側面も重要です。そのデジタル製品は、社会にとってプラスの利益をもたらしますか？例えば２０２１年に、フェイスブックの内部告発者フランシス・ハウゲン氏は、SNS 大手の内部調査で、インスタグラムが１０代の少女たちの不安や鬱、自殺願望を生み出していることを示す文書を公開しました。

Instagramは短期的には高い経済的リターンをもたらすかもしれませんが、このティーンエイジャーへの害は長期的に持続し得るものでしょうか。また、政府はFacebook や Instagram を規制するために何ができるのでしょうか？

Facebookは、社会的な論争、罰金、訴訟を克服するためのリソースを持つ巨大企業ですが、小さな会社やスタートアップ企業は、同じような圧力に直面した場合、ほとんどが折れてしまうでしょう。

そのため、持続可能性を検討する際には、事業、顧客、社会に対する価値の提供が必要であり、以下のようなことを検討してみるといいかもしれません：

• このデザインが成立するには何が必要か
• デザインを機能する製品にするには、どのような費用がかかるか
• 新製品や新機能を構築するための設備投資はあるか
• 価格モデルはどうなっているか、また、そのビジネスは利益を上げられるか
• ROI（投資対効果）が出るまでどのくらい時間がかかるか
• その製品はサステナブルか
• その製品は社会にどのような影響を与えるか

なお、持続可能性は有用性と同様に、その製品が確実に実行可能で持続可能であるようにするために、アイデアの調査、分析、ストレステストが求められます。

実現可能性

実現可能性は、現在のリソースに注目し、予測可能な将来において製品を開発する能力があるかどうかを判断します。そしてデザイナーは、その製品がビジネスにどのような影響を与えるかを考慮しないといけません。

実現可能な要因としては、以下のようなものがあります：

• 技術的な制約
• 財務上の制約
• 製品がブランディング、マーケティング、カスタマーサポートなどに与える影響
• 想定される市場投入までの時間
• 運営能力

理想的には、利用可能なリソースを用いて、会社の現在の能力の範囲内で新製品や機能をデザインしたいものです。新製品をサポートするためにインフラを構築しないといけないとなると、リスクとコストが増加しますからね。

新製品や新機能をデザインする際に考慮したい実現可能性に関する質問として、以下のようなものが挙げられます：

• 現在のデザイン体制で、新製品を開発するための部品が揃っているか
• デザイン・開発にかかる時間はどれくらいか
• 新製品の構築や拡張に十分なプロダクトデザイナー、UX デザイナー、エンジニアがいるか？
• 技術的な制約は新しいデザインに対応できるか
• 組織は新しい人材の採用が必要か
• 組織の能力を拡張する必要がある場合、それが将来の製品にどのような利益をもたらすのか
• その製品はブランドにどのような影響を与えるのか
• 製品のリリースは、マーケティング、セールス、カスタマーサポートなど、組織の他の分野に影響を与えるか？また、そのような部門はより多くの仕事をこなす能力があるか

デザインレビューにおける「有用性、持続可能性および実現可能性」の使用

組織は、「インフラ、マーケティング、販売、カスタマーサポートなどのコストを伴う開発を行う前にデザインやプロトタイプの問題点を特定する」という目的のもと、製品デザインの初期段階でデザインレビューを実施し、特定の基準に照らしてデザインを評価します。

基本的には、組織は製品デザインの有用性、持続可能性、実現可能性を知りたいと考えています。

UXデザインレビューのテンプレートのご紹介

「有用性、持続可能性、実現可能性」の デザイン思考 の方法論を適用することで、ステークホルダーに包括的かつ客観的なデザインレビューを提示するためのインサイトとデータを得ることができます。

以下は、ステークホルダーが読みやすく、理解しやすいように、デザインレビューの説明する際に使用できるストラクチャーまたはテンプレートです。

問題：問題は簡潔に述べましょう。デザインチームとビジネスチームは、この土台から共通の理解を深めていきますからね。

システム（現状）： 問題のコンテクストを理解するために、現在のシステムがどのように機能しているかを示しましょう（既存の製品であれば）。その後、あなたの提案する経験によって、システムがどのように機能するかを示すといいでしょう。

JBTD（ジョブ理論）： デザインレビューでは、何が顧客のモチベーションを高めるのかについて、共通の理解を持つことが重要です。Tony Ulwick氏はJBTDを「市場、顧客、ユーザーニーズ、競合他社、顧客セグメントを異なる角度から観察することでイノベーションをより予測しやすく、収益性の高いものにする。」であると定義しており、これによって、顧客がソリューションをどのように「採用」または「不採用」にするかの決定方法をステークホルダーが理解するために役立ちます。

事業目的： 顧客の問題解決におけるビジネス価値とROI を述べましょう。

把握すべきメトリクス： 測定しないものは改善できません。このメトリクスによって、新製品のデザインによって生み出されるビジネスと顧客の価値を定量化できるはずです。

提案された体験： 提案内容を文章でまとめ、明確で理解しやすいものにしましょう。その場にいる人たちは、その提案があなたが以前に明確にした問題とどのように関連しているのかを理解しないといけませんからね。

提案の意味合い：その提案がビジネスの他の部分にどのような影響を与えるか、もしかしたらわからないかもしれません。製品デザインの初期段階でそれを理解するのは、有用性、持続可能性、実現可能性のバランスを取るのに重要です。

基本的なエクスペリエンスデザイン： ワイヤーフレーム、モックアップ、プロトタイプ、またはMVP（最小実行可能製品）を提示して、顧客が製品をどのように望ましいと感じるかをステークホルダーがイメージできるようにしましょう。

デザインに反映されるインサイト：このデザインを選択した理由は何でしたか？インサイトや仮説などは何でしたか？いくつかの項目を箇条書きにして思考の深さを示しましょう。

新デザインに関する仮説：

• 新しいデザインについての仮説とは
• どのようにしてこの仮説にたどり着いたのか
• この仮説を、重要だと思われるメトリクスとどのように整合させることができるか

このような仮説は、明確でテスト可能なものであるべきです。明確な合格・不合格のメトリクスでテストを行うことで、この仮説は、少しずつ前進していることを測るための強力な基礎となるはずです。

チームの協調性を重視： ステークホルダーからどのような意見が必要か？デザインレビューのテンプレートのこのセクションによって、製品の成功の鍵を握るステークホルダーのために、明確なコンテクストと焦点を設定できます。

UXPinにあるデザインライブラリを使って、忠実度の高いプロトタイプやMVP を手短に構築し、デザインレビューの際にステークホルダーに提示することができます。無料トライアルにサインアップして、早速 UXPinプロトタイプ第１号を作成しましょう！

The post デザイン思考 における「有用性、持続可能性、実現可能性」とは appeared first on Studio by UXPin.

 ユーザビリティテスト は、デザイン思考のプロセスにおいて重要な役割を果たします。UX チームにとって、問題を解決しようとしている人達に自身のソリューションを発表する機会であり、緊張と興奮を伴う経験です！

UXPin は、世界で最も洗練されたプロトタイプと ユーザビリティテスト のデザインツールです。UXPin と Merge の技術を使うことで、デザイナーは、完全にインタラクティブですぐに使用できるコード コンポーネントを使って、最終製品の機能を備えた忠実度の高いプロトタイプを作成できます。UXPin で正確なテストと有意義な参加者のフィードバックが得ましょう。１４日間の無料トライアルにサインアップして、UXPin の高度なプロトタイプとテストをぜひご体験ください！

 ユーザビリティテスト とは

ユーザビリティテスト（「ユーザビリティ調査」とも呼ばれる）は、実際のユーザーを使って UI（ユーザーインターフェース）やフローをテストします。その際に UX リサーチャー（モデレーターまたはファシリテーター）は、参加者の行動や振る舞いを観察しながら、（通常はデジタル製品のプロトタイプ上で）一連のタスクを完了するよう依頼します。

モデレーターは、UX リサーチャーがプロトタイプを使う際に、その人がどのように考え、感じているかを理解できるように、参加者の考えや行動の言語化をお願いする可能性があります。

UXチームが ユーザビリティテスト を実施する理由

ユーザビリティテストは、UX チームに、以下のような貴重なフィードバックとユーザーインサイトをもたらします：

• ユーザーの問題解決に向けたデザインコンセプトの検証
• 修正すべきユーザビリティの問題の露呈
• 改善の機会の発掘
• ユーザーについての更なる理解

ユーザビリティテストは、テスト、問題の露呈/ユーザーについての学習、調整、再テストを繰り返すプロセスです。

また、エンジニアが開発プロセスを開始するデザインハンドオフまでに、プロトタイプを可能な限り修正改善することを最終目標としています。

「 ユーザビリティテスト 」と「UX テスト」

「ユーザビリティテスト」と「UX（ユーザーエクスペリエンス）テスト」の違いについては、よく混乱や議論が見られます。この用語は、異なる分野のテストを指すため、同じ意味で使うのは正しくありません。

•  ユーザビリティテスト ：UI、ナビゲーション、マイクロインタラクションなど、製品の使いやすさと性能のテスト
•  UX テスト ：デジタル製品を使用する際のユーザーの楽しさや満足度のテスト

この２用語の定義は異なりますが、UX リサーチャーは【ユーザビリティ】と【UX（ユーザーエクスペリエンス）】 を同時にテストします。

例えば、ある UX リサーチャーは、ユーザビリティ調査（ユーザビリティテスト）で参加者がどのようにタスクを完了するかを観察し、別のリサーチャーは、ユーザーの行動や振る舞いを研究します（UX テスト）。

この２つは、製品テストの際に考慮すべき重要なメトリクスです。ユーザーがあるタスクを完了できれば、UX デザイナーはこれを「よくできた」と思うかもしれませんが、その過程でもしユーザーが不満を抱いていたとしたらどうでしょう。より優れた UX を持つ競合製品に乗り換えられてしまう可能性がありますよね。

 ユーザビリティテスト の種類

ユーザビリティテストの方法は、主に以下の２つがあります：

• モデレートテスト
• 非モデレートテスト

UX チームは、この２つの方法をリモートおよびユーザビリティラボ （対面）テストに適用することができます。

モデレート

モデレートのユーザビリティテストでは、ファシリテーターが参加者と対話し、観察したり質問したりしながらタスクを完了するよう依頼します。

また、UXチームは、ラボや Zoom、Skype、または専用のテストツールを使ってリモートでユーザビリティ調査を実施できます。

利点：

• 参加者がタスクを理解し、正しく完了することを保証する。
• 参加者の行動、反応、振る舞いについて質問するなど、参加者と関わることができる。
• 上記のポイントは、UX チームに正確で有意義なフィードバックをもたらす。

欠点：

• 会場探し、参加者、チームスケジュールとの調整、機材の手配など、多くの計画が必要。
• より多くのリソースを必要とするため、テストのコストが上がる。
• コストや時間的な制約から参加者が限られる。

非モデレート

モデレートされていないユーザビリティテストでは、ファシリテーターは不在ですが、参加者に一連のタスクを完了するように指示を与えます。

参加者は、ラボ環境、フィールド（ユーザーが製品を通常使用する場所）、またはリモートでタスクを完了する可能性があります。

利点：

• リサーチャーは複数の参加者を同時にテストできる
• 少ないリソースで、モデレートされていないテストが大幅に安くなる

欠点：

• 被験者がガイダンスなしにタスクや指示を理解することに依存するため、タスクが完了しなかったり、テスト結果に一貫性がなかったりする可能性がある。

 ユーザビリティテスト の方法

カードソーティング

カードソーティングは、要素の階層性をテストし、情報アーキテクチャを確立するための初期段階のユーザビリティ手法です。

モデレーターは、参加者が仕分けできるように、トピックまたはカテゴリのグループを（通常は重要度別または関連性別のグループ）を提示します。

ペーパープロトタイプ

ペーパープロトタイプは、UX チームがユーザーフローや情報アーキテクチャをテストする、初期段階のユーザビリティ手法のひとつです。

ちなみに、ユーザビリティテストには費用がかかり、ペーパープロトタイプでは有意義なユーザーフィードバックが得られないことから、UX チームが参加者とともにペーパープロトタイプをテストすることはほとんどありません。

ただし、ペーパープロトタイプは、ユーザーのナビゲーションの期待値を知る上で、何らかのヒントを与えてくれます。

デジタル Lo-Fi プロトタイプテスト

デジタル Lo-Fi プロトタイプでは、一連のワイヤーフレームを使ってユーザーフローとシンプルなナビゲーションをテストしますが、ペーパープロトタイプと同様、Lo-Fi プロトタイプでは UX に関する限られたフィードバックしか得られません。

Hi-Fi プロトタイプテスト

高忠実度（Hi-Fi）プロトタイプをテストすることで、UXチームは正確で有意義なフィードバックが得られます。また参加者は、最終製品の完全に機能するレプリカを使ってタスクを完了します。

デザイナーは UXPin Merge で、「デザイン要素」を「最終的な製品の機能を備えた忠実度の高いプロトタイプを作成するためにデベロッパーが使うインタラクティブなコンポーネント」とつなぐことができます。コードコンポーネントでデザインすることで、参加者は他のどのデザインツールよりも優れたUXPinプロトタイプと対話することができるのです。

UXPin の１４日間無料トライアルでユーザビリティテストを試してみませんか？

クリックトラッキング（クリックの追跡）

クリックトラッキングは、ユーザーがプロトタイプのどこをクリックやタップしたかを調査するものであり、UX デザイナーはこの情報を使って、参加者が最も頻繁にクリック又はタップする場所を確認することができます。

また、クリックトラッキングで、リンク構造の検証や、参加者がボタンや CTA（Call To Action）を簡単に識別できるかどうかを確認できます。

アイトラッキング（目線の追跡）

UXリサーチャーは、アイトラッキング装置を用いて、参加者が UI をどのように探索するか、あるいはどの要素が最初に目に留まるかを調べます。このような知見によって、UX デザイナーは画面レイアウトの優先順位や CTA の配置を決めることができます。

 ユーザビリティテスト を６つのステップで成功させる方法

ユーザビリティテストでは、計画と目標を持つことが極めて重要です。計画と目標がないと、UX リサーチャーは何をテストすればいいのか、テスト結果の価値は何なのか知る由もないですからね。

そこで、ユーザビリティテストを以下のような簡単な６ステップに分けてみました：

1. 目標の確定
2. テストの選択
3. ユーザータスクの作成
4. リサーチ計画書の作成
5. テストの実施
6. レポート原稿の作成

１：目標の確定

最初のステップは、ユーザビリティ調査の目標の確定です。この目標は、例えば、以下のような大まかな質問や具体的な質問を投げかけます：

• 大まかな質問：どのチェックアウト法がユーザーの完了が一番速やかになるか
• 具体的な質問：ボタンをアニメーション化するとクリック率が上がるか

例えば、eコマースのチェックアウトフローのテストや、新規ユーザーの登録プロセスのテストなど、ゴールに優先順位をつけて、答えたい特定の質問に限定してテストを行うことが重要です。

ユーザビリティテストのセッションを最大限に活用し、できるだけ多くのフィードバックを得たいところですが、それではユーザーの疲労や不正確な結果を招きかねません。

２：正しいテストの選択

何をテストしたいのかが分かれば、適切なユーザビリティテストの方法を選ぶことができます。

ちなみに、無料のEブックである『The Guide to Usability Testing（ユーザビリティ・テストガイド）』では、３０種類のユーザビリティテスト手法の概要が説明されており、どの手法をいつ適用すればいいのかが解説されています。

そこでは、ユーザビリティテストは以下の４つのカテゴリーに分類されています：

• 説明付き：設定された指示に基づき、具体的な目標や個別の要素で、ユーザーの製品との対話を分析する。(例：ツリーテスト、廊下テスト、 ベンチマークテスト)
  
• 非文脈化：予備的なユーザーテストやユーザーリサーチ（ユーザーテストとユーザビリティテストの違いを参照）に最適。必ずしも製品に関わるものではなく、一般的で理論的なテーマを分析し、アイデアの創出や幅広い意見を対象とする。(例：ユーザーインタビュー、アンケート、カードソートなど）
  
• 自然（または自然に近い）：リサーチャーは、ユーザーが製品を最も頻繁に使う環境においてユーザーを分析する。このテストでは、ユーザーがどのように行動するかを調べ、それによって、コントロールの代償としてユーザーの感情を正確に把握できる。(例：フィールドテスト、日記テスト、A/Bテスト、ファーストクリックテスト、βテスト）。
  
• ハイブリッド：従来の方法を捨てて、ユーザーのメンタリティを特徴的にとらえる。(例：参加型デザイン、短時間暴露記憶テスト、形容詞カード）。

テスト方法を選択したら、チームと共有し、目標と戦術をユーザビリティ計画書にまとめます。

３： ユーザータスクの作成

ユーザビリティテストでは、質問や言い回しなど、参加者に提示するものすべてが、参加者の反応に影響します。

ユーザビリティのタスクには、オープンなものとクローズなものがありますが、テストでは、その両方をうまく組み合わせる必要があります：

• クローズ：解釈の余地が少なく、例えば「12人収容できる会場を探す」というような、成功か失敗かが明確に定められた問題が与えられ、定量的で正確なテスト結果が得られる。
• オープン：参加者にはオープンタスクをこなす方法がいくつかある。例えば「お友達は Optimal Workshop（ユーザー調査のプラットフォーム） のことを話しているけど、あなたは使ったことがないみたいだから、どのように機能するのか調べてみてましょう。」といったような『サンドボックス』スタイル（プログラムがシステムの他の部分に悪影響を及ぼすことのないように設計された環境）のタスクであり、 定性的で、時には予想外の結果を生み出す。

また、モデレーターは、偏った考えを与えないように質問の言い回しに気を配る必要があります。

例えば、あるECストアで、ユーザーが母親へのプレゼントをどのように見つけるかを知りたいとします。もし、「当店で母の日のギフトを検索していただけますか」というような質問をすると、参加者が自然な直感に従うのではなく、検索機能を使うことを示唆することになるかもしれません。それに、この質問は、質問というよりも、指示のように聞こえますね。

なのでこの質問は、「当店での母の日ギフトはどのように探しましょうか。」という言い方がいいかもしれません。

４： ユーザビリティ 調査計画書の作成

ユーザビリティ調査計画書は、以下の７項目がないといけません：

1. 背景：ユーザーリサーチに至った理由や経緯について、一段落で記述する。
2. 目標：この研究で何を達成したいかを箇条書きでまとめる。目標は客観的かつ簡潔に。例えば「新しいチェックアウトプロセスがユーザーにどのように好まれているかをテストする 」ではなく、「新しいチェックアウトプロセスが初めて利用するユーザーのコンバージョンにどのように影響するかをテストする 」と書く。
3. 質問：この研究で答えてほしい質問を５〜７個程度挙げる。
4. 戦術：UXリサーチャーがテストを行う場所、時間、方法。この特定のテストを選択した理由を説明する。
5. 参加者：行動特性など、研究しているユーザーのタイプを記述する。ペルソナを添付して、さらにコンテクストを深めることもできる。
6. タイムライン：募集開始日、テスト開始・終了日時、ステークホルダーが結果を期待できる時期。
7. テスト説明 ：スクリプトが準備されている場合は、スクリプトを含めておく。

ステークホルダーからの提案やフィードバックを促し、確実に全員が納得して見落としがないようにしましょう。

さらに読む ： The Plan That Stakeholders Love: The One-Pager.（ステークホルダーに愛されるプラン： ワン・ページャー（１ページでまとめられたもの））

５：テストの実施

以下は、ユーザビリティテストを実施するタイミングです：

参加者が快適に過ごせるようにする： 参加者に、自分の能力ではなく、製品をテストしているのだということを再度確認しましょう。事前に説明を作成することで、モデレーターの指示、フェイズ、トーンに一貫性を持たせることができます。

干渉しない ：偏見を避けることができ、予測していなかったユーザー行動のインサイトを明らかにできるかもしれません。有意義なインサイトは、予想もしなかった方法で参加者が製品に接することから生まれます。人間の自然な行動を観察し、それが機能改善のインスピレーションになるようにしましょう。

セッションを記録する：チームは、後からユーザビリティ研究を見直す必要があるかもしれませんからね。

連携：レインボー・スプレッドシート（一瞬で色分けできるスプレッドシート）を使用して、各ユーザビリティ・テストの解釈を記録するといいでしょう。UXリサーチャーは、メモを比較して、共通する観察事項やユニークな観察事項を確認することができます。ちなみに、レインボースプレッドシートは、我がチームが Yelp の再デザインを行った際に、ステークホルダーのために結果を要約するのに効果的でした。(出典：Rainbow Spreadsheets by Tomer Sharon　（トマー・シャロン氏によるレインボースプレッド)

６：レポートの作成

ユーザビリティ調査報告書は、結果をまとめてステークホルダーと共有するのに有効な手段です。

ここでは、ユーザビリティレポートを作成する際のポイントをご紹介します：

具体的にする：「ユーザーは適切な製品を購入できなかった」は、理由を説明していないため、あまり役に立ちません。例えば「検索バーが見つからなかったため、ユーザーは正しい商品を購入できなかった」など、UXの観点から具体的な問題を説明しましょう。

問題に優先順位を付ける：ユーザビリティの問題を分類し、優先順位を付けることで、デザインチームがどこから手をつけるべきかを把握しやすくなります。その際はナビゲーションの問題やレイアウトの問題などのレポートを分類し、優先順位に「低/中/高」がわかるカラーコードを使うことをお勧めします。

推奨事項を記載する：あとは、ステークホルダーに解決策があることを知ってもらえるように、ユーザビリティの問題を解決するためのチームの推奨事項を盛り込みましょう。

その他、ユーザビリティレポートを作成する上で考慮すべき点に以下のようなものがあります：

• 正式なユーザビリティレポート
• 内容を補足するチャート、グラフ、図
• 過去のテストドキュメント 
• テストのビデオまたはオーディオトラック

UXPinを使ったユーザビリティテスト

UXPinは、包括的なデザインおよびプロトタイピングツールです。他のデザインツールとは違い、UXPin はワイヤーフレーム、モックアップ、プロトタイプ、テストの要件を満たすための プラグイン や アプリ を必要としません。

さらに、UXPin はさらに多くの機能を備えており、プロトタイプのステートやインタラクションを利用することで、参加者の製品インタラクションを強化し、有意義なフィードバックや結果を提供することができます。

UXPin の１４日間トライアルにサインアップして、UXデザイン、プロトタイプ、ユーザビリティテストの全く新しい世界をぜひご体験ください！

The post ユーザビリティテスト とは？成功させる6つの秘訣 appeared first on Studio by UXPin.

明確に定義されたUX（ ユーザー エクスペリエンス ）戦略は、組織のミッションステートメントと同じくらい重要であり、UXチームが革新的なデジタル製品を構想・デザインする際の指針になってくれます。

本記事は、著名なデザイナーであり作家でもある Robert Hoekman Jr.（ロバート・ホークマンJr.）氏が執筆したeBook「The Field Guide to UX Strategy」を要約したものです。

 UX戦略 を改善する方法をお探しでしたら、世界最先端のコードベースのデザインおよびプロトタイピングツールである UXPin を試してみませんか？１４日間の無料トライアルにサインアップして、UXPinでより良いUX を実現しましょう。

 UX戦略 とは

 UX 戦略 は、UX の目標を製品や組織に合わせた計画です。 組織が顧客にブランドと製品の相互作用をどのように体験してほしいかを確定するため、UX デザイナーは決定を下す際に常にビジネス戦略とそのユーザーを考慮します。

企業がUX戦略を策定する際には、以下の点を考慮する必要があります：

• ブランドとの関連で、組織がどのようにUXを定めているか
• UXデザインは製品戦略とどのように整合させるか
• UX とビジネス目的の整合性
• 行動、期待、ユーザーニーズなど、定性的および定量的データから得られる詳細なユーザーペルソナ
• 市場トレンドが UX に与える影響
• 競合他社の調査
• 将来の目標に対する現在の製品パフォーマンス
• 製品の目標、目的、KPI の確定、優先順位付け、および実行
•  ユーザー 調査の手順
• 調査結果のステークホルダーへの報告

 UX戦略 の重要性

デザイン思考プロセスでは、主に ユーザー に焦点を当てますが、それは当然のことです。しかし、UXデザイン戦略がなければ、デザイナーはブランドとその目標を忘れてしまいます。そこでUX戦略が、組織とエンドユーザーをデザイナーの焦点に合わせ、製品とブランドの体験を一致させます。

UX戦略は、リサーチ、デザインプロセス、ユーザビリティテストにおいて、組織とそのステークホルダーが確実に発言できるようにします。

UX戦略は、以下の５つを行うという点で必要不可欠なものになっています。

1. UX （ ユーザー エクスペリエンス ）と UXデザインの利点について、ステークホルダーに常に最新情報を提供する
2. UXリサーチとデザインプロセスの概要を示す
3. UXの成功度の測定法を確定する
4. UXデザインの理解と重要性を組織全体に浸透させる
5. ブランドの期待と UX を一致させる

 UX戦略 はどこから始めるか

UX戦略の策定は、以下のようなデータの調査やステークホルダーへのインタビューなど、ディスカバリーのプロセスからスタートします：

• 一次ステークホルダー
• 二次ステークホルダー
• 現在の ユーザー 
• ベータテスター（実地試験）
• SME （特定領域の専門家）
• 競合するデジタル製品の ユーザー 
• 業界データ

一次ステークホルダー

「一次ステークホルダー」とは、その製品の担当者を指します。大抵のスタートアップ企業では CEO （最高経営責任者）と CTO （最高技術責任者）になりますが、より確立されたビジネスでは、関わっていかなければいけない経営幹部メンバーが複数いる場合があります。

一次ステークホルダーは大体、UX が成長、キャッシュフロー、事業価値、利益にどのような影響を与えるかを知りたいものです。

一次ステークホルダーへの質問の例：

• なぜ、この収益モデルを選択したのですか？
• UX に関する最大の懸念事項は何だとお考えですか、また、その理由は何ですか？
• うまくいっていると思う点はどこでしょうか？
• 競合製品と比較して、当製品はどうだと思いますか？
• どのメトリクスの改善を期待しますか？

プロからのヒント：一次ステークホルダーがそれぞれ何を最も重視しているかを調べ、ビジネスにおける彼らの役割に関連した質問をしましょう。これがわかれば、発見段階で有意義なフィードバックが得られます。

間接的関係者「二次ステークホルダー」

「二次ステークホルダー」とは、部門を管理し、組織の目標を実行する責任を負う人たちであり、最終的に UX に影響を与えるような企業の制約や課題を理解していることから、重要な存在になります。

二次ステークホルダーには、プロダクトマネージャー、マーケティングリード、リードリサーチャー、役員、その他製品のUX に影響を与えたり依存したりする部門のトップなどにあたります。

二次ステークホルダーにインタビューする際は、まず経営陣の期待や懸念事項を概説しましょう。そうすることで、ハイレベルな指令に沿った UX の改善方法を模索することができます。また、二次ステークホルダーのそれぞれの役割と責任、そしてそれがユーザーにどのような影響を与えるかにも注目する必要があります。

質問は、ステークホルダーの関心事に沿って行うようにしましょう。それ以外の質問は、誤解を招く情報や視点になる危険性が高いですからね。

現在のユーザー

製品がすでに存在している場合は、現在のユーザーにインタビューして、実際に使用している顧客の視点を得るといいでしょう。

このようなインタビューに対する報酬の提供は避けましょう；共有してくれるフィードバックや意見に影響を与える可能性があります。１回の電話やミーティングは２０分以内とし、最小限のやりとりにとどめるようにしましょう。

ユーザーに連絡するときは、自分の役割と、製品の改善のためにリサーチしていることを説明しましょう。

現ユーザーにインタビューする際のポイント：

• 少なくとも３人のユーザーとのミーティングを設定する。５人目あたりになると、最初の4人が言ったことと同じようなことを聞くようになりますよ。
• 他のチームメンバーを招待する。例えば、あなたがフォローアップの質問に集中している間、別のデザイナーやリサーチャーがメモを取るのを手伝ってくれるでしょう。マーケティング担当者やデベロッパーにとっても、ユーザーの背景や行動を直接理解することができるというメリットがありますよね。
• どのように製品を見つけたのか、どのような機能を最も使っているのかを尋ねることで、信頼関係を築く。
• 気持ちや好みばかりを聞くのではなく、行動についても聞いてみる。例えば、「〜の時はどう感じますか？」ではなく、「〜の時はどうしますか？」と聞くとか。「何」や「どこ」などの自由形式の質問は、「はい」「いいえ」の二者択一の質問と比べて、より有意義なフィードバックが得られますよ。
• ガイドラインとして使う質問リストを用意しておく。ただ、ユーザーリサーチやユーザビリティテストのように、台本通りにカッチリ行こうとする必要はありません。考えもしなかったようなフィードバックが出たらそこを掘っていけるような余裕をもたせておきましょう。
• 製品について話し始めたら、フォローアップの質問をたくさんする。答えは単純ではありません。もし、苦情が始まったけど終着点がなさそうな場合は、それを追ってみましょう。何が原因なのかを探るのです。好奇心を刺激するものは何でもそうしてください。

ベータテスター

既存の製品の ユーザー と比べて、ベータテスターは新製品への投資度が低ことから、ベータテスターのインタビューは、UX戦略の発見において一番大変な部分になります。

ベータテスターは、バグや新製品の機能不足に不満があるかもしれません。なので、そのような問題を乗り越えて、製品が解決しようとする実際の苦労や問題を見つけないといけないのです。

共感しましょう。 ユーザー のこれまでの使用状況、問題点、失望点、製品への要望を聞きましょう。製品体験の向上が目的であり、それは彼らなしではできないことを強調するのです。

SME（Subject Matter Expert：その領域の専門家）

SME で、複雑な市場、製品、 ユーザー データにコンテクストを与えることができます。

SMEの例としては以下のようなものがあります：

• 経験豊富なビジュアルデザイナー
• プログラミングや技術的な専門家
• 行動心理学者
•  ユーザー リサーチャー
• データサイエンティスト
• プロジェクトマネージャー
• 成功したスタートアップの創業者
• ビジネスコンサルタント

専門家へのインタビューには十分な準備をし、自社の製品、ユーザー、組織の目標に関連する質問だけをするようにしましょう。また、専門家が説明していることを明確に理解し、自社や自身が持っている物語や偏見を最もよくサポートする情報を選び出すことがないようにしましょう。

競合製品の ユーザー 

自社の競争優位性や、それがUX戦略にどのような影響を与えるかの理解が重要であり、そのためには、 ユーザー の希望や、競合他社の製品についての感想を調査する必要があります。

競合他社のレビューを読めば、ユーザーのペインポイントが手っ取り早く見つかります。競合他社のレビューを見つけるための貴重なリソースは、以下の３つがあります：

• Apple アプリストア
• GooglePlay ストア
• Trustpilot

ブラウザの拡張機能を持つ製品の場合、Google Chrome ウェブストアなどのブラウザストアもチェックしてみましょう。

自社製品との類似点を探し、よくあるクレームなどはメモしておきましょう。また、ポジティブなフィードバックをチェックして、顧客が何で喜ぶのかもみてみましょう。

業界データ

分析データと ユーザー からのフィードバックを比較することで、パターンや行動に関するコンテクストが得られます。

例えば、サインアップ時の離脱が多く、ユーザーが「サインアップフローの操作が大変だ」と言った場合、フィードバックとデータの間に明確な相関関係があると言えます。

KISSMetricsのようなイベント追跡ツールやMadKuduのような予測行動ツールで、どのようなユーザーのフィードバックが最も有意義であるかの判断ができるようになります。

UXPinでは、MadKuduを使って購入フローのユーザー行動をマッピングし、プロセスを最適化する方法を見つけ、障害を取り除いています。

 UX戦略 策定のための６つのヒント

UX戦略について何から始めればいいかよくわからない方のために、UX戦略のテンプレートを含む、無料のUXプロセスおよびドキュメンテーションテンプレート集をご用意しました。

ここでは、UX戦略策定の際に考慮すべきヒントを６つご紹介します。

１．ユーザー中心主義を貫く

UX戦略の目標設定の際は、常にユーザー重視の姿勢を崩さないこと。UX戦略は、『企業の目標をUXデザインに合わせること』がポイントであり、ユーザーを犠牲にしてビジネスを充実させる方法を見つけることではありません。

２．利益よりもユーザーを優先する

UX は常に透明であるべきです。ビジネスにおいて利益を上げるのは必須ですが、UX戦略がユーザーをさしおいて利益を優先することがないようにしましょう。例えば、サービスの解約や退会を阻止すべく、手続部分を見えにくい所に置いたり面倒くさくして、ユーザーが大変な思いをするようなことをしてはいけません。

３．企業の UXロードマップを確定する

ステークホルダーへのインタビューとユーザーへのインタビューを使って、UI （ユーザーインターフェース）デザインと UX に関する会社の長期的なロードマップを確定しましょう。

４．具体的かつ現実的な目標を立てる

UXデザイン戦略での発見を使って、以下に基づいた製品のデザインの希望を特定しましょう：

• ステークホルダーのフィードバック
• ユーザー調査
• 競合他社分析

UX戦略の目標は明確にし、大まかな目標や漠然とした目標は避けましょう。例えば「ユーザー登録数を増やす」ではなく、「ユーザー登録数を年間１５%増やす」というように具体的な目標を設定し、このような目標は、直感ではなく、きちんと実際のデータに基づく現実的なものであるようにしましょう。

５．使用状況の確定

顧客が製品を使用する状況や環境（いつ、どこで、誰が、何を、どのような理由で）を明確にしましょう。エンドユーザーとその環境について、できるだけ詳しくどんどん説明しましょう。これでデザイナーは、ユーザーと共感しながら UX を考えることができるのです。

また、CX（顧客体験）は製品だけでなく、広告、メッセージ、ポリシー、ユーザー契約、カスタマーサポートなど、他のタッチポイントにも広がっていることを忘れずに考慮しましょう。

６．戦略の見直しと更新

かつて古代ギリシャの哲学者ヘラクレイトスは、 ” 変化だけが不変である ” と言いました。この言葉は、目まぐるしく変化するテック業界や UX業界にとって、これ以上ないほど真理をついています。

できる UX戦略家は、新しいテクノロジー、市場の変化、新しい法律など、計画を混乱させる力への適応をよく考えています。

UX戦略を毎年見直して、現状の把握や、長期的な目標達成に向けて順調に進んでいるかを確認しましょう。前年の実績に基づいて、目標の更新や、新たな目標の設定もできますからね。

UX戦略の確定、ドキュメント化、実行、テストを実践で証明された手法でサポートする無料のe-Bookである「The Field Guide to UX Strategy」を忘れずにもらってください。

 UX戦略 の強化に UXPin ができること

“UXPinの理念は、デザインとエンジニアリングを融合させ、より良い、より速い製品開発の世界を実現することで、最高のユーザー体験を提供することです。“

UXPin の忠実度の高いプロトタイプは、ステート、コードベースのインタラクション、条件付き書式、変数、データのキャプチャと検証、関数などを備え、最終製品の正確なレプリカを作成することができます。

忠実度が高いプロトタイプは、最終製品と同じユーザー体験を提供するため、ユーザビリティテストを効率的に行えます。また、エラーが少なくなるため、市場投入までの時間が短縮されます。

UXPinの高忠実度プロトタイプは、デザインのハンドオフを大幅に改善します。自動化されたデザインスペック、CSS、スタイルガイド、UXPin 内でのドキュメント作成機能により、エンジニアは各プロトタイプが何をすべきかを把握でき、それによって製品チーム、デザインチーム、デベロッパーの間でよく見られる、デザインハンドオフ時のやりとりを最小限に抑えることができます。

コードベースデザインがどのように企業の UX 戦略を改善し、UX とビジネス目標に早く到達できるかを体験してみませんか？UXPinを14日間無料トライアルでお試しいただき、コードベースデザインがどのようなものかをぜひご確認ください。

The post UX戦略 初心者ガイド – 効果的な戦略のためのヒント appeared first on Studio by UXPin.

多くのプログラミング言語では、ウェブサイト、ソフトウェア、その他のデジタル製品の構築、拡張のためにパッケージが使われ、こういったパッケージにより、エンジニアは追加のコードを書いたり維持したりすることなく、プロジェクトの機能を拡張できます。

もしあなたの会社で Node.js が使われていたら、エンジニアが NPM、Node.js パッケージ、またはパッケージマネージャについて話しているのを聞いたことがあるかもしれません。本記事では、パッケージがどのように機能し、なぜエンジニアがそれを使用するのかについての基本理解のために、デザイナーの視点でこれらの用語について説明します。

UXPin Mergeは、デザイナーが完全に機能するコードコンポーネントでUIデザインができる画期的なツールを提供しています。UXPin Mergeのトライアルはこちらより。

NPM(Node Package Manager)とは

NPM（Node Package Manager）は、エンジニアがアプリケーションやWebサイトの開発に使うツールのオープンソースレポジトリです。

NPMは2種類あります：

1. オープンソースプロジェクトを公開するためのレポジトリ。簡略版：デジタル記録及び検索機能
2. レポジトリとインタラクトするためのCLI（コマンドラインインターフェース）。簡略版：ストレージ機能と通信するためのツール

パッケージマネージャ とは？

NPMを説明する前に、パッケージマネージャの基本を理解しておきましょう。パッケージマネージャはデベロッパーのためのツールキットだと考えてください。

例えば、支払いにStripeを使用するアプリケーションを構築するとします。パッケージマネージャは、あなたの製品がStripeと通信して支払い処理をするのに必要なコードをすべてインストールします。

エンジニアは、コードを書いたりStripeのドキュメントからのコピー＆ペーストの代わりに、コマンドの入力だけで、パッケージマネージャがStripeから必要なコードの依存関係をインストールします。

検索機能、API、決済、認証ツール、地図、アイコン、ホスティングなど、アプリケーション開発のためにに思いつくあらゆる機能を備えたパッケージが何百万と存在します。

NPMなどの、誰でもパッケージをアップロードしてインストールできるオープンソースのレポジトリと、アクセスが制限されたプライベートなパッケージレポジトリがあります。

コマンドラインインターフェースとは？

CLI（コマンドラインインターフェース）とは、デベロッパーがコンピュータープログラムの操作に使うテキストインターフェースのことです。このCLIを使用すると、コマンドを実行して、ソフトウェア開発に必要なバックグラウンド操作を実行できます。

NPMの場合、例えば、エンジニアはnpm installのようなコマンドにパッケージ名を続けて指定したパッケージをインストールすることができるように、CLIによってパッケージレジストリの対話ができます。

NPMレジストリ

NPMのウェブサイトは、エンジニアがパッケージについて検索したり学んだりする場所ですが、このウェブサイトは単なるレジストリであり、パッケージをホストしているわけではありません。代わりに、エンジニアはGitHub、Packagecloud、AWS CodeArtifactなどのプラットフォームを使って、パッケージをホストし配布しています。

例えば、NPM上のUXPin Merge CLIを見ると、レポジトリと関連リンクとしてGitHubが表示されています。その上に、UXPin Merge CLIとその依存関係を【 npm i @uxpin/merge-cli】とインストールするコマンドがあります。 NPM の後の “i” は “install” の省略形なので、【npm install @uxpin/merge-cli 】と入力しても、同じ結果になります。

依存関係とは？

パッケージは、エンジニアが【依存関係】と呼ぶ他のパッケージで構成されています。ちょっとわかりにくいですよね。この「依存関係」とは、プロジェクト内で異なるタスクを実行するコードのパッケージのことです。

例えば、UXPin Merge CLI は Typescript を使用しており、Typescript は UXPin Merge CLI が必要とする 41 の依存関係のうちの 1 つに過ぎませんが、依存関係として typescript パッケージが必要です。

開発依存とは？

UXPin Merge CLI の依存関係を見ると、41の依存関係と41の開発依存 (devDependenciesとも呼ばれる) があります。

• 依存関係：あるソフトウェア実行（本番）に必要なパッケージ
• 開発依存：開発段階で必要なパッケージのみ

依存関係と開発依存はnode_modulesという別のフォルダに存在するので、packages.jsonファイルとプロジェクトのコードはそれらがどこにあるのかがわかります。

package.jsonファイルとは？

そのメタデータと依存関係を提供する package.json ファイルがあります。コンピュータにプロジェクトをインストールするとき、NPM は 、依存関係と 開発依存 をインストールするのにpackage.json ファイルを参照します。

それぞれの依存関係を個別にインストールする代わりに、コマンドラインでnpm installと入力するだけです。

ホスティングプロバイダーもpackage.jsonファイルを使用して、そのサーバー上でプロジェクトの実行に必要な依存関係（開発依存を除く）をインストールします。

package-lock.jsonとは？

package-lock.jsonは、プロジェクトのビルドに使用されたパッケージの正確なバージョンを特定します。このファイルによって依存関係がロックされ、プロジェクトがインストールされるときに、最新のリリースではなく、開発中に使用されたバージョンが参照されるようになります。

エンジニアは定期的にパッケージを更新しますが、多くの場合、パッケージの動作方法が変更されます。それにより、依存関係のロックによって、プロジェクトが意図したとおりに確実に動作するようになります。

NPMの使用方法

ここでは、一般的なNPMのコマンドとその機能について説明します。

• npm init：プロジェクト用のpackage.jsonファイルが作成されます。アプリケーションを一から構築する場合、npm initはプロジェクトの重要な情報を含めるために使用する最初のコマンドの1つになり、NPMは、パッケージをインストールまたは削除するたびに、package.jsonファイルを自動更新します。
• npminstall：プロジェクトの依存関係をすべてpackage.json ファイルにインストールします。
• npminstall <package-name>：たとえば、npminstall @uxpin/merge-cli とすると、Merge CLI がインストールされるように、 NPMレジストリから特定のパッケージをインストールし、node_modules フォルダに保存します。
• npminstall <package-name> –save：NPMパッケージをインストールし、package.jsonファイルの依存関係に追加します。
• npminstall <package-name> –save-dev：NPMパッケージをインストールし、開発依存に追加します。
• npmuninstall <package-name>：プロジェクトから特定のパッケージをアンインストールします。
• npmdoctor：npmのインストールを診断し、パッケージの管理に必要なものがすべて揃っているかどうかを確認します
• npmupdate <package-name>：特定のパッケージを最新バージョンに更新します。

これらは、最も一般的なNPMコマンドのほんの一部であり、すべてのリストはNPMのドキュメントでご覧になれます。

デザイナーとしてのNPMの理解

NPMは、デザインツールのプラグインやアプリの拡張機能に匹敵する、ツールキットです。パッケージがどのように作られるのか、その裏側を知る必要はありませんが、一つや二つ知っておくと便利かもしれません。

まず、MUIやAnt Designなど、コードコンポーネントライブラリの一部は、NPMパッケージとして共有されています。

NPMパッケージとして配布されているコンポーネントライブラリはどのように探すのでしょうか。UXPinが公開しているデザインシステムのライブラリAdeleから、UXPinに取り込めるコンポーネントライブラリを探したとします。そこでShopifyのPolarisを選び、それがNPMで配布されていることがわかります。 そこで、NPMのサイトに行って、ShopifyのPolarisを探し、見つけるのです。

UXPinはMerge技術により、NPMパッケージを介してコンポーネントライブラリからUI要素をインポートすることができ、それらの要素を使って、完全に機能するプロトタイプを組み立てることができます。

UXPin Mergeは通常、デベロッパーによってセットアップされますが、開発サポートが不足している場合はMerge Component Managerを使って、コンポーネントを自分で管理することができます。

もし、デベロッパーとの連携を強化するためにプログラミングの知識を高めたいのであれば、HTML、CSS、Javascriptなどの基本的なコードの原則やコンポーネントライブラリについて学ぶ方が、デザイナーにとってはるかに有益だと思います。

UXPin Mergeで連携の強化

Mergeは、デザイナーとエンジニアが同じコンポーネントライブラリを使用することで、デザインと開発の連携を促します。

Mergeは、デザイナー用のUIキットとデベロッパー用のコードを用意する代わりに、レポジトリをUXPinのエディタに同期させ、デザインチームがコードコンポーネントを使用して完全に機能するプロトタイプを構築できるようにしています。

自社デザインシステムやMUIなどのコンポーネントライブラリを同期させることで、デザイナーはUI要素をドラッグ＆ドロップするだけでインターフェースやプロトタイプの構築ができます。UXPin Mergeをトライアルしてみたい方はこちらまで。

The post NPMと言うのは？完全ガイド appeared first on Studio by UXPin.

創業間もないベンチャー企業であれ、多国籍企業であれ、 プロダクトロードマップ は、会社の目標達成に向けてチームの足並みを揃えるのに欠かせません。

本記事では、いい プロダクトロードマップ の作成と維持に関する、製品の専門家からの貴重なヒントを、ロードマップの作成プロセスを簡素化するツールのリストも含めてご紹介します。

世界最先端のコンポーネント主導型プロトタイピング ツールである UXPin Merge を使って、製品開発ワークフローの効率化や、部門を超えた連携の強化、より速い目標達成を実現しましょう。Merge ページからアクセス権をリクエストして、今すぐ始めましょう。

 プロダクトロードマップ とは

プロダクトロードマップ は、製品のゴールとマイルストーンを示すハイレベルなガイドです。チームはそれに基づいて計画し、戦略を立てることができ、また、チームメンバーやステークホルダーに対して、何をなぜ作るのかを説明し、全員が同じ目標や目的に向かって行動できるようにします。

 プロダクトロードマップ に含むべき内容

 プロダクトロードマップ には、重要な要素がいくつかあります：

• 製品ビジョン：製品の原動力となる究極の目標
• タイムライン：ロードマップ全体を視覚的に表現したもの
• 目標またはマイルストーン：ビジョンに向けた時間拘束力のある目標
• 機能：構築しなければならないもの
• リリース：1つまたは複数の製品機能の納品
• エピック：複数の機能を包含する大規模なイニシアチブまたはプロジェクト
• KPI（重要業績指標）：進捗を把握するためのメトリクス

プロダクトロードマップの利点

プロダクトロードマップは、ビジョンとそこに到達するための方法を確定するのに欠かせないものであり、チームメンバーやステークホルダーに、現在地と次に何が来るかを伝えてくれます。

プロダクトロードマップで、チームは共通の目標に集中でき、管理者は確実にタスク、プロジェクト、新機能に適切な優先順位を付けられるようになります。また、製品の進捗とスケジュールを組織全体、特にステークホルダーの賛同とリソースの割り当て計画のために伝えることも重要です。

プロダクトロードマップの責任者

プロダクトマネージャーは、通常、プロダクトロードマップの編集と管理を担当します。また、会社のビジネス目標に沿った、適切で現実的なロードマップを作成するにはチームリーダーやステークホルダーとの連携が必要です。

プロダクトロードマップと製品戦略

製品戦略は、組織がどのようにビジョンと目標を達成するかを確定するものであり、それに対しプロダクトロードマップは、そのような目標を達成するためのステップとタイムラインの概要を示すものです。

• 製品戦略：どのように行うか
• プロダクトロードマップ：何をしなければならないか

どちらも製品ビジョンを実現するには欠かせないものですね。

うまくいくプロダクトロードマップの条件

プロダクトロードマップがうまくいくための重要な要素は３つあります。

1. 製品ビジョン
2. タイムライン
3. 機能（リリース）

先の「含むべき内容」でざっと説明したように、プロダクトロードマップには他にもいくつかの要素がありますが、この3つのうちの1つでも欠けていると効果的ではありません。

1. 製品ビジョン

良いロードマップには、チームメンバーを導き、彼らの仕事の目的を作り出すビジョンや指標が必ずあります。Muralには、製品ビジョンとビジョンステートメントの作成に関して、以下が含まれなければいけないと述べている記事があります：

• 目的意識がある
• 志が高い
• 達成可能である
• 顧客中心である
• 簡潔である
• 文書化されている

2. タイムライン

どのプロダクトロードマップにも、機能、プロジェクト、目標、マイルストーンなどのタイムラインが必要です。それは特定の開始日や終了日ではなく、時間枠（月、四半期、年など）でもかまいませんが、自身のチームが時間通りの納品を確約することが一番大事です。

3. 製品のフィーチャー

フィーチャーとは、目標やマイルストーンを達成するために、チームメンバーがタイムラインに従って何を作らなければならないかを示すものであり、通常、個々のタスクではなく、ハイレベルな目標です。

プロダクトロードマップ改善のための8つのヒント

このヒントで、よくある落とし穴を避け、プロダクトロードマップを最適化し、成功に繋がります。

1. プロダクトロードマップはシンプルに

プロダクトロードマップは、読みやすく、わかりやすいものでないといけません。細かい情報なしに、高いレベルの目標や目的が提供されることを目的としており、各機能には以下が含まれるべきです：

• 簡単な説明
• ステータス
• 優先順位
• タイムフレーム/締め切り
• 担当チーム/部署
• 見込み客

ヒント：スプレッドシートでも生産性向上ツールでも、ロードマップをデスクトップ画面の幅内に収めれば、スキャンやナビゲートが簡単になります。Asanaのこの例と同様です。

2. 現実的な目標を設定する

社員のモチベーション向上のために高い期待値を設定することは重要ですが、プロダクトロードマップは、現実的で人材のキャパシティに見合ったものでなければなりません。

3. GO（目標指向） ロードマップと連携する

プロダクトロードマップを成功させるには、複数のチーム、部署、主要なステークホルダーの連携が必要です。プロダクトマネジメントの講師、作家、コンサルタントであるローマン・ピヒラー氏は、こういった人達を集めて、GO（目標指向）ロードマップを作成するワークショップを開催することを推奨しています。

GOロードマップは成果ベースであるため、PM（製品管理者）は目標の特定や、それに応じた優先順位をつけることができます。ピヒラー氏の無料テンプレートに示されているように、GOロードマップには以下のものが示されます：

• 日付：その製品はいつ出荷されるのか
• 名前：それは何と呼ばれているのか
• 目標：どのような問題を解決しようとしているのか
• 機能：どのようなコア機能が必要なのか？
• メトリクス：目標達成をどのように確認するか

4. 機能を格付けして優先順位をつける

起業家であり、UXデザイナーでもあるクレマンス・デバイ氏は、機能の優先順位付けに以下のような格付けシステムを使用しています：

1. 痛み：苦しい、混乱、チャンス
2. 努力：小 （1）、中 （2）、大 （3）
3. ビジネスの価値： $（低） $$（中）、 $$$（高）

クレマンスは、スケーラブルな円を用いて機能がチャート化されるので、重要度の階層を視覚化し、それに応じた優先順位とリソースの割り当てを簡単に行うことができます。

5. 「ノー」を 言えるようになる

プロダクトロードマップは、「行きたくない場所」も確定しなければいけません。プロダクトロードマップ作成ソフト「Aha！」のCEOであるブライアン・デ・ハーフ氏は、製品戦略に沿わない機能やアイデアには「ノー」と言わないと、ロードマップが希薄になり、非現実的になると警告しています。

PMは、アプリ内データやサイトメトリクスなどの定量的データと、ユーザーインタビューなどの定性的データを含むユーザーリサーチによって、ロードマップの決定をサポートしなければいけません。

また、ブライアンは、他のユーザーに対応する前にメインとなるユーザーのための機能を優先させるべく、主要なペルソナと副次的なペルソナを分けることを勧めています。

6. 自身のオーディエンスを知る

ロードマップの課題は、複数のチーム、部署、顧客、社内外のステークホルダーがロードマップを読む必要があることです。この人達がみんなそれぞれ違う言語を話すと考えてみて下さい – ロードマップを彼らが理解できる言語に翻訳しなければいけませんよね。

ロードマップを1つだけ作成しても、すべての人に対応できるわけではありません。例えば顧客にはすごい機能のリリースについて説明し、ビジネスチームには成長予測と収益に関心を持たせるというように、製品開発チームのためにマスターロードマップを作成し、さまざまな対象者に対応するために色々なバージョンを作成するのがいいでしょう。

7. プロダクトロードマップツールでロードマップをシンプルにする

プロダクトロードマップの作成と管理は時間がかかるものです。ツールはタスクを自動化し、プロダクトロードマップを一から作成・管理する手間を省くことができ、結果的に皆さんの貴重な時間を節約できます。

以下は、プロダクトロードマップの構築と管理にお勧めの人気のプロジェクト管理ツールです：

• Asana
• Monday.com
• Jira
• Aha!
• Craft.io
• ClickUp

このようなツールには、いいプロダクトロードマップのテンプレートが含まれているのですぐに始めることができ、また、多くはSlack、Teams、G-Suite、Google Driveなどの他のアプリとの統合で、生産性と連携が効率化されます。

8. インプットを促す

プロダクトマネジメントは、社内のチーム、ステークホルダー、および顧客がアイデアを提出するためのチャネルの設定が必要です。Feature Upvoteのようなツールを使えば、PMは機能のアイデアを集め、チームや顧客が最も評価するものを支持（Upvote）することができます。

このようなツールで、製品チームは製品戦略と顧客の要望を一致させ、顧客のニーズを満たしながら最高のROIを実現する機能の優先順位を決定するすることができます。

UXPin Mergeによる製品納入の改善

プロダクトロードマップの作成は一つの方法ですが、プロジェクトを期限内に成功させるには、有能なチームと適切なツールセットが必要です。UXPin Mergeはデザインと開発を同期させて連携を強化し、ドリフトや不整合をなくします。その結果 エラーが減り、デザインの引き継ぎがスムーズになることで、市場投入までの時間が短縮されます。

信頼できる唯一の情報源（Single Source of Truth）

Mergeを使用すると、レポジトリからUXPinのエディタにコンポーネントライブラリを同期できるため、デザイナーとエンジニアは同じUI要素を使用でき、Vue、Ember、Angularなどの他のフロントエンドのフレームワークの場合は、当社のGit統合またはStorybookを使用してReactライブラリを接続できます。

レポジトリへの変更は自動的にUXPinのエディタに同期され、デザインチームに更新が通知されます。デザイナーはUXPinのバージョンコントロールを使ってデザインシステムのバージョンを切り替えることができ、完全なコントロールと柔軟性を提供します。

プロトタイプとテスト

デザインチームは、既製のインタラクティブなコンポーネントをドラッグ＆ドロップして、ユーザーインターフェースを構築することができます。インタラクティブ性、ステート、カラー、タイポグラフィー、その他デザインシステムによって決定されるコンポーネントのプロパティが組み込まれているため、デザイナーはゼロからデザインするのではなく、プロトタイプに集中することができます。

Merge によるプロトタイプで、製品チームやエンジニアのような非デザイナーにとってデザインプロセスがより身近なものになり、組織のより少ないリソースでのデザイン拡張が可能になります。

UXやデザインツールのスキルが限られているPayPalの製品チームは、UXPin Mergeに切り替えた後、経験豊富なデザイナーが画像ベースのデザインツールで以前行っていた作業よりも8倍速くUIを構築できるようになりました。

レポジトリへの変更は自動的にUXPinのエディタに同期され、デザインチームに更新が通知されます。デザイナーはUXPinのバージョンコントロールを使ってデザインシステムのバージョンを切り替えることができ、完全なコントロールと柔軟性を提供します。

プロトタイプとテスト

デザインチームは、既製のインタラクティブなコンポーネントをドラッグ＆ドロップして、ユーザーインターフェースを構築することができます。インタラクティブ性、ステート、カラー、タイポグラフィー、その他デザインシステムによって決定されるコンポーネントのプロパティが組み込まれているため、デザイナーはゼロからデザインするのではなく、プロトタイプに集中することができます。

Merge によるプロトタイプで、製品チームやエンジニアのような非デザイナーにとってデザインプロセスがより身近なものになり、組織のより少ないリソースでのデザイン拡張が可能になります。

UXやデザインツールのスキルが限られているPayPalの製品チームは、UXPin Mergeに切り替えた後、経験豊富なデザイナーが画像ベースのデザインツールで以前行っていた作業よりも8倍速くUIを構築できるようになりました。

TeamPasswordの、デザイナーがいない小規模なエンジニアリング チームは、ユーザビリティとUXの向上に、UXPin Mergeを使ってパスワード管理ツールのプロトタイプ作成とテストをします。

両社ともUXPin Mergeを使うことで、ワークフローの大幅な効率化と市場投入までの時間の短縮が実現され、競争力が上がっています。コンポーネント主導のプロトタイピングにより、PayPalとTeamPasswordは プロダクトロードマップ のゴールと目標を達成するためにプロジェクトの期限を守ることができました。

有意義なフィードバック

UXPin Mergeにより、デザイナーは没入感のあるダイナミックで個別化されたユーザー体験によって、最終製品を正確に再現することができます。より良いプロトタイプは、ユーザーテストやステークホルダーからよりよいフィードバックが得られるということです。

このように忠実度の高いプロトタイプを作成することで、デザイナーはデザインプロセスにおいてより多くのユーザビリティの問題や改善の機会を特定することができ、よりミスの少ない高品質のリリースが実現されるのです。

スムーズなハンドオフ（引き継ぎ）

ハンドオフは難しく、デザイナーとエンジニアの間でよく摩擦が生じることで知られています。UXPin Mergeでは、デザイナーとエンジニアが同じコンポーネントと制約を扱うため、ハンドオフがシームレスになり、ハンドオフ自体がほとんどなくなります。

エンジニアは、レポジトリからコンポーネントをコピーしてUXPinから変更点をコピーするだけで開発プロセスを始めることができ、デザイナーは、プロトタイプに注釈を付けてコンテキストとドキュメントを提供することもできます。

UXPin Merge を使用したコンポーネント主導のプロトタイピングにより、製品のユUXを向上させながら、プロダクトロードマップの目標をより迅速に達成する方法を　見つけましょう。詳細およびアクセス権のリクエスト方法については、Merge ページをぜひご覧ください。

The post チームのロードマップを改善してより良い製品を作ろう appeared first on Studio by UXPin.

ユーザー分析は、プロジェクトの基礎となる調査をもたらし、デザインチームは、この調査をデザインの決定の指針、機会の特定、ステークホルダーの賛同の獲得、共感の実践、プロジェクトのロードマップの優先順位付けに使用します。

ユーザー分析の構成要素や、結果を組み合わせて実用的なインサイトを作成する方法を理解するのは、ユーザーニーズとビジネスゴールを一致させて、好製品をデザインするのに不可欠です。

世界最先端のエンドツーエンドデザインおよびプロトタイピングツールで、正確で実用的なユーザビリティテストの結果が得られます。無料トライアルにサインアップし、コードベースのデザインが製品開発にどのような革命をもたらし、ユーザーにより良い体験を提供できるのか是非ご覧ください。

ユーザー分析とは

ユーザー分析は、人間の行動が製品デザインに与える影響を調べます。そしてUXデザイナーは、ユーザーの行動を理解し、デザインの決定を導くのに、定量的・定性的データを使用します。 

例えばUXデザイナーがコーヒー注文アプリをデザインする際に、顧客の人口統計、状況、環境、プロセス、飲料を注文するのに使うデバイスを知りたいと考えるように、リサーチチームは、ユーザーがデジタル製品をどのように使用するかを理解するのに、ユーザーフローに基づいたペルソナやユースケースを作成します。

この分析により、デザイナーは、顧客がアプリケーションを通じてコーヒーを注文するのに適した機能をデザインすることができるのです。

ユーザー分析の実施担当者

ユーザー分析を行う担当者またはチームは、組織と製品の成熟度によって異なりますが、UXデザイナー又はUXリサーチャーは通常、初期段階のユーザー分析または製品の再デザインを担当します。

確立された製品のユーザーリサーチは、大抵プロダクト・マネージャー/デザイナー/オーナーが引き継ぎ、共同作業や複雑なユーザビリティ問題の解決にUXデザイナーを参加させます。

さらに読む ：プロダクトデザイナーとUXデザイナーの違いや役割の違いについては、こちらの記事をご覧ください。

ユーザー分析を行うべきタイミング

チームがユーザー分析を行う場面は、主に3つあります：

• 新製品のデザイン
• 既存製品の再デザイン
• 既存製品の新機能のデザイン

どのような状況であれ、ユーザー分析はUXのデザインプロセスの初期に行われるのがほとんどです。デザインチームはその結果をもとに、プロジェクトの目標設定やアイデア出し、そしてデザインの決定をします。

ユーザー分析が重要な理由

ユーザー分析では、エンドユーザーのタスクやゴールに関する質問に答え、デザインや開発の意思決定の指針を示します。

この分析により、市場調査で必ずしも特定できるわけではないユーザーの心理状態、ユースケース、環境、使用頻度、競合製品との関わり方などの役割や特性を明らかにすることができます。

理由1：ユーザー分析で思い込みや偏見を排除できる

包括的なユーザー分析を行うというのは、顧客も意思決定に参加できるようなものです。ステークホルダーの指示、偏見、思い込み、社内政治、その他の要因に基づく決定ではなく、チームはユーザー調査を意思決定プロセスの指針としています。

理由2：ユーザー分析でビジネスチャンスが見つかる

ユーザー分析によって、チームは顧客のニーズとビジネス目標を一致させることができ、リサーチャーが改善点、競争力、市場ギャップ、その他の機会を探すのにもユーザー分析が使われます。

ユーザー分析の方法

ユーザー分析の手法は、2つに分類されます：

• 定量的データ：計測可能だが、行動の原因はわからない
• 定性的データ：主観的なデータだが、「なぜ 」が明らかになる可能性がある。

UXデザインでは、どのデータセットも一長一短です。1つのデータセットを使用しても、ストーリーの一部しかわかりません。なのでUXリサーチャーは、ユーザー、競合他社、市場を理解すべく、定量的データと定性的データを組み合わせるのです。

定量的データ

定量的な調査では、数字、時間、比率など、測定可能なデータが得られます。このデータは、分析者が基準値を特定し、何かが上がるか下がるかを測定できるため、比較的簡単に分析することができます。

定量的なデータは、デザイナーやリサーチャーにユーザーの属性を伝え、定性的データと組み合わせて、UXリサーチの重要なツールである「ペルソナ」を作成します。

定性的データ

UXデザインでは、定性的なデータに高い価値を置いています。測定可能なデータは重要ですが、大抵それだけでは 「なぜ 」を説明することができないのです。そこでUXリサーチャーは、定性的データを用いて、問題や機会の根本を理解します。

例えば、Google Analyticsの定量的なデータでは、eコマースのチェックアウトフローの離脱率が高いことがわかります。そこでUXデザイナーがインタビューを行うと、ユーザーはチェックアウトの長いフォームに入力することに苛立ちや負担を感じていることがわかります。

このような定性的データがなければ、チェックアウトフォームを修正するだけではなく、価格や支払い方法、送料に問題があると判断してしまう可能性があります。

ユーザー分析のアーティファクト5つ

リサーチャーやアナリストがユーザー分析を行う際に使うUXアーティファクトには、次のようなものがあります：

• ユーザーペルソナ
• ユーザーストーリー
• ユーザージャーニーマップ
• ユーザーコンテンツマトリックス
• ユーザータスクマトリックス
• タスク分析

1. ユーザーペルソナ

ユーザーペルソナは、UXの調査・分析の基礎となるものです。このUXアーティファクトは、ユーザーの属性、目標、行動、信念を1ページの文書に集約し、架空の名前とプロフィール画像でユーザーグループを代表するものです。

デザインチームと製品チームはペルソナを使用して、人間的なつながりを作り、共感を得やすくします。また、ペルソナは、共感マップ、ユーザー・ジャーニー、ストーリーボード、フローなど、他のUXアーティファクトを開発するための基盤にもなります。

2. ユーザーストーリー

ペルソナは、デザイナーに製品の対象者を明確に示し、ユーザーストーリーは、そのユーザーがどのように製品を使用するであろうかを概説します。このストーリーで、ユーザーがさまざまなタスクをこなす際の環境、モチベーション、状況、考え方を理解できるようになります。

アジャイルコーチであり、Industrial Logicのシニアコンサルタントであるビル・ウェイク氏は、ユーザーストーリーを開発する際に従うべきシンプルなガイドラインを作成しました。彼のユーザーストーリーの方法論は、”INVEST “という頭字語を用いて、1回のイテレーションでビジネスとユーザーに価値をもたらします。

• 独立（Independent）：ユーザーストーリーは、他のストーリーに依存しないよう、自己完結している必要がある
• 交渉可能（Negotiable）：ユーザーストーリーは柔軟で適応性のあるものにするため、詳細すぎる説明は避ける
• 価値あるもの（Valuable）：ユーザーストーリーは、エンドユーザーに価値をもたらすものでなければならない
• 見積もり可能（Estimable）：ユーザーストーリーに必要なリソースは見積り可能であるべきである
• 拡張可能（Scalable）：ユーザーストーリーを軽量化することで、一定の確度でタスクと優先順位付けを行うことができる
• テスト可能（Testable）：ストーリーがいつ完成したかをチームが理解できるように、受け入れ基準を説明する

ユーザーペルソナの曖昧さ解消のために、因果関係に着目してデザインされたフレームワークであるインターコムのジョブストーリもまた、ユーザーストーリーの方法論です。 インターコムによると、ジョブストーリーは実装よりもモチベーションに重点を置いているため、より実用的です。

3. ユーザージャーニーマップ

ユーザーエクスペリエンスマップやカスタマージャーニーマップともいいます。

ユーザーストーリーがモチベーションとコンテクストをもたらすのに対し、ユーザージャーニーマップは、ペルソナがタスクを完了する様子をステップごとに視覚化します。ジャーニーマップで、より価値のあるユーザー体験を生み出すためにデザイナーが最適化することができる、顧客の重要な瞬間が明らかになります。

ここでは、貴重で実用的なユーザージャーニーマップを作成するための4つのヒントをご紹介します：

• 真実を明らかにする：マッピングする体験に関する定量的・定性的データを、ユーザーリサーチで調べましょう。そしてウェブ解析、コールセンターのログ、顧客調査やインタビューなど、さまざまなソースを検討します。さらにユーザーデータを三角測量し、知識のギャップを埋めます。
• コースを描く：エクスペリエンスマップには、レンズ（チームがジャーニーを見る際のペルソナであるレンズ、すべてのチャネルのタッチポイントであるジャーニーモデル、およびマッピングプロセスから得られたデザイン原理とインサイトである結論を含める必要があります。
•  ストーリーを語る：ユーザーニーズの始め、中間、終わりを描きましょう。ストーリーに欠かせないインサイトと、「あると便利」なインサイトを明確にします。マップには、すぐに目につくものと、後から身につくもののユーザーニーズの階層がないといけません。
• マップを配布する：会議で発表したり、壁に貼ったり、印刷したりして、チームメンバーやステークホルダーの目に触れるようにします。全員がマップをレンズとして使い、顧客と同じように世界を見ることが目的です。

4. タスク分析

デザイナー、エンジニア、プロダクトマネージャー、そしてステークホルダーは、必ずしも自分が使うとは限らない製品や、馴染みのない業界を構築することがよくあります。タスク分析は、そのような問題を解決するために、インサイトとコンテキストを提供することを目的としています。

タスク分析では、ユーザーがどのようにタスクを完了させるかを調べ、以下のような詳細を確認します：

• マインドセット
• ユーザー環境
• 物理環境とデジタル環境における行動
• タスクの継続時間
• 使用頻度
• タスクの難易度

ユーザーに焦点を当てるユーザーストーリーやジャーニーとは異なり、タスク分析では、ユーザーが完了しなければならないアクティビティを分解します。

5. ユーザータスクマトリックス

複数のペルソナを分析する場合、ユーザータスクマトリックスを使用して、さまざまなタスクとメトリクスを比較することができます。このマトリックスで、タスクを重要な順にランク付けでき、デザイナーはメインの対象者の特定や、価値提案の検証、それに応じた製品ロードマップの優先順位の決定することができます。

以下のPaper Protosの例では、航空券を予約するための7つのタスクと3人のペルソナが表示されています。

このペルソナを比較すると、「旅行経路の検索」がユーザーにとって最も重要なタスクであり、「航空券を予約する前に旅行ガイド（荷物制限）を参照する」は、あるグループにとってのみ重要であることがハッキリわかります。

MailChimpのUXコンサルタントであるステファニー・トロース氏は、ユーザータスクマトリックスに対して、より結合的なアプローチをとっています。彼女のマトリックステクニックでは、行動と動機のコンテキストというレンズを通して見ることで、ペルソナとエクスペリエンスマップのより広いスナップショットがもたらされます。

彼女のユーザーマトリックスはより視覚的で、それによってチームがパターンを識別し、それに応じて優先順位をつけやすくなります。

6. ユーザーコンテンツマトリックス

コンテンツマトリックスは、既存のコンテンツがどのようにユーザーのニーズを満たしているかを可視化し、改善点を見つけ、コンテンツの更新に優先順位をつけるのをサポートします。製品のコンテンツマトリックスを分析することで、余計なコンテンツ、古いコンテンツ、つまらないコンテンツを排除できるのです。

ここでは、コンテンツマトリックスの主なメリットを4つご紹介します：

• 優先順位の鋭い認識：製品にどのようなコンテンツがあるのか（そしてなぜあるのか）を知ることで、ユーザーや製品との関連性や価値に関する質問を形成することができます。
• 運営上の制約への対応：たとえば、「ユーザーは頻繁なアプリのホーム画面の更新が必要だが、そのための技術的なリソースがないことが判明するかもしない」といったように、マトリックスを埋めていくうちに、解決策に対する新たな制約が見つかるかもしれません。コンテンツマトリックスでは、評価を促すことで、「ベストの次」の選択肢を発見し、誤った思い込みで前進することがないようにします。
• 統一言語の開発：コンテンツマトリックスにより、専門用語やスラング、その他の紛らわしい用語を避けながら、トーンと用語の一貫性を維持することができます。
• 正確なスケール感：製品のコンテンツ規模を把握することで、より適切なデザインの判断が可能になります。例えば、100画面と1,000画面のコンテンツを評価する場合、マトリックスによって製品のマトリックスを可視化し、それに応じてリソースの優先順位を決めることができます。

調査結果の優先順位の決め方

ユーザー調査と分析が完了すれば、ユーザーの全体像や、チームが解決しなければならない問題、そしてその優先順位が見えてくるでしょう。

優先順位付けマトリックスによって、チームはデザイン機能を可視化し、「必要」と 「あれば便利 」を分けることができます。多くの場合、チームは圧倒的に長い機能リストを持っており、絞り込みは困難です。

そこで、デザインの目的に優先順位をつけるためのヒントをご紹介します：

• トップタスク分析：適格なユーザーに、簡単に実行できるタスクのランダムリストを渡し、上位5つを選んでもらうことで、ユーザーにとって最も重要なものを特定することができます。
• ギャップ分析：優先順位をつけた機能を、重要度と満足度の高い順に評価してもらい、次に、公式の【重要度＋（重要度　ー　満足度）】を使って、機能の優先順位を決定します。
• 狩野モデル：ユーザーに、製品からどの機能がなくなると最も困るかを評価してもらいます。この満足度の差は、「必要な機能」と「あれば便利な機能」を示しています。
• QDF（品質機能の展開）：優先順位をつけられた仕事、または上のタスクの分析からの機能のリストから始め、これと会社からの機能のリストを組み合わせます。QFDは、ユーザーの必要性を最もよく満たす機能をランク付けします。
• パレート分析（80/20の法則）：この方法は、「必要な機能」と「あれば便利な機能」を素早く区別することができます。例えばトップタスクでの最多投票、最多収益など、機能を高いものから低いものへと並べ替え、合計し、各項目のパーセンテージを計算します。スコアが最も高い機能が、最も重要な機能です。
• 因果関係ダイアグラム：UXの問題は複雑であるため、この分析によって各問題の複数の原因を明らかにし、効果的なトラブルシューティングを可能にします。「なぜ？」と問いかけながら因果関係図を作成し、症状ではなく根本的な原因を明らかにします。
• FMEA（故障モード影響解析）：これで、特定のアクションがもたらす悪影響を理解でき、機能の追加ではなく壊れている部分の修正で、製品を改善できるケースを強調することができます。FMEAは、問題の共通性、重大性、難易度に基づいて危険優先度数を算出します。

おすすめの本：The Guide to UX Design Process & Documentation.

UXPinプロトタイプから有意義な分析結果を得よう

UXPinのコードベースのデザインツールにより、デザインチームは、最終製品のような完全に機能するプロトタイプを作成できます。コードのようなユーザーインターフェースやインタラクションを作成し、実用的なユーザビリティテストの結果やステークホルダーからの有意義なフィードバックを得ることができます。

無料トライアルにサインアップして、UXPinでエンドツーエンドのデザインプロセスを強化し、顧客に高品質なユーザー体験を提供しましょう。

The post ユーザー分析 – 質の高いインサイトを得る方法 appeared first on Studio by UXPin.

デザイナーは、製品開発プロセスを通じて多くのUXアーティファクトを作成します。こういった記録で、デザインチームは以前の作業を反復して、ステークホルダー、デザインのハンドオフ、研究開発、および将来のプロジェクトのための貴重なドキュメントを提供しやすくなるのです。

本記事では、一般的なUXアーティファクトと、各アーティファクトが次のアーティファクトをどのように導くかについてみていきます。また、チームやステークホルダーによって、どのUXアーティファクトが最も重要であるかについてもお話します。

デザインファイル、ドキュメント、コンポーネント、プロトタイプ、ワイヤーフレーム、モックアップなどのUXアーティファクトを一元化したデザインツールで管理しましょう。無料トライアルにサインアップして、UXPinの高度なコードベースデザイン機能をぜひお試しください。

 UXアーティファクト とは

UXアーティファクト（またはUX成果物）とは、デザインチームがプロジェクト中に作成する調査記録、スケッチ、デザインファイル、プロトタイプ、報告書、その他のドキュメントを指します。

 UXアーティファクト の主なメリット6点

1. プロジェクトスコープを概説し、ビジネス、ユーザー、技術の要件を確定する（UXデザイン要件文書）
2. デザインプロセスを文書化することで、デザインチームは過去の作業を反復し、重複を避けることができる
3. デザイン思考のプロセスやさらなる意思決定の指針となるリサーチを統合する
4. チームとステークホルダー間の連絡と連携を簡素化する
5. デザインチームがユーザーのニーズやペインポイントを調査・理解できるようになる
6. 新しいチームメンバーのオンボーディングのための貴重なドキュメントとなる

 UXアーティファクト 3種

問題をシンプルにすべく、この記事では、UXアーティファクトを以下を含めた5つのカテゴリーに分類しています：

• リサーチ
• デザイン
• テスト

1. アーティファクトのリサーチ

アーティファクトのリサーチには、デザインプロセスを通じたリサーチに関連するあらゆるものが含まれます。ここでは、一般的なアーティファクトのリサーチをいくつかご紹介します：

• UXデザイン要件書
• リサーチプラン
• ユーザーリサーチ
• 競合他社リサーチ
• 市場リサーチ

その中のいくつかを、より詳しく見ていきましょう。

2. ユーザーリサーチ

ユーザーリサーチのアーティファクトは、初期のデザインプロセスには欠かせないものであり、この資料でデザイナーがユーザーを理解し、人を中心としたデザインを決定できます。ユーザーリサーチのアーティファクトには、以下のようなものがあります：

• ペルソナ：ユーザーグループを表す架空の人物。 UXデザイナーに、共感と理解を集中させるための人間的な表現を提供。
• エンパシーマップ：ユーザーが問題や状況に遭遇したときに、何を考え、何を言い、何を感じるかを可視化し、ユーザーに共感するための方法。
• ユーザージャーニーマップ：ユーザーがあるタスクを完了するまでの道のりを段階的に可視化したもの。
• ストーリーボード：ジャーニーマップに似ているが、アイデアやコンセプトを視覚化するためにイラストやストーリーテリングにより重点を置いている。
• ユーザーフロー：eコマースのチェックアウトのように、ユーザーがデジタル製品を利用するまでの流れを最初から最後まで可視化したもの。

3. 競合他社リサーチ

UXデザイナーは、競合他社や市場の調査を通じて、製品の需要や機会のギャップをより広く理解することができます。競合他社リサーチの典型的なアーティファクトは、デザインプロジェクトの開始時に完了した競合他社リサーチをまとめた文書である、競合分析レポートです。

デザインアーティファクト

デザインアーティファクトは、デザイナーがデザインプロセスで作成するアーティファクトの大部分を占めると思われ、次のようなものがあります：

• スケッチ＆ペーパープロトタイプ
• ワイヤーフレーム
• サイトマップ/情報アーキテクチャの図式
• モックアップ
• プロトタイプ
• スタイルガイド

1. スケッチとペーパープロトタイプ

デザイナーは、デジタルプロセスに移行する前に、スケッチやペーパープロトタイプを作成し、アイデアを反復しています。また、デジタルワイヤーフレームやモックアップをデザインする際には、こういった紙のアーティファクトをテンプレートの参考資料として使用します。

2. ワイヤーフレーム

ワイヤーフレームは通常、デザイナーが紙からデジタルに移行する際に最初に作成するアーティファクトです。デザイナーはワイヤーフレームを使って、各ユーザーインターフェースの構造とレイアウトを決定すると同時に、低忠実度のプロトタイピングの基礎を提供します。

3. サイトマップ/情報アーキテクチャの図式

サイトマップ（情報アーキテクチャとも呼ばれる）は、各製品やウェブサイトのページと、それらのリンク方法を視覚化したものです。このような情報アーキテクチャは、デザインと開発におけるいくつかの重要な決定を導くため、必要不可欠なUXアーティファクトになります：

• プロジェクトに必要な総画面数とそのデザイン法
• 各ユーザーフローの構成法
• ボタンやリンクなど、画面間の接続に使用するUI要素の設定
• コンテンツとナビゲーションの優先順位の設定
• ヘッダーとフッターなど、ナビゲーションのリンクの配置設定

4. モックアップ

モックアップは、UIデザイン要素を含む最終製品の外観を正確に視覚的に表現したものです。これらのデザインは静的なものですが、忠実度の高いプロトタイプの土台となるものです。

5. プロトタイプ

デザイナーは、デザインプロセスを通じてアイデアを反復する際に、低忠実度プロトタイプと高忠実度プロトタイプを作成します。低忠実度のプロトタイプで、デザイナーがユーザーフローと情報アーキテクチャをテストでき、高忠実度のプロトタイプは、ユーザーテストとステークホルダーのフィードバックのための貴重なアーティファクトになります。

また、高忠実度なプロトタイプは、エンジニアが開発プロセスにおいて参考にし、各画面のレイアウトや、製品がどのように機能しなければならないかを把握するのに、このアーティファクトが使われます。

ただ、これらは忠実性や機能性に欠けるため理解しにくく、それによりデザイナーとエンジニアの間に摩擦が生じることが、画像ベースのプロトタイプの課題として挙げられます。

UXPinはコードベースのデザインツールであり、デザイナーとエンジニアが同じ言語で会話することができます。デザイナーは、UXPinのステート、インタラクション、変数、エクスプレッションなどの高度な機能を使って、コードのような忠実度と機能性を持つプロトタイプを構築できます。無料トライアルにサインアップして、UXPinがエンドツーエンドのデザインプロセスをどのように強化できるかをぜひご覧ください。

6. スタイルガイド

製品のスタイルガイドは、色、タイポグラフィー、ロゴ、ブランディングのガイドライン、その他のビジュアルおよびインタラクションデザインの指示など、重要な情報をデザイナーに伝えます。スタイルガイドは、デザイナーの一貫性の維持や、デザインドリフトの低減をサポートするため、重要なUXアーティファクトです。

製品のスタイルガイドと連動しているのが、カード、ナビゲーションメニュー、CTA（Call to Action）など、ユーザビリティの問題を解決するための部品群である「パターン・ライブラリ」です。

アーティファクトのテスト

デザイナーがデジタル製品を改善するための問題や機会を特定するための貴重なデータは、テストによってもたらされ、このようなアーティファクトには通常、製品ロードマップ、プロジェクトのKPI（重要業績評価指標）、および全体的なUX戦略のための重要なUXメトリクスが含まれます。

また、UXリサーチャーは、ユーザビリティテスト中にデータや文書を作成しますが、これは問題や機会の特定や、デザインのアイデア検証のために不可欠です。

アーティファクトのテストには、以下のようなものがあります：

• アンケート報告
• ユーザビリティレポート
• 分析レポート
• UX監査

1. アンケート報告

アンケートの結果は、通常1ページ程度の報告書になり、デザイナーはこのデータを使って、意思決定やステークホルダーへのプレゼンテーションを行ったりします。

2. ユーザビリティレポート

ユーザビリティテストは、ユーザーエクスペリエンスのデザインプロセスの重要な部分であり、各ユーザビリティテストは、具体的な問題点と修正のための推奨事項を記載したレポートが作成されます。

3. 分析レポート

デザインチームへのユーザーの行動やデジタル製品の操作方法に関するインサイトは、分析によってもたらされます。アナリストは、デザイナーが知りたいことや分析したいことに応じて、さまざまな分析レポートの作成ができます。

デザイナーは、分析レポートを使って問題や機会を特定し、調査やテスト結果を検証します。

4. UX監査レポート

「UX監査とは、既存のデジタル製品がビジネス、ユーザーエクスペリエンスやアクセシビリティの要件を満たしているかどうかを審査するQA（品質保証）プロセスである。」

UX監査レポートは、リンク切れの修正や古くなったコンテンツの交換など、実行可能な次のステップを含むプロセスをまとめたものです。

UXアーティファクトは誰が使うのか

NN Group（Nielsen Norman Group）の調査では、デザイン部門以外でUXアーティファクトを使う主なエンティティを3つ特定しています。：

• 社内のステークホルダー
• 社外ステークホルダー/顧客
• エンジニアリングチーム

社内のステークホルダー

• ワイヤーフレーム
• 高忠実度のインタラクティブプロトタイプ
• 競合分析レポート
• ユーザージャーニーマップ
• テストレポート

社外のステークホルダー

• 競合他社分析レポート
• ユーザージャーニーマップ
• テストレポート
• 忠実度の高いモックアップとプロトタイプ

Engineering Teamsエンジニアチーム

• サイトマップ
• ユーザーフロー
• スタイルガイドとパターンライブラリ
• 高忠実度のプロトタイプとモックアップ
• ワイヤーフレーム
• デザインハンドオフ文書

UXPinでの UXアーティファクト の作成、共有、管理

UXPinは、UXアーティファクトの作成、共有、管理など、デザイナーにエンドツーエンドのデザインソリューションを提供します。そのうちのいくつかを詳しく見ていきましょう。

1. ワイヤーフレーム、モックアップ、プロトタイプ

ワイヤーフレーム、モックアップ、プロトタイプのデザインは、アイデアの開発とテストには欠かせません。デザイナーは、UXPinを使ってこのようなアーティファクトをデザインし、チームメンバーと共有して連携を行ったり、ステークホルダーと共有してフィードバックを得たりすることができます。

UXPinのコメント機能では、チームメンバーやステークホルダーがデザインに対するフィードバックを提供し、デザイナーにコメントを割り当て、アクションを起こした後に「解決済」として作成することができます。

このようなアーティファクトやフィードバックを一箇所に集めることで、デザイナーはテストと反復を速やかに行い、デザインプロセスを効率化することができるのです。

2. デザインシステム

UXPinの直感的なデザインシステム機能により、チームは以下のようなプロジェクトのビジュアルデザイン要素を構築、共有、管理することができます：

• コンポーネント
• 色
• タイポグラフィ
• アセット

専任のデザイナーやDSチームは、説明／ドキュメントの追加や、チームメンバーが不正に変更できないような権限の設定など、プロジェクトのデザインシステムを管理することができます。

UXPinのデザインシステムは統合された機能であるため、追加のプラグインやアプリケーションを必要とせず、すべてを1つのデザインツールで集中管理することができます。

3. ドキュメンテーション

デザインハンドオフは、デザイナーやエンジニアにとってストレス満載の作業であることはよく知られており、デザイナーは、デザインやプロトタイプの説明のために、複数のフォーマットで複数のアーティファクトを作成することがよくあります。

UXPinはデザインハンドオフ用に最適化されているため、デザインチームはプロトタイプに関するドキュメントを作成できます。もう外付けのPDFや説明ビデオで、デザイナーに「こうすればいいんだよ」と説明する必要はありませんね。

また、UXPinはスペックモードで追加のドキュメントを自動的に作成し、それによってエンジニアは以下のようなことができます：

• プロパティの確認
• 距離測定
• スタイルガイドを読む（スターターCSSを含む）

また、エンジニアはUXPinのコメントを通じてデザイナーと連絡をとり、特定のUI要素について質問することができます。

4. プレビューとシェア

多くのデザインツールはプロトタイプやテストの機能を備えておらず、また、正確なテストには適さない限定的な機能を提供しているものもあります。

UXPinのプレビューとテスト機能により、デザイナーはボタンをクリックするだけでプロトタイプを立ち上げることができ、プレビューと共有により、リサーチャーはユーザーとテストを実施し、テスト中に素早く変更して反復することができます。

UXPinを製品設計に活用しよう

UXPinは、ユーザーにより良い体験を提供し、最も価値のあるUXのアーティファクトを一箇所で管理することができます。無料トライアルにサインアップし、コードベースのデザインが製品のデザインプロセスにどのような革命をもたらすかを是非ご覧ください。

The post 作成されるべき最も重要な UXアーティファクト appeared first on Studio by UXPin.

最近では、視覚的に美しいだけでなく、ユーザーの要求を効果的に満たすピクセルパーフェクトなUIがますます重視されるようになりました。このUIへの再注目は、この動向をサポートするツール、フレームワーク、環境の大幅な増加をもたらしました。Storybookは、UI開発をより速く、より簡単にするためのツールの1つです。

本記事では、Storybookの理解と、Storybook Argsがどう便利なのかについて簡単にお話すべく、まずStorybookについての簡単な説明とその大きな利点について述べ、それからArgsの概要とその使い方について説明します。

Storybookとは

初めての方に説明すると、Storybookとは、インタラクティブで効率的な方法でコンポーネントを作成・テストすることができる、UIコンポーネントの開発環境です。Storybookを通じて、コンポーネントライブラリを簡単に閲覧でき、各コンポーネントのさまざまな状態の確認もできます。また、デベロッパーのためのインタラクティブなデザインシステムとしても機能します。

Storybookを使用すると、さまざまな「ストーリー」を作成できます。ストーリーとは、コンポーネントを追加し、サンドボックス環境で様々なユースケースを作成・テストできる場所です。ストーリーブックでは、小さなスタンドアロンコンポーネントから、Webアプリケーションの複雑なページまで作成できます。

Storybookには、UIデザインプロセス全体の学習、実装、テスト、文書化をしやすくするエコシステムがあり、Githubのスタータープロジェクトのインストールから始められます。また、詳細なドキュメントや、エコシステムに慣れるのに役立つインタラクティブなチュートリアルもあります。

UI開発時に使われる理由

Storybook の何が一番いいかと言ったら、オープンソースのツールであることです。これだけでも、強力なUI開発ツールを探しているオープンソースコミュニティの支持者にとっては十分な理由になります。

UI開発、テスト、ドキュメンテーションを合理化するという事実の他に、Storybookの際立った特徴の1つは、UIを分離して構築できるサンドボックス環境であることです。これにより、最も重要な部分、つまり正しいコンポーネントとページの実装に集中でき、その間はデータ、API、ビジネスロジックのことを気にする必要はありません。

また、Storybookでは、難しいユースケースのモックも可能です。このような鍵となるステートは、アプリでの再現は少し難しいですが、Storybook を使えば全くの手間いらずです。

また、UIが実際にどのように動作するかをチームに確認させることで、タイムリーなフィードバックを得ることができ、StorybookにはStorybook Docsのような便利なアドオンが付属しており、高品質でカスタマイズ可能なMarkdown/MDXの記述ができます。

Argsとは

Storybook Argsは、入力引数を通して動的なデータの受け取りを可能にすることによって、ストーリーを書くためのより良い方法をもたらします。これらはストーリーのサイズを小さくするだけでなく、複数のストーリーにまたがってフィクスチャデータを再利用することができるため、ポータビリティも実現します。

Argsを理解するもう一つの方法は、Storybookが個別のJavaScriptオブジェクトに引数を確定するために展開される道具とみなすことです。これはコンポーネントのライブでの編集に便利ですが、Argsを使うために、基礎となるコンポーネントのコード変更は必要ないことに注意してください。

Storybook Argsの利用方法

まず、Argsオブジェクトが何であるかを見てみましょう。Argsオブジェクトは、JSONで直列化できるオブジェクトです。このオブジェクトは、有効な値の型にマッチした文字列のキーで構成されており、そのキーは、フレームワークのためのコンポーネントにできます。Argsオブジェクトを確定する方法には、「ストーリーレベル」と「コンポーネントレベル」の2つがあります。

ストーリーレベルでは、引数 CSF（主要成功要因）ストーリーキーは、それらが添付される単一のストーリーのための引数を確定するのに使われ、JavaScript の再利用オブジェクトを介して再利用することができます。一方、コンポーネントレベルでは、引数はコンポーネントのすべてのストーリーに適用され、これは特に上書きされない限り有効です。

ストーリーの引数は、他のストーリーへの合成のために分離することができ、これは、複合コンポーネント、つまり、他の様々なコンポーネントを使用して作成されたコンポーネントのストーリーを書く際に非常に便利です。この複合コンポーネントは、それぞれの子コンポーネントにそのまま引数を渡すことができ、引数によって、引数を直接合成することができます。

引数設定のもう一つの方法は、URL経由です。有効なストーリーの引数は、URLの引数クエリパラメータを使って上書きができます。これは URL を変更することで手動で行うか、【Controls】 と呼ばれるアドオンの助けによって自動化できます。セキュリティの強化のために、例えば英数字、数字、スペース、ダッシュ、アンダースコアのみ、この方法で確定される引数には一定の制限があります。URLを通じて実装される引数は、デフォルトで指定される引数を拡張し、オーバーライドします。

コンポーネントの改変

UXPinが提供するMergeテクノロジーは、自身のStorybookや既存の公開Storybookをシームレスに統合することで、作業がより快適なものになります。ストーリーブックの統合に関するステップバイステップガイドはこちらで確認できます。コードベースのコンポーネントをUXPinのインタラクティブな世界に持ち込み、Production-readyのインタラクティブなコンポーネントをプロトタイピングに使用すれば、数分でデザインを始めることができます。

​​引数を使用すると、コード内でコンポーネントのプロパティを変更する代わりに、UXPinのデザインエディタで簡単に変更できます。これの素晴らしい点は、事前のコーディング経験がなくても、業界標準のプロトタイプを構築できることです。すべてのフレームワークに対応しているため、特定のStorybookフレームワークについて心配する必要もありません。

まとめ

Storybookは、UIのデザインとテストをインタラクティブかつ使いやすい方法で行うことができる、完全なUI開発エコシステムであることに疑いの余地はないでしょう。その使いやすさと絶大な柔軟性により、業界をリードするUI開発ツールの1つとなっています。

UXPinでは、Storybookのパワーを活用することができ、MergeテクノロジーによってStorybookの引数から簡単に利益を得る方法が取り入れられています。これにより、デザインに関するあらゆる問題を簡単に解決し、最終製品との一貫性を持った魅力的なデザインを作成することができます。

The post Storybook Args とは？Storybookでどのように改善されるのか appeared first on Studio by UXPin.

UXドキュメントは、最初のコンセプトから現在のイテレーションまで、製品のライフサイクルにコンテキストを与える参考資料のような役割を担っており、UXデザインのプロセスにおいて非常に重要な部分になります。 よくできたUXドキュメントは、詳細でありながら無駄がありません。非常に的が絞られ実用的で、目的意識が高いものであるべきなのです。 UXPinは、UXドキュメント、プロトタイプ、デザインシステム、スタイルガイドをすべて1つの場所に保存することができます。UXPinを14日間お試しいただき、世界最先端のUXデザインツールをご体験ください。

UXドキュメントとは　ーその重要性ー

UXドキュメントは、プロダクトの立ち上げから現在のリリースまでの道のりを記した作業文書です。このドキュメントは、以下の理由から必要不可欠です：

• 企業の備忘録 ：ユーザーエクスペリエンスデザインの決定、ワークフロー、リサーチ、その他チームが試したプロセスについて、何がうまくいき、何がうまくいかなかったかを含め、順を追って参照することができることから、チームが同じ間違いを繰り返したり、他のチームが既に試した道をまた探ったりするのを防ぐことができます。
• オンボーディングと引き渡し：UXドキュメントは、新しいチームメンバーのオンボーディングや新しいチームへの製品引渡しの際に役立ちます。製品や会社を買収する場合、UXドキュメントでより迅速で円滑な資産の移転を促すことができます。
• 信頼できる唯一の情報源（Single source of truth）：各チームと部門が製品の歴史とそれがどのように現在に至ったかが、単一のリファレンスでわかるということです。単一なので、個人や部門が議題を押し付けるために事実を歪曲したり、失敗したものを再試行するようなことはできません。
• 連絡と連携の促進：効果的なデザインドキュメントにより、各ステークホルダーはUXデザインのプロセスや製品がどのように進化してきたかを読むことができます。
• 貴重な研究開発（R&D）と知的財産（IP）：よくできたUXドキュメントは、製品の研究開発が記述された貴重な知的財産資産です。この資産は、将来の製品開発や、販売時の製品価値向上に役立ちます。

UXドキュメントの内容

UXドキュメントの内容や制作過程は、製品、業界、会社、リサーチ、デザインプロセスによって変わってきます。 ここでは、ドキュメントをまとめる際に考慮しなければならない、ユーザーエクスペリエンスデザインの要素をいくつかご紹介します。

• 導入
• ユーザー調査
• 初期コンセプトとスケッチ
• 情報アーキテクチャ
• ワイヤーフレームとモックアップ
• プロトタイプ
• ユーザビリティテスト報告書
• デザインシステム

導入

導入部分や概要は、UXドキュメントをまとめたものであり、プロジェクトの目標、目的、ビジョンが含まれていないといけません。導入部分は、デザインの詳細をそこまで気にしないステークホルダー（非デザイナーを含む）にとって、吸収しやすくわかりやすいものでなければなりません。

ユーザー調査

ユーザーリサーチは、ユーザーペルソナ、共感マップ、ユーザージャーニーマップ、インタビュー、市場調査など、顧客に関わるあらゆる情報を含むUXリサーチ文書に欠かせない要素です。 ユーザーリサーチは、UXドキュメントの中でも、推測や当て推量、結果の誤認を避けるためのあらゆる情報を盛り込む余裕のある部分です。

初期コンセプトとスケッチ

初期コンセプトやスケッチの要約を含めることで、製品のできる過程がどのように始まったか、製品の機能の背景にある思考過程を理解できるようになります。 また、スプリントやブレインストーミングセッションのレポートも入れることで、多くのチームがユーザーやデザインの問題をどのように解決してきたかがわかります。

情報アーキテクチャ

情報アーキテクチャは、製品、ナビゲーション、ユーザーフローの全体像を見ることができるため、UXドキュメントの必需品と言えます。また、読む人が製品の成長や進化の過程を見れるように、アーキテクチャの変更履歴を記載することもできます。

ワイヤーフレームとモックアップ

静的なワイヤーフレームとモックアップにより、ステークホルダーは製品の詳細を理解すべく各画面を確認できます。ワイヤーフレームには各画面の構造と階層のコンテキストがあり、モックアップは色、文字デザイン、アイコン、ブランディング、その他のビジュアル要素を全面に出します。

プロトタイプ

プロトタイプで、ステークホルダーは製品を調べ、ユーザビリティテストやデザインコンセプトの背景にあるコンテキストがわかるようになります。UXドキュメントには、これまでに作成したすべてのプロトタイプではなく、最新のイテレーションのみが含まれるべきです。

UXPinは、世界最先端のコードベースデザインおよびプロトタイピングツールです。UXドキュメントの中で、最新の製品プロトタイプへのリンクをお届けします。UXPinのプレビューと共有モードでは、ステークホルダーは最終製品のようにプロトタイプを操作することができます。 チームメンバーはスペックモードを使って、プロパティ（サイズ、色、グリッド、文字デザイン）の検査、距離の測定、製品のスタイルガイド（デザインシステム）を開くことができます。 UXPinの強力なプロトタイピング機能を体験してみませんか？今すぐ14日間の無料トライアルにサインアップを！

ユーザビリティテストレポート

ユーザビリティレポートは、テストのプロセスと結果を文書化したものです。UXドキュメントの完成度を高め、一貫性を持たせるために、できるだけ早く標準的な報告過程を定めるのが大事です。 また、会社のユーザビリティテストのプロセスと報告方針の概要を文書に記載することにより、研究チームは、高い品質と一貫性を維持しています。

デザインシステム

デザインシステムやスタイルガイドは、製品のデザインパターン、フォント、カラー、コンポーネント、階層構造、スペーシングといったビジュアルデザインの基準の概要に当たります。また、スタイルガイドには、企業全体の信頼できる唯一の情報源（Single source of truth）を維持するためのガイドラインと正しい使用法も含まれます。

UXPinはMergeテクノロジーにより、信頼できる唯一の情報源（Single Source of Truth）のジレンマが解決され、プロダクトデザイナー、UXチーム、デベロッパーは、レポからUXPinのデザインエディタに同期された同じデザインシステムのコンポーネントを使用できます。 UXPin MergeがどのようにPayPalのDesignOpsワークフローの再構築や市場投入までの時間短縮を実現させたかについての詳細をご覧ください。

いいUXドキュメントを作る3つのヒント

Codal（企業向けデザイン・開発会社）のヨーナ・ギダレビッツ氏による、UXドキュメントを改善するための3つのヒントをご紹介します。 ヨーナは、作成するUXドキュメントについて、以下の重要事項２つを聞かなければいけないと言います。

1. そのUXドキュメントは意思決定の原動力となるか
2. そのUXドキュメントはチームにとって使い勝手のいいものか

1. 意思決定の原動力を決めてUXドキュメントに目的を付ける

事実：UXドキュメントは、それが意思決定の原動力であれば目的を持つ UXドキュメントは、デザイナー、デベロッパー、QAスペシャリスト、ステークホルダー、経営者など、さまざまなエンドユーザーを対象としており、全員が業務中に情報に基づいた意思決定を行うために特定のドキュメントを使用することがあります（使用しないこともあります）。

実際、どのような文書でも意思決定に影響を与えることができます。 ここで、アジャイルなSDLC（ソフトウェア開発ライフサイクル）を少し考えてみましょう。ある文書はSDLCの特定の活動に影響を与えるかもしれませんし、別の文書はその後のいくつかの活動に影響を与えるかもしれません。 このため、ドキュメントのライフサイクルを考慮することが不可欠です。

ドキュメントのライフサイクルとは、ユーザーからユーザーへ、不要になるまでの道のりを指しますが、それはROI（投資収益率）の問題です。 例外はありますが、大抵こういった文書は、複数の段階における意思決定の原動力なので、SDLC期間中にドキュメントが適切であればあるほど、それを完成させるために費やした時間に対するリターンは大きくなります。

つまり、UXの専門家は、必要なときだけドキュメントを作ればいいのです。そうでなければ、ドキュメントを作るだけでなく、それを消費しなければならない人たちのために、時間とお金を無駄にすることになるのです！ でもどうやってドキュメントを作る前にライフサイクルを判断するのかと思ってますか？ ドキュメントのライフサイクルを決めるのは、様々なユースケースを見るのと同じくらい簡単です。

例えば、Codalがあるクライアントのために作成した次のようなエンパシーマップを考えてみましょう。 UXの専門家は、UXリサーチ文書は優れた意思決定ツールになりがちであるとわかっています。

上記のエンパシーマップのライフサイクルを調べてみましょう。それには、「誰が」「何のために」このドキュメントを使うのかが考えられなければいけません。Codalの場合、このドキュメントはユーザーリサーチの結果をまとめたものになります。

ユーザー調査の結果は、SDLC期間中の製品戦略全体を推進し、デベロッパーやプロダクトマネージャーがそのドキュメントを所有していなくても、そのドキュメントの所見は必然的に彼らの仕事に影響を与えることになります。

先ほどのロジックに従えば、エンパシー・マップは製品の将来への投資となり、できるだけ早い段階でUXドキュメントを作成することで、時間の経過とともにROIが増加します。

2. 対象者の要求を満たすことで、UXドキュメントを有益にする。

事実：文書は意思決定の原動力となり得るが、同時に役に立たないものでもある デベロッパーは、UXデザイナーやUIデザイナーが作成したデザインに従ってページレイアウトを決定することが多いので、デザインドキュメントがどんなにお粗末でも、開発の意思決定の原動力になります。

つまり、「決断の原動力になる」ことと、「良い決断の原動力になる」ことは、まったく別ものなのです。 目的と対象者を定めた文書は、対象となるユーザーの適切な意思決定を促すのに役立つと思われます。

逆もまた然り。 対象者の具体的な要求が考慮されていない文書は、UXスペシャリストの意図が誤って伝わってしまう可能性があります。 対象になっていないドキュメントの落とし穴を避けるのは至ってシンプルです。

• 対象となるユーザーベースの推測
• チームのドキュメント使用法の分析
• ユーザーの言語を話すようドキュメントの作成

以下のインタラクティブなワイヤーフレームを考えてみましょう。

どんな文書でも、その目的を調べることで、対象となるユーザー決めることができます。 静的なワイヤーフレームは、通常、インターフェースデザイナーが、UXデザイナーのビジョンをピクセル単位で完璧にモックアップに仕上げることができるよう、視覚的なスキャフォールドとして使用されます。

しかし、インタラクティブなワイヤーフレームは、デベロッパーが依存関係やインタラクションモデルを評価するために使用することもできます。

また、プロダクトマネージャーは、機能の幅（水平方向の要件）と深さ（垂直方向の要件）をすばやく評価することができ、QAスペシャリストは、インタラクティブワイヤーフレームを使って、デベロッパーの機能を再現する作業を二重にチェックすることもできます。 このように、インタラクティブなワイヤーフレームのターゲット層は、以下が含まれると思われます：

• UIデザイナー
• プロダクトマネージャー
• ウェブ／モバイルデベロッパー
• QAスペシャリスト

ドキュメントを確実に使えるものにするには、上記の各ターゲットの具体的なニーズに応えなければなりません。そうでなければ、私たちのドキュメントは事実上何の役にも立たないのです。

LookThinkがUXPinで作成したドキュメントをそれぞれのオーディエンスに合わせた方法を紹介します。

• UIデザイナーに向けて： 画像とレイアウトの寸法を見積もる
• プロダクトマネージャーに向けて：追加的な価値がもたらされる可能性があるけど現在のスコープを超える「ぐらつく」機能をメモしておく
• デベロッパー向け： 複雑な機能を明らかにするためのメモを追加し、実現可能性について意見を求める

3. 焦点を絞ることで、ドキュメントの使い勝手を向上させる

事実：ドキュメントはユーザビリティに大きく依存する

どんなに文書の内容がよくても、読み手に理解されなければ何の役にも立ちません。ドキュメントの使いやすさを一言で言えば、「フォーカス」です。

UXの専門家は、しばしばUX文書に過剰な情報を詰め込んでしまうことがあり、この情報過多は、特にデータが翻訳中に失われた場合、多くの問題を引き起こします。

人間は余計なことを読みたがらないものです。20〜30ページのドキュメントを読んでわくわくしたことが、人生で何回ありましたか。UXドキュメントは焦点を絞られていなければいけません。

Codalがクライアントのプロジェクトのために作成した、以下のサイトマップを見てみましょう。

このドキュメントは、フォーカスの素晴らしい例です。

Codalは、1ページに全て収め、余計なことや余計な注釈を入れないようにしました。ターゲットとなるユーザーは、関連性の高いデータを消費するだけでよく、それ以上でも以下でもないのです。

UXドキュメンテーションにおけるフォーカスの達成は、目的と有用性という基本原則を単に適用するだけです。上記の文書は、この点を効果的に示しています。 UIデザイナーやデベロッパーは、あなたが選択した理由を一つ一つ聞く必要はありません。直接会って話を聞くか、上位3〜5位までの決定事項のみに焦点を当てましょう。

もちろん例外はあります。例えば、QAチームがソフトウェアの機能を十分にテストするために、詳細な理由を必要とする場合があります。その場合は各部門と連絡を取り合い、どの情報が必須で、何が余計かを知ることが重要です。

おまけのヒント：すべての関連文書にリンクするドキュメントハブを作成する AutodeskがUXPinで以下に示すように、実際の意思決定ドキュメントをぐちゃぐちゃにするのではなく、ハブに説明書きを入れましょう。

UXPinでUXドキュメンテーションを改善しよう

UXPinでは、製品のプロトタイプに直接ドキュメントを追加できるため、デザインツール内でリファレンスを一元管理することができます。 このようにドキュメントを一元化することで、プロダクトデザイナー、UXチーム、デベロッパー間の連絡と連携が促され、全員が同じ方向に向かって進むことができるようになります。 次のプロジェクトでUXPinを試してみませんか？14日間の無料トライアルにサインアップして、UXPinによる製品のデザイン強化、ワークフローの合理化、チーム連携の改善法をご覧ください。

The post UXドキュメント軽量化のガイド appeared first on Studio by UXPin.

他のデジタル製品と同様、デザインシステム作成は最初の一歩に過ぎません。その後には製品およびテクノロジーとともに成熟するデザインシステムをサポートし、進化させ、拡張していくという次のステップが待っています。 また、デザインシステムチームは、システムの改善やバグ修正、新しいコンポーネントのために、ユーザーからのフィードバックを集めなければいけません。デザインシステムを拡張し、成熟させるやり方に正しいも間違いもありませんが、チームをもっと成功させるために採用できるガイドラインは多少あります。

UXPinには、デザインシステムの開発、立ち上げ、拡張、成熟のためのツールと機能が搭載されています。無料トライアルにサインアップして、世界最先端のコードベースのデザインツールをご体験ください。

デザインシステム立ち上げ後に行うべきタスクのチェックリスト 

1）ユーザーからのフィードバックに寛容であること

デザインシステムを進化・拡大させる鍵のひとつは、ユーザーからのフィードバックです。デザインシステムチームは、デザインシステムのユーザーと繋がるためのチャンネルを設置しなければなりません。 ここにいくつか例を上げてみましょう：

• フォームによる投稿：ほとんどのデザインシステムには、ユーザーがフィードバックを送信するためのフォームが備わったお問い合わせページがあります。これによって、チームが問題を見つけたら、難なくDS チームに連絡できます。Stack Overflow の Stacks デザインシステムには、各ページのフッターにフォームがあり、ユーザーが高評価、低評価、メッセージ送信、GitHub への問題報告ができるようになっています。
• ワークショップの開催： デザインシステムのワークショップは、使い方やベストプラクティスをチームに伝えるのに最適ですが、ユーザーの声に耳を傾けてフィードバックを得るのにもとてもいい機会になります。
• メッセージチャンネル： Slack や Jira などのプラットフォームで専用のチャンネルを設置すると、DS チームにアクセスしやすくなり、ユーザーもフィードバックを送りやすくなります。たとえば、#デザイン、#開発、#バグ、#ドキュメント、#リリースなど、目的別に複数のチャンネルを設けることを考えてみてください。
• ビデオ通話でのQ&Aセッション： ビデオ通話によるQ&Aセッションは、遠隔地にいるチームと顔を合わせて話をするのにとても大事です。DSチームはこのセッションを利用して、質問に答えたり、画面を共有して複雑な問題を説明したり、一緒に問題を解決することができます。

２）デザインシステムガバナンス

“デザインシステムガバナンスとは、製品のデザインシステムを維持・更新するためのプロセスやプロトコルのことである”とあることから、デザインシステムのガバナンスと進化には、こうしたコミュニケーションチャネルの開設が欠かせません。 デザインシステムの整合性を維持するには、チームは更新や変更のための手順やプロトコルに従わなければなりません。標準的なガバナンスの方法は、決定木から始まり、ユーザーが適切な指示にたどり着くまで一連の質問を行う（例えば、「既存のパターンの修正を提案する」等）といった感じです。 一般的な改正や手続きは以下の通りです。

• 新要素の導入：新しい要素を追加するためのワークフローと手順
• パターンの推進：単発的な、あるいは最良の新しい実践を行うための手順
• パターンの見直しと適応： 新しい要素がデザインの原則や基準に合っているかどうかを確認するためのレビュープロセス
• デザインシステムアップデートのリリース：リリーススケジュールによる、アップデートの一貫性の維持とチームメンバーの正しいQA手順の把握

新しいUI要素やコンポーネントは、元のデザインシステムと同様に、厳しいデザイン、プロトタイプ、テストを受けなければなりません。そしてDSチームは、デザインシステムのスタイルガイドとドキュメントをリリースに合わせて更新する手順も含める必要があります。

３）拡張に対する柔軟性

整合性と一貫性を確保するためにガバナンスは不可欠ですが、DSチームには、チームがデザインシステムとその製品を拡張するための柔軟性もないといけません。 Salesforce Lightningでは、「バリエーション」と「ステート」によって、柔軟性を実現し、それによってユーザーは1つのコンポーネントに複数のバージョンを持つことができます。この主体的なアプローチにより、Salesforceのチームは、基本的なコンポーネントの変更に時間のかかるガバナンス手順を踏むことなく、革新と拡張を実現するためのツールが手に入ります。

4) ロードマップとリリースの共有

DSチームは、デザインシステムの変更をユーザーや関係者に伝えるためのチャンネルの設置が必要です。

デザインシステムのロードマップ ロードマップは、デザインシステムのタイムライン、タスク、マイルストーン、成果物の概要を示し、透明性を確保し、ユーザーとステークホルダーの期待を管理するためのものです。 一般的なデザインシステムのロードマップは以下の通りです。

• 最近のリリース
• チームの現在の仕事
• チームの次の仕事
• 今後のリリース予定（6-12ヶ月先まで）

リリースノートまたはチェンジログ

デザインシステムには、最新のリリース情報を知らせる「最新情報」セクションを設け、備考欄や更新されたドキュメントへのリンクも掲載しておきます。

バージョン管理

リリースに関連して、ユーザーが最新のデザインシステムのバージョンにアップグレードする方法とタイミングをコントロールできるようにするバージョン管理も行われています。UXPin Mergeのバージョンコントロールでは、各プロジェクトのデザインシステムのバージョン管理を行うことができます。デザイナーはバージョン間の切り替えも可能で、不具合調査や古いUIの更新にも便利です。

5）デザインシステムの推進

多くの人にとって、デザインシステムの利点は明らかですが、もっと詳しい説明が必要な人もいます。となると、DSチームと支持者は、デザインシステムを普及させ、組織全体での利用を増やすためのクリエイティブな方法を見つけなければいけなくなります。

デザインシステムサンドボックスの作成

サンドボックス環境を作ることは、ユーザーがデザインシステムと対話するには素晴らしい方法であり、多少のテストプロジェクトや製品のUIをコピーしてもらうことで、実体験が得られます。 サンドボックス環境で最も早くプロトタイプを構築した人に賞品をあげるようなイベントを毎月開催したりして、サンドボックスをよりエキサイティングなものにしましょう。 並べで比較するデモンストレーション PayPal が UXPin Merge に切り替えたとき、Merge と画像ベースのデザイン ツールを比較検討しました。その際にPayPalのデザイナーは、UXPin Mergeを使用してプロトタイプ１ページを8倍速く作成しました。 このようなデモンストレーションで、ワークフローを合理化するデザインシステムの能力が証明されやすくなります。このようなセッションを録画し、関係者へのプレゼンテーションに使用することで、デザインシステムへのさらなる投資を促すことができます。

デザインシステムの会合

コミュニケーションは、デザインシステムを拡張し、成熟させるのに欠かせない要素の一つです。DS チームはフィードバックを受けることにオープンでなければならず、また採用を拡大するためにユーザーと積極的に関わらなければなりません。 組織全体の導入・普及を実現するためには、対面式の会合を開催することが重要です。Salesforce LightningのDSチームに8年以上携わったイーシャ・カスリワル氏は、Clarity Conference 2017の講演で、この点を改めて強調しました。 「ライトニング・デザイン・システムでは、組織全体への普及と導入に重点を置いています。オフィスアワーで週に2回、誰でもデザインシステムについての質問ができるようにしています。また、カジュアルなランチミーティングも開催しています。それでも声を大にして言いたいのは、このような対面での働きかけを頻繁に行い、相談相手として存在しなければならないことを知らない人がまだたくさんいるのです。」

6）KPIを用いた価値測定

将来のリソースを獲得するには、DSチームにはデザインシステムの投資対効果の実証が必要です。デザインシステムの導入前にKPIを測定し、パフォーマンスを測定するための基準値を持つことはとても大切なのです。 デザインシステムのパフォーマンスを長期的に追跡するのに欠かせないKPは3つあります。

1. チーム効率 – 組織内のデザインシステムを使って、チームが新製品を作るのにかかる時間の見積り。
2. 市場投入までのスピード – チームがプロトタイプを作成し、テストするのにかかる時間の測定。
3. コードへの影響 – リリースごとにデベロッパーがどれだけコードを変更したかの測定。

その他、デザインシステム導入後に改善を実感できる部分には、以下のようなものがあります。

• 売上／コンバージョンの増加
• テクニカルサポートコールの削減
• ブランド満足度
• 手戻りやミスの削減
• 従業員の定着率
• 人件費削減

7）デザインシステムの熟成

長期的な目標は、デザイナーやエンジニアが新製品を開発するために必要なものがすべて揃っているようなデザインシステムの成熟度を達成することですが、この成熟度を達成するためには、相当な時間とリソースが必要になります。 世界的なソフトウェア開発企業であるIressは、設計システムの成熟度を4つのステージに定めています。最終段階はデザインと開発の間で完全に統合された信頼できる唯一の情報源（single source of truth）ですが、このプロセスは2015年に始まり、Iressは2022年になってようやく達成しました

UXPinによるデザインシステムの拡張と成熟

UXPinには、1つのデザインツールを使って、コンセプトから完全に統合されたデザインシステムまでを実現する機能が搭載されています。また、デザインシステムのスタイルガイドとドキュメントを格納するスペースも用意されているので、デザイナーはUXPinをずっと使い続けることができます。

UXPin Mergeで、デザイナーとデベロッパーが同じコンポーネントを使用し、組織全体で信頼できる唯一の情報源（single source of truth）を作成するデザインシステムを次のレベルに引き上げることができます。 MergeでレポジトリにホストされているデザインシステムをUXPinのデザインエディタに同期させることができるため、デザイナーは完全に機能するコードコンポーネントを使用して、モックアップやプロトタイプを構築することができるようになり、当社のReactコンポーネントのGit統合か、Angular、Vue、Web Components、Ember、など他の技術に対応したStorybookで選ぶことができます。 DSチームは、コンポーネントプロップ（React用）またはアーギュメント（Storybook用）を使用して、デザイナーがデザインシステムに応じて、例えばボタンコンポーネントに「ステート」、「インタラクション」、「サイズ」、「カラーオプション」を追加するなど、柔軟に変更できるようにします。

エンジニアが既にコンポーネントに精通しているため、マージデザインの引き継ぎが非常にスムーズです。どのコンポーネントの変更もJSXでレンダリングされるため、エンジニアはコピー＆ペーストで開発を始められます。 コードベースのデザインを試す準備はできましたか？無料トライアルにサインアップしてUXPinの直感的なデザインエディタをお試しください。

また、MUIライブラリとの統合により、UIコンポーネントのデザインも14日間お試しいただけます。UXPinでデザインシステムの構築、管理、拡張をご体験ください。

The post デザインシステム作成後にやるべきことチェックリスト appeared first on Studio by UXPin.

デザインシステムの採用と拡張は簡単ではありません。ステークホルダー、プロダクトマネージャー、開発チーム、デザイナーを説得し、デザインシステムの価値を伝えるために、組織全体から得なければなりません。

デザインシステムの構築は、最初の一歩にすぎません。デザインシステムが使われて最適な成熟度に到達するには、多くの時間と費用がかかります。 デザインシステムを伝えるということは、そのデザインシステムで、チームがより効率的で生産性が高く、複雑な課題に自由に取り組めるようになるということを証明しなければならないということです。

ExxonMobileがデザインシステム「Unity」を作成したとき、同社は10か月で50以上ものWebアプリを構築しました。 このように、デザインシステムがどのようにビジネス価値を生み出し、投資収益率（ROI）をもたらすかを実証することが目標です。

この記事では、デザインシステムをステークホルダーや投資家に売り込む際に役立つ実用的な情報・ヒントなど、組織の賛同を得るための方法についてご紹介します。

ゼロから始める・既存のデザインシステムを使用する場合でも、UXPinには、プラグインやエクステンションのない単一のプラットフォームを使用した、デザインシステムを構築、拡張、成熟させるためのソリューションがあります。 

なぜデザインシステムの普及が必要なのか？

多くのステークホルダーは、デザインシステムの構築と管理を、収益を生み出す製品のデザインと最適化から外れた、やたらコストのかかるものと見なしています。 彼らは、デザインシステムがどのようにROIを生成するかをわかっていません。

デザイナーには、他のデザインチーム、プロダクトマネージャー、およびエンジニアにデザインシステムを採用するよう説得するという壁も立ちはだかります。 Spotifyが2018年にデザインシステム「Encore」を構築したとき、彼らは「22種類のデザインシステムが浮遊していた」といいます。

したがって、デザイナーにとってデザインシステムの普及が必要な主な理由は2つです。

• ステークホルダーにとってのビジネス価値を証明する。
• デザイナー、プロダクトチーム、およびエンジニアの作業負荷を軽減および生産性の向上。

デザインシステムのバイインを取得において誰が責任を担うのか？

誰がデザインシステムのバイインで責任を担うのかは、組織とデザイン設計部門の構造によって異なります。 製品マネージャー、Webマネージャー、デザインリーダー、DesignOpsリーダー、またはスタートアップ会社の業務を受け持つUXデザイナーから任されることもあり得ます。

Eightshapesの創設者であるネイサン・カーティス氏は、3つのよくあるデザインチームの構造と、デザインシステムの拡大にどのように関与しているかを識別しています。

• 独立型チームモデル：一般的に、スタートアップの環境では、契約社員やフリーランサーと仕事をするUXデザイナーが一人いる。彼らは、一貫性を管理し、契約社員（および将来の社員）のオンボーディングを最小限に抑えるために、デザインシステムの必要性を説くこともある。
• 集権型チームモデル：中規模から大規模の組織で典型的なチーム構成で、集権化されたチームによって設計上の意思決定が行われる。複数の製品の設計決定を管理することが多い。
• 連合型チームモデル：米国上院の代表と同じように、さまざまなプラットフォームおよび製品ラインの設計者の部署が協力して、設定された期間、集合的に設計上の意思決定を行う企業構造。

ステークホルダーにデザインシステムを提案するタイミングは？

デザインシステムの構築が遅れるほど、そのデザインシステムの実行に時間と費用が掛かります。 問題は、AirbnbやSpotifyなどの多国籍企業を含むほとんどの組織が、これに気付くのが遅すぎるために、結局は多額の費用がかかってしまうということです。

Airbnbのデザイン担当副社長であるアレックス・シュライファー氏は、「単純なことです。まず製品の製造方法を導入しないことには、製品を導入することはできません。」 と述べています。

UXPinがデザインシステムのスペシャリストである、Superfriendlyのダン・モール氏に話を聞いたとき、どの規模の会社がデザインシステムから利益を得るのかを尋ねました。 ダン氏は、「私が特定できるような規模あるとは思いませんが、その会社の維持している、または維持しようとしているデジタル資産の数に左右されることだと思います。」と答えました。

デザインシステムがないと、ソフトウェア開発プロセスが徐々に遅くなり、ユーザーエクスペリエンスが低下します。 デザインを拡張するために設計者の雇用を増やすことはできません。 デザイナーが増えるのは「キッチンで調理する人」が増えるということであり、その結果、デザインプロセスに収拾がつかず、一貫性がなくなり、デザインにズレが生じます。

以下は、タイミングをみるためのチェック事項です：

• 製品開発のスピードに満足していますか？
• 自身のインターフェースは、同じデザインパターン、色、文字デザイン、およびその他のスタイルを共有していますか？
• KPIを満たす高品質の製品を提供するのに十分な時間は常にありますか？
• 部門のサイロは設計にどのように影響しますか？
• 余分な設計またはコードタスクにどのくらいの時間とお金をかけていますか？
• 設計や技術的負債の整理にどのくらいの時間とお金をかけていますか？

このような質問に答え、設計上の問題を浮き彫りにすることで、組織がデザインシステムを導入する時期だということを提案できるきっかけになります。

デザインシステムをどのように普及するか？

無料のツールキットであるデザインシステムの普及に、デザイナーからバイインを得るための実証済みのテンプレートがあります。 デザインシステムが解決する問題と、それがどのようにROIをもたらすかを特定するための内部リサーチが必要です。

以下は、プレゼンを準備し、デザインシステムを広めるための5つのステップです。

ステップ１ー　リサーチの実施

最初のステップは、リサーチを実施して、設計における社内の問題点を見つけることです。例えば、もしかしたら、UIキットやスタイルガイドの方が、より現実的で費用効果の高いソリューションかもしれません。

この方法は直感に反するように聞こえるかもしれませんが、ステークホルダーや他のチームメンバーからの抵抗や精査に直面する可能性が高いことを頭に入れておいてください。 あなたの目標は、難しい質問に備えるためにあらゆる可能性を確実に探っておくことです。

プロダクトマネージャー、デザインリーダー、カスタマーサポートマネージャー、エンジニア、およびその他のチームメンバーが直面している問題と課題を把握するために、リサーチには彼らへのインタビューも含まれるべきです。

• 手直し率は？
• デザインの引き渡しの問題は何ですか？
• ユーザビリティの問題に関連するサポートチケットはいくつありますか？ そして、ユーザーへの影響は何ですか？
• どのくらいの頻度で設計と開発にズレが生じますか？

この段階での目標は、デザインシステムが解決できる問題を特定し、ROIがプラスになるのを実現することです。 最も重要なことは、これらの社内の問題が顧客にどのような影響を与えるかということです。

ステップ2–調査に基づいてプレゼンの準備

デザインシステムを広めるテンプレートには、4つのセクションに40を超えるスライドがあり、デザインシステムを実施するための強力なプレゼンを作成するために必要なものがすべて含まれています。

以下がプレゼンに含まれます：

• ユースケースと調査からの事実による導入
• デザインシステムとは何か、そしてそれがどのように機能するかの概要
• ROIを計算して提示するためのテンプレート
• 次のステップのセクションと、設計システムの実施を計画する方法

また、デザインシステムの一貫性と整合性を維持するために、ガバナンスのシステムとデザインシステムチームが必要になります。 そうしないと、Spotifyのように、22のデザインシステムが世界中に広がってしまいます。

デザインシステムチームの規模は、会社と製品数によって異なります。 以下は、Superfriendlyが集権型チームモデルに推奨するデザインシステムチームの例です（上記の「誰がデザインシステムのバイインを得るために責任を担うのか？」をご参照ください）。

• プロダクトオーナー
• デザインマネージャー
• テクニカルディレクター
• シニアデザイナー
• シニアエンジニア
• シニアアナリスト
• コンテンツストラテジスト
• アソシエイトデザイナー
• アソシエイトエンジニア
• QA

規模が小さめの企業やスタートアップ企業では、これらの役割のうち2〜5つしか果たしていない場合があります。

ステップ3–味方を見つけてチームを教育する

ステークホルダーに提案する前に、チームメンバーの教育をすることが不可欠です。 プロジェクトの背後にいるチームメンバーが多いほど、ステークホルダーを説得できる可能性が高くなります。

Abstractのシニアプロダクトデザイナーであるジョーダン・スタニシア氏は、デザインシステムに対するあなたの情熱とビジョンを共有する他の部門から「味方」を見つけることを勧めています。 こういった味方の伝道者は、あらゆる部門がどのようにデザインシステムを使用するか、そしてそのチームメンバーにアピールするための最善の方法を教えてくれます。 SurveyMonkey、HubSpot、WeWorkの従業員はすべて、この戦略でチームメートの教育をしてきました。

このプロセス中で、ステークホルダーへのプレゼンを強化するためのより深い見識が得られるかもしれません。

ステップ４ー　ステークホルダーへのプレゼン

ステークホルダーへのプレゼンでは、次のことを提示することが重要です。

• デザインシステムが、これまで他社や競合他社にどのように役立ったか
• 自社が抱えている問題点、ペインポイント
• これらの非効率性から生じるコスト
• 顧客への影響
• チームメンバーからのフィードバック
• デザインシステムによる非効率性の低減・解消とそれに伴うROIの算出方法
• 会社特有の利点
• 提案するデザインシステムの構造の基本的な概要
• デザインシステムのチームとガバナンスの概要

無料のテンプレートであるデザインシステムの普及には、こういったポイントをステークホルダーに簡潔に提示するための余白スペースがあります。

ステップ5–継続的な伝導とアウトリーチ

デザインシステム自体のように、あなたがする伝導と教育は進化の途中です。なので、 デザインシステムチームは、引き続きチームメンバーと連携していなければいけません。

• 問題点の洗い出しと解決策
• インプット、提案、オーナーシップの奨励
• 更新、拡張およびベストプラクティスに関するチームへの教育

デザインシステムを拡張するにつれて、より多くの資金とリソースが必要になるので、デザインシステムをステークホルダーに継続的に伝道することが重要です。

• デザインシステムが非効率性をどのように改善したか実証
• チームメンバーからのフィードバック
• デザインシステムに関連するユーザーリサーチからのフィードバックの共有
• デザインシステムによるユーザビリティとアクセシビリティの改善方法
• ROI
• デザインシステムのロードマップと、将来の変更がビジネス価値をもたらす方法

UXPinを使用したデザインシステムの構築、拡張、および成熟

UXPinのデザインシステムの機能を使用して、最小限の投資でデザインシステムを始めてみませんか。 色、アセット、文字デザイン、コンポーネントを使用して、デザインシステムをゼロから設計してみましょう。 ドキュメントを使用してデザインシステムを管理し、新しいコンポーネントの権限を設定して、不正な変更を防ぐこともできます。

UXPinは、UXPi Mergeを使用した、拡張および成熟したデザインシステム向けのソリューションもあります。 マージを使用すると、リポジトリからデザインシステムをUXPinのデザインエディタに同期できます。 設計者は、完全に機能するコードコンポーネントを引き出して移動させるだけで、新しい製品やユーザーインターフェースを構築できるのです。

Mergeを使用すると、UXデザイナー、プロダクトチーム、およびエンジニアは皆まったく同じコードコンポーネントを使用するため、組織全体で信頼できる唯一の情報源が作成されます。

UXPinを使用してゼロからデザインシステムの構築を開始する無料トライアルにサインアップするか、成熟したデザインシステムについては、Mergeのページにアクセスして詳細をご覧ください。

The post デザインシステムを普及させるためには？ appeared first on Studio by UXPin.

デザインシステムの構築というのは、時間と費用のかかる作業です。 しかし、多くの組織に見られるように、メリットはコストをはるかに上回ります。 デザインシステムのロードマップにより、チームメンバーとステークホルダーは、デザインシステムの成熟度、目処、およびタイムラインをモニタリングできます。  

この記事では、着手したばかりでも、既存のデザインシステムを拡張したい場合でも、デザインシステムが与えるインパクトをステークホルダーに納得させ、その価値を高めて採用を促進させる方法についての見解を述べていきます。  

UXPinを使用すると、デザインシステムをゼロから構築することや、Merge機能を用いて既存のUIコンポーネントライブラリを同期するのが簡単にできます。 無料お試しを申し込んで、世界で最も先進的なコードベースのデザインツールを体験してみてください。  

デザインシステム のロードマップとは？

デザインシステムのロードマップは、タイムライン、タスク、目処、および成果物をグラフ化した高レベルの作業文書です。 製品ロードマップと同様に、チームメンバーとステークホルダーが着手と目処を視覚化して透明性を高め、予測を管理するためのタイムライン形式の戦略計画です。  

デザインシステムチーム（またはDesignOps）は、今後数か月の間に何が行われるかを誰でも確認できるように、ロードマップを通常四半期ごとに編成して発表します。  

典型的なデザインシステムのロードマップには、次のものが含まれます。

• 最近のリリース
• チームが現在取り組んでいること
• チームが次に取り組むこと
• 今後のリリース（6〜12か月前）

なぜロードマップが必要なのか？

チームとステークホルダーにとって、以下の目的によりデザインシステムのロードマップが必要になります。

• チームがデザインシステムの展開を計画して優先順位を付けることができます
• デザインシステムのロードマップにより、ステークホルダーは進捗状況を確認し、リリースのROIを測れます
• チームはロードマップを元に製品リリースを計画できます
• チームや部門間のコミュニケーションとコラボレーションを改善します
• 役割と責任を明確にします
• 一貫性を維持し、チームメンバーが同じ作業を繰り返すのを防ぎます

リリース計画とロードマップの違いは？

  ロードマップは、デザインシステムのリリース段階と目処についての概要を示す高レベルの全体像ですが、リリース計画は、各段階と目処を確実に達成するためにチームがやっていかなければいけない、特定の手順の詳細な所見です。  

  チームは、リリース計画の詳細や個々のタスクに必ずしも関心がないステークホルダーや顧客とやり取りをするのに、デザインシステムのロードマップを使います。  

デザインシステムのリリース計画は、リーダーが他のチームや部門と連携するのに最も有益です。  

各ドキュメントは、それぞれ特定の目的を持って作られているので、デザインシステムのロードマップには全てロードマップとリリース計画が必要です。 Productboardのこの記事では、リリース計画とロードマップの違いと、ロードマップを視覚化および管理するための便利なツールについてより詳しく説明しています。  

デザインシステム のロードマップの作り方

   以下は、デザインシステムのロードマップを作成する7つのステップの概要です。Nielsen Norman Groupのこの記事を、大まかなガイドとして使います。  

1. 目標の設定
2. 監査
3. 調査
4. ビルドの確定
5. 優先順位の設定
6. ビルド
7. 維持

ステップ１ー　目標の設定

最初のステップは、デザインシステムを構築し、ロードマップを作成する目的を確立することです。 ここで設定された目標は、プロセスを通してガイドし、後でデザインシステムのロードマップに優先順位を付けるのに役立ちます。  

ステップ２ー　監査

製品とユーザーインターフェースを監査して、各スタイル、要素、およびコンポーネントを一覧表示します。 この監査は、不整合やエラーを特定する絶好の機会です。  

監査は次の4つのカテゴリに分類できます

1. スタイル：色、フォント、サイズ、間隔など。
2. アセット：画像、動画、アイコン、ロゴ、その他の視覚的なデザイン要素
3. UIコンポーネント：ボタン、CTA、カード、フォーム、モーダル、パンくずリストなど。
4. インタラクション：アニメーション、マイクロインタラクション、その他のモーションアイテム

あくまでガイドラインとして使用してください。 組織では、デザインシステムの各部分に異なる名前またはカテゴリが使用されている場合があります。

ステップ３ー　調査

次に、デザインシステムのユーザー（UXデザイナー、製品チーム、エンジニア）にインタビューして、現在のワークフロー、問題点の特定、彼らがデザインシステムからどのようにメリットが得られるか（またはどのように既存のデザインシステムを改善させるか）を把握します。  

また、既存のアーティファクトのコピーを集めることもできます。

例：

• 以前のロードマップとデザインシステムのドキュメント
• デザインシステムガバナンスのドキュメント
• ユーザージャーニー
• IA　（情報アーキテクチャ）
• スタイルガイド
• バックログ（設計および開発）
• UX戦略
• UX監査

  作業が重複しないようにし、新しいデザインシステムのロードマップが現在の戦略、プロセスやプロトコルと確実に一致するようにするのが、これらのドキュメントを収集する目的です。  

ステップ４ー　ビルドの確定

監査と調査を使用して、構築する必要のあるデザインシステムの部分を明らかにします。 デザインシステムのパートを、監査で使用したカテゴリに分けます。  

EightShapesのネイサン・カーティス氏は、最初にホワイトボードと付箋を使って、5つのカテゴリの「構築する部分」を特定し、次に「今、もうすぐ、後で、待機」順に並べます。  

構築または修正する必要のあるデザインシステムの各部分を全て確定して一覧表示することが目標です。

ステップ５ー　優先順位の設定

  構築する必要のある部分を全部リストアップしたら、それに優先順位を付けて、デザインシステムのロードマップのタイムラインを作成します。  

   

ゼロからデザインシステムを構築する場合は、まずは基本的なスタイルと要素を優先します。 ブラッド・フロスト氏のアトミックデザインメソッドを使用して、デザインシステムを最小の部品とスケールに分けることをお勧めします。  

  既存のデザインシステムの場合、ユーザビリティとアクセシビリティの問題に関連する要素とコンポーネントを最優先します。  

ステップ６ー　ビルドとテスト

ロードマップができたら、設計者はデザインシステムの構築を始めます。 我々は、UXPinの開発と、40人以上の設計およびエンジニアリングのリーダーへのインタビューで得た経験に基づいて、デザインシステムを構築するためのステップバイステップガイドを作成しました。  

  12ステップのプロセスには、UIインベントリのカタログ化、組織の賛同の取得、デザインシステムチームの編成、デザインシステムガバナンスの確立、標準化、追加のリソースなどが含まれています。  

リリース前に、UXデザイナーは、使いやすさとアクセシビリティの基準を満たしているか、新しいコンポーネントをテストしなければいけません。 ガバナンスのシステムの実行によって、チームはリリース前に確実に正しいプロセスとプロトコルに従うことができます。  

設計者は、新しいデザインシステムコンポーネントのリリース前に正確なテストができるように、コードのような機能を備えた忠実度の高いプロトタイプを、UXPinを使って作成します。 高度なインタラクション、ステート、変数、およびエクスプレッションを使用して、最終製品のような見栄えと機能のプロトタイプを作成します。

ステップ７ー　維持

デザインシステムが完成することはありません。 デザインシステムは製品と共に進化し、設計と開発の間の信頼できる唯一の情報源に到達するまで、いくつかのデザインシステムの成熟の段階を経ます。  

デザインシステムのロードマップも、完成することはありません。 デザインチームは、組織とステークホルダーを最新の状態に保つために、少なくとも四半期に1回はロードマップを再検討し、改訂する必要があります。  

デザインシステム のロードマップを作成するための最善法7つ

１．部門の枠を超えたチームの構築　UXデザイナー、プロダクトマネージャー、エンジニアを含む部門の枠を超えたチームを構築して、デザインシステムのロードマップを作成および管理します。 クロスファンクショナルチームで、複数の部門からの設計システムの支持者を確保して賛同と使用の可能性を高めます。

２．問題の確定　デザインシステムとロードマップを使用して、解決しようとしている問題を明らかにします。 製品と組織には、それぞれに固有の問題と優先順位があります。 問題を明らかにすることで、どこから始めて、どのように目標に優先順位を付けるかがわかります。

３．目標と目処の設定　チームが目標を設定し、いつ各タスクを正しく完了したことを確認できるように、デザインシステムとロードマップの目標と目処を設定します。

４．フィードバックと貢献の奨励　組織全体、特にUXデザイナー、製品チーム、エンジニアからのフィードバックと貢献を奨励します。 このインプットにより、賛同が高まり、チームにデザインシステムの所有権が与えられます。

５．ソフトローンチの活用とプロジェクトのテスト　デザインシステムをリリースや拡張する前に、ソフトローンチを行い、社内チームとプロジェクトをテストして、早期の見解を得ます。 これらのソフトローンチにより、制御された環境の問題点を特定でき、それによって変更や修正の実行がしやすくなります。 ６．ツールを見つける　デザインシステムとロードマップの管理に役立つツールを見つけましょう。 正しいツールを使用すれば、ワークフローを最適化し、時間のかかる管理タスクを自動化できるため、デザインシステムのROIが向上します。

７．設計トークンと標準化された命名規則の実行　最初のコンポーネントの設計をこれから始めるという時でも、設計トークンと標準化された命名規則を実行します。 これらのデザイントークンで、デザインシステムを拡張するときに、まとまりと一貫性を維持しやすくなります。

UXPinを使用したデザインシステムの作成と拡張

UXPinは、組織がデザインシステムをゼロから構築したり、成熟のどの段階での既存のデザインシステムを管理したりするためのソリューションを提供します。  

ゼロからの構築

デザインシステムはUXPinで簡単に作成できます。 外部ツールやプラグインを使用せずに、1つのユーザーインターフェースからデザインシステムを構築、共有、管理、および拡張できます。  

各デザインシステムは、色、文字デザイン、アセット、コンポーネントの4つの部門で構成されています。 設計者は、ドキュメントの説明を含めたり、チームメンバーが不正な変更を加えないように権限を設定したりすることもできます。  

無料お試しを申し込んで、UXPinで初めてのデザインシステムコンポーネント構築がいかに簡単かを体験してみてください。  

デザインシステムの成熟度のためのUXPin Merge

  UXPin Mergeは、古いデザインシステムを備えた組織に最適なソリューションです。 Mergeを使用すると、コードコンポーネントをリポジトリからUXPinのエディターに同期できるため、UXデザイナーと製品チームは完全に機能するプロトタイプを作成できます。  

Mergeは、1つのデザインシステムを維持するだけでよいため、デザインと開発の間のギャップを埋めることにより、信頼できる唯一の情報源（Single Source of Truth）を作成しながら、多くのDesignOpsの課題を解決します。 リポジトリへの更新は、どれも自動的にエディターに同期され、UXPinは設計チームに変更を通知します。  

  Vue、Angular、Ember、Webコンポーネントなどの他の一般的なフロントエンドフレームワークのGit統合またはStorybookを使用してReactコンポーネントを同期できます。  

 UXPin Mergeの詳細を確認し、この強力なコードベースの設計テクノロジへのアクセスを申し込んでください。

The post デザインシステムのロードマップを作成する方法 appeared first on Studio by UXPin.

現代の速いペースで進むハイテク業界では、デザインの一貫性を完璧に保つことは困難な状況です。特に、複数のチームが同じデジタル製品に取り組んでいる場合はなおさらです。 定期的なUXデザイン監査によって、デザイナーは製品を評価し、継続性、一貫性、アクセシビリティ、ユーザビリティの問題を特定することができます。 UXPinのコードベースのデザインツールで、忠実度、機能性、コラボレーションを高めながらエラーを削減します。

UX監査とは？

UX監査（UXレビューと呼ばれることもある）は、既存のデジタル製品がビジネス、ユーザーエクスペリエンス、アクセシビリティの要件を満たしているかどうかを確認する品質保証（QA）プロセスです。 デザイン監査を行うことで、UXデザイナーは、貴重な実データを用いて、ユーザーのペインポイントやビジネスバリューの機会を特定することができます。デザインプロセスでのテストは、実世界で製品がどのように機能するかを明らかにするには限界があります。特に、毎日何千、何百万人ものユーザーを抱えている場合はなおさらです。 UX監査では、以下のような測定、テスト、および分析を行います。：

• リンク切れ
• フォント、色、パターンなど、デザインシステムの不整合
• レイアウトやレイヤーの不統一
• 古いコンテンツ
• カスタマージャーニーのボトルネックと障害
• ユーザビリティとアクセシビリティ
• ユーザビリティヒューリスティック
• ブランディングとメッセージング
• ビジネスとユーザーエクスペリエンスの目標に照らして製品設計を見直す
• トラフィック、エンゲージメント、コンバージョン率、リテンション、売上分析
• 法令遵守（GDPR、CCPAなど）

デザインオーディットの最後には、問題点の修正や製品の最適化のための実用的な推奨事項を記載したUX監査報告書を作成します。

UXデザイン監査を行うタイミング

チームは通常、重要な製品アップデートや製品再設計をリリースするたびに、QAプロセスの一環としてUX監査を実施します。また、組織が定期的にUX監査を実施し、製品がビジネスおよびユーザーエクスペリエンスの目標を満たしていることを確認する場合もあります。

UX監査は誰が行うのか？

誰がUX監査を行うかは、企業の規模や利用可能なリソースによって異なります。多くの新興企業は社内のデザインチームを使ってUX監査を行うでしょう。 客観的で偏りのないUX監査を行うために、外部の監査人を利用して製品を評価し、報告書を提出する組織もあります。大企業では、UXデザインエージェンシーを利用することもあります。高価ではありますが、有意義なフィードバックと洞察を伴う徹底的な監査を行うことができます。中小企業や新興企業では、フリーランサーを雇って同様の結果を得ることも検討できます。

UX監査の準備方法

UX監査では、デジタル製品を評価するためにいくつかのベンチマークが必要です。これらのベンチマークがなければ、監査人は製品がKPI、目標、および目的を満たしているかどうかを判断する方法がありません。 もしあなたの会社にUX戦略がないのであれば、UX監査を行う前に、まずこれを定義することから始めるとよいでしょう。無料のUXプロセスとドキュメンテーションのテンプレートをダウンロードし、この記事を読んでいただき、最初のデザイン監査の前に御社のUX戦略のアウトラインを描くことができます。 UX監査の準備には、以下のものが必要です。

• ユーザーペルソナ
• 明確なビジネス目標の設定
• 製品データおよび分析
• 過去のUX監査結果および変更点
• 監査の制約、成果物、期限、ステークホルダー

ユーザーペルソナ

UX監査を実施する前に顧客とそのペルソナを特定することで、現在のユーザー（分析データから）とターゲットユーザー（過去のユーザーおよび市場調査から）が一致しているかどうかを判断することができます。 UXオーディットの結果、ユーザーの属性に変化があったとします。その場合、UXデザイナーはデザイン思考プロセスを適用して、製品がこの新しいグループに適切に対応しているかどうかを判断する必要があるかもしれません。

明確なビジネス目標

企業のビジネス目標を理解することも、UX監査の準備として監査人が知っておかなければならない重要な要素です。監査人は、製品が企業のビジネス上の期待に応えているかどうか、そしてデザインが与える影響を、ネガティブなものであれポジティブなものであれ、評価する必要があります。

監査の制約条件、成果物、納期、ステークホルダー

最後に、監査人は、監査の予算/リソースの制約、成果物、期限、報告に関する利害関係者を理解する必要があります。この情報は、制約と期待に応えるために監査人がどのようにレビューを行うかを決定するため、監査そのものと同じくらい重要です。

製品データおよび分析

監査役は、ヒートマップ、クリックトラッキング、その他のインタラクションデータなど、関連する製品分析および情報を収集する必要があります。Google Analytics、Kissmetrics、Hotjar、CrazyEggなどを使ってデータを取得することができます。 このデータは、ユーザーがデジタル製品をどのように操作しているかを理解し、デザイナーがその行動に合わせて変更を検討する必要があるかどうかを判断するのに非常に重要です。 また、アナリティクスは、製品の成功指標とKPIを測定するためのコンバージョンデータと収益データを監査人に提供することができます。

以前のUX監査結果および変更点

監査人は、過去のUX監査のレポートから、同じ問題がまだ存在しているかどうかを確認することができます。前回のUX監査の後に設計変更があった場合、監査人は、その変更が問題を解決し、ユーザー・エクスペリエンスに影響を与えたかどうかを判断することができます。

UXデザイン監査の実施

ユーザビリティ・ヒューリスティック

ヤコブ・ニールセンのインタラクションデザイン10原則は、多くのUXデザイン監査の基礎となっています。90年代初頭に開発されたNielsenの10個のヒューリスティックのリストは、監査人が従うべき特定のユーザビリティガイドラインではなく、幅広い「経験則」を概説しています。

1. システム状況の可視化：ユーザーが自分の操作の影響と次のステップを理解するために、現在のシステム状況を確実に把握できるようにすること。
2. システムと実世界の一致：デザインは、親しみやすい言葉、フレーズ、コンセプトでユーザーの言語を話さなければなりません。また、論理的で直感的な操作により、タスクや目標を容易に達成できるようなデザインでなければなりません。
3. ユーザーのコントロールと自由度：タスクやフローを変更したり、終了したり、やり直したりするための完全なコントロールをユーザーに提供する必要があります。例えば、フロー中に「戻る」ボタンを設置したり、ショッピングカートの項目を更新・削除できるようにします。
4. 一貫性と標準：デザインに一貫性がないと、ユーザーの認知負荷が高まり、結果として製品体験が損なわれる可能性があります。業界標準に準拠し、デザインの一貫性を保つことで、ユーザーが製品を使用するために学ばなければならないことを最小限に抑えることができます。
5. エラーの防止：設計者は、エラーが起こりやすい状態を防止または排除するために、できる限りのことをしなければなりません。
6. 思い出すよりも認識する：ユーザーはボタンやアクション、要素が何をするものかを覚える必要がないようにします。ユーザーの認知負荷を軽減するために、ユーザーインターフェースは認識を促進するものでなければなりません（明示的なラベルや指示）。
7. 柔軟性と効率性：デジタル製品は、ユーザーが自分の好きなワークフローをカスタマイズできる柔軟性を備えていなければなりません。例えば、最もよく使う機能へのお気に入りリンクを簡単に作成できるようにする。
8. 美的感覚とミニマリズムデザイン：ユーザーのためにならない冗長なコンテンツやUI要素は避ける。ミニマルな画面レイアウトは、ユーザーが最小限の労力で必要なものを見つけられるようにします。
9. エラーの認識、診断、回復を支援する：エラーメッセージは、問題を解決するためのわかりやすい手順でユーザーを導く必要があります。意味のないエラーコードは避け、代わりに製品ドキュメントやカスタマーサポートへのリンクを提供します。
10. ヘルプと説明書：製品の説明書は、ユーザーが製品の機能を理解し、必要な作業を完了するのに役立つものでなければなりません。

監査人は、これらの10のユーザビリティ・ヒューリスティックを監査するために、ユーザーテストと製品分析を組み合わせて評価する必要があるかもしれません。

ユーザー・エクスペリエンス

UXデザインは人間中心のアプローチであるため、製品のユーザーエクスペリエンスを監査することは、デザイン監査において最も重要な部分と言えるでしょう。 監査員は、アナリティクスとインタラクションデータを調査し、ユーザーフロー、ナビゲーション、および全体的なユーザーエクスペリエンスに対するデザインの影響を判断します。分析データで何か目立つものがあれば、問題を完全に理解するためにユーザビリティテストを実施したり、推奨したりすることもあります。

デザインシステム評価

企業のデザインシステムは、継続性と一貫性を維持するために不可欠です。監査員は、UIコンポーネントやデザインパターンがユーザーエクスペリエンスの目標やブランディングのガイドラインに合致しているか、製品のデザインシステムを検証する必要があります。

アクセシビリティ

アクセシビリティは、製品がすべてのユーザーにとって包括的であることを保証するための重要な要素です。監査人は、カラーパレット、フォント、コンポーネントが視覚障害のあるユーザーに配慮されているかどうかを検討する必要があります。また、視力の弱いユーザーに配慮して、明暗の切り替えが可能かどうかもチェックします。 UXPinに組み込まれたアクセシビリティ機能は、デザイナーがベストプラクティスに従うことを支援し、設計を引き渡す前に製品がWCAG標準に合格するようにします。14日間の無料トライアルに登録して、UXワークフローを最適化するためのUXPinの内蔵されている機能をさらにご体験ください。

UX監査チェックリスト

UX監査チェックリストは、監査人が必要な準備から最終的な監査報告書までを行うものでなければなりません。 UXPinの23ポイントUXチェックリストは、最終製品に到達する前に一般的なデザインの問題を回避し、全体的なユーザーエクスペリエンスを向上させるのに役立つはずです。また、この23項目のチェックリストは、監査用チェックリストを作成する際のガイドラインとして使用することもできます。

UX監査を成功させるための5つのヒント

1. すべて記録する：メモを取り、スクリーンショットを撮り、指摘された問題へのリンクを提供する。これらの記録は、忘れ物をなくし、関係者に徹底的で実用的なフィードバックを提供するために役立ちます。
2. 整理整頓：製品の規模によっては、メモ、画像、測定基準など、多くのデータを収集することになるでしょう。分析データの整理と分析にはスプレッドシートを使用し、スクリーンショットなどの対応する資産はクラウドストレージを使用して保存しましょう。
3. 行動可能な推奨事項：あなたが特定した問題を解決するために、ステークホルダーができる行動を提供します。これらのアクションは、推測や仮定ではなく、実際の洞察に沿ったものでなければなりません。
4. 正確であること：報告の際には、具体的な問題、問題の所在、修正するための推奨事項をステークホルダーに伝えること。
5. 発見した問題に優先順位をつける：ステークホルダーに対して、特定した問題の重要度を知らせます（例：低、中、高）。通常、問題の深刻度やユーザーエクスペリエンスへの影響に基づいて優先順位を付けます。

まとめ

定期的なデザイン監査は、製品がユーザーエクスペリエンスとビジネス目標にどのように合致しているかを判断するために不可欠です。初めてUX監査を行う場合は、明確なUX戦略を持ち、監査員がベンチマーク、目的、およびKPIを測定できるようにする必要があります。 ヤコブ・ニールセンの10個のユーザビリティ・ヒューリスティックは、監査人が製品のコンポーネントと機能をテストするための素晴らしい基礎を提供します。監査人は、これらのユーザビリティヒュリスティックを使って、製品を客観的に眺め、ユーザーの視点から質問をする必要があります。

UX監査 UXPinの改善

UXPinを使ったUXオーディットの改善方法を3つご紹介します。 コードベースのプロトタイプ。UXPinのコードベースのデザインエディターにより、最終製品のような外観と感触の忠実度の高いプロトタイプを作成することができます。監査役はこれらのプロトタイプをユーザビリティスタディに使用し、データと分析に基づく仮定をテストすることができます。 コメント UXPinのコメント機能により、監査役はユーザーインターフェース上で直接問題を記述し、タスクを割り当てることができます。

内蔵アクセシビリティ： 監査役は、コントラストチェッカーや失明シミュレーターなどのUXPinの内蔵アクセシビリティ機能を使って、製品のアクセシビリティをすばやく評価できます。

世界最高のユーザー・エクスペリエンスデザインツールを使い始める準備はできましたか？14日間の無料トライアルに登録して、UXPinのコードベースのデザインツールがどのようにUXワークフローを改善し、顧客により良いユーザーエクスペリエンスを提供できるかをぜひご体験ください。

The post UX監査 -知っておくべき考えとは – appeared first on Studio by UXPin.