メンタルモデルによるデジタル製品開発

こんにちは、Habr！ 米国の同僚によるブログの「 メンタルモデルを使用したデジタル製品の設計 」で非常にクールな記事を見つけ、翻訳してここに公開しました。 この記事の著者はデザイナーのティム・シェーナーです。 デジタル製品の開発に携わるすべての人に読むことをお勧めします。

プロジェクトチームで相互理解を達成するための最良の方法。

翻訳が難しい

かつて、インドを旅して、私は安価な本を買いました-ドストエフスキーによる英語の罪と罰。 私はこの傑作を喜んで読むことを楽しみにしていましたが、最終的には大変な苦労でそれを打ち負かしました。 喜びの代わりに、私は当惑しました：なぜそれが賞賛されるのですか？ 後で判明したように、私が読んだテキストは元のソースからはほど遠いものでした。 このことを知ったのはバンコクに着いたときだけで、そこで読んだ本を古本屋に売ろうとしました。 翻訳がひどいので、彼はそれを必要としないと言った。



このケースは、翻訳は簡単な作業ではないことを示唆しています。 うまくやることは難しいだけでなく、専門家だけがうまくやっていないと判断することができます。 人間の操作を自動化するデジタル製品を開発する場合、最も複雑な方法で翻訳に対処する必要があります。 まず、人の作業の観察結果の類似した結果を、コンピューターが解釈できるデジタル形式に変換する必要があります。 次に、チームのエンジニア、デザイナー、製品マネージャーにとって同じことを意味する言葉でアナログからデジタルへの変換を説明する必要があり、それらはすべて異なる用語を使用してアイデアを策定します。 ドストエフスキーの話は、同じレベルに移動しても意味を維持することはそれほど簡単ではないことを示していますが、そのようなレベルのデジタル製品を開発するときは2つあります。

ソリューションは、モデルを一緒に構築することです

デジタル製品を開発する際の翻訳の難しさに対する私のアプローチは、最初に翻訳する必要がある情報の量を最小限にすることです。 これを行うには、最初からチームメンバーが5つのメンタルモデルを一緒に構築する必要があります。

1. ユーザーモデル：対象者
2. 価値モデル：なぜ有用なのですか？
3. 相互作用モデル：使用方法
4. オブジェクトモデル：どのように配置されていますか？
5. データモデル：この状態を管理する方法

この回路を「デジタルマシン」と呼び、次のように表示します。







これらの5つのモデルは、プロジェクト参加者の心の中に無意識の前提として常に存在します。 このような仮定は混乱の主な原因であるため、提案されたスキームは、人々が共通の言語を見つけ、効果的に情報を交換し、頭の中で発展したアイデアを議論するのに役立ちます。



ソフトウェアは実際にはデジタルマシンであるため、私のアプローチは有効です。

ボルトではなくビットで構成され、スチールで作られているのではなくコードで具体化されていますが、それを使用する感覚（つまり、使いやすさ）-いずれにせよ、すべてが考えられている場合-と同じソースから来ています任意のマシン：デバイスとオペレーターの関係。ここでは、重要な問題を解決するための簡単な導入情報が有用な結果に変換されます。



デジタル製品の開発において機械との類似性を引き出すことで、物理オブジェクトに適用されるのと同じ視覚的および空間的ロジックに頼ることができます。



つまり、デジタル製品の内部構造を見たり触ったりすることは不可能であり、開発中に機械との類似性を引き出しますが、物理オブジェクトに適用される同じ視覚的および空間的ロジックに頼ることができます。 また、空間的思考と比thinking的思考は非言語的能力であるため、一緒に構築されたこのようなモデルは、異なる見解を持つ参加者によって容易に知覚されます。



これでデジタルマシンスキームの目的がわかったので、各モデルについて詳しく見ていきましょう。

ユーザーモデル

ユーザーモデルは、デジタルマシンを使用しているユーザーを示します。 これは人間の行動のモデルであり、目標、行動、感情を定義します。 どのプロジェクトでも、これは特定の特性を持つ架空のキャラクターです。







トーマスは実在の人物のようですが、そうではありません。 あなたは人気テレビ番組のヒーローを生きている人々と見なしますが、実際には彼らは役を演じる俳優です。 開発チームにとって、架空のユーザーは特定の人物です。会議に参加しない限り、誰もが顔と名前で彼を知っています。 秘Theは、写真と名前を使用すると、モデルが生き返り、感情移入の自然な傾向のおかげで仕事をするということです。



私たちが他の人とコミュニケーションを取り、仕事をするために、他人の行動を正確に予測するのに役立つのは共感です。 たとえば、トーマスのお気に入りの色がオレンジ色であることに今日合意した場合、もちろん明日もオレンジ色になります。 トーマスについて話し続けると、彼の好みとニーズについて共通の理解が得られます。彼が好む色だけでなく、私たちが彼のために開発したデジタルマシンに期待するものも。 この一般的な理解は、関数を追加または削除することの価値を判断するために、しばしば無意識に使用する基準になります。

価値モデル

デジタル製品-人のように-良い第一印象を与えるチャンスは1つだけです。 価値モデルは、この印象があなたの観点からどのようにあるべきかを決定します。



彼女はユーザーに次のように伝えます。

1. この製品は何ですか？
2. どうすれば私の生活が楽になりますか（より面白く、より効率的になりますか）。
3. なぜこの特定の製品を購入/優先/使用する必要があるのですか、それについて特別なことは何ですか？

最初の質問は、これはどのような製品ですか？ -最高レベルのユーザーのフィルターとして機能します。 トーマスは忙しいので、彼は非常に迅速に、そして大部分はあなたの車を特定のカテゴリーに直観的に分類します。 その後、製品の他のすべての印象は、このカテゴリに関する期待に依存します。 まず、彼は、あなたが録音ツール、画像編集プログラム、バス停で時間を過ごすおもちゃ、友人と通信するためのメッセンジャー、またはデータ分析システムを作成したかどうかを判断します。 トーマスが適切なカテゴリーに興味を持っているなら、彼はあなたの価値モデルの残りを研究します;そうでなければ、彼は時間を無駄にしません。



値モデルは、次のステートメントとして表すことができます。

[製品名]はユーザーエクスペリエンスのカテゴリであり、

それは私にそのような利点をもたらします（そして、そのような理由のための代替ソリューションよりも優れています）。

最後の部分は括弧で囲まれています。理由を簡単な文で説明することが常に可能であるとは限らないためです。 これらの特徴的な機能を定義することは非常に重要ですが、多くの場合、ユーザーにそれらを伝える最良の方法は、相互作用モデルを介して暗黙的に行われます。



パラドックスは、価値モデルが最も理解しやすく、記述が最も難しいことです。 最も難しいのは、ユーザーエクスペリエンスを作成する組織ではなく、個人の価値を定義する言語を見つけることです。 個人にとっては、何らかのタスクや組織の遂行を簡素化することが重要です。収入を得るか、戦略的な目標を達成することが重要です。 人の価値は主要であり、組織の価値は導き出されます。組織は、人の価値を生み出すことに対する報酬として価値を受け取ります。



最も難しいのは、ユーザーエクスペリエンスを作成する組織ではなく、個人の価値を定義する言語を見つけることです。



この問題を解決するには、2つの重要な手順を実行する必要があります。 まず、より広いビジネスモデル内にデジタルマシンを精神的に配置します。この場合、当社の製品は、消費者に対する組織の全体的な価値提案の1つのコンポーネントにすぎません。 第二に、説得力のある価値モデルを作成するには、人間指向の開発手法を適用し、ターゲットユーザーに似た人々を直接引き付けることで、一緒に構築する必要があります。

相互作用モデル

対話モデルは、人がデジタルマシンの状態をどのように変更するかを決定します。 このモデルは、デジタルマシン回路の2つのコンポーネント（人間とアルゴリズム）の対話として表すことができます。 このダイアログでは：

• マシンの状態を変更するためのオペレーターのアクション-
• これはアルゴリズムへの入力です。
• 応答して結果を生成します。
• オペレータからのフィードバック信号として知覚される
• 車の状態が変わったこと。

ユーザーはデジタルマシンと対話して特定のタスクを実行し、この相互作用によりデジタルマシンの状態が変化するため、対話モデルの目的はデジタルマシンの状態を変化させることであると言えます。



相互作用モデルのこのような理論的理解は、以下で説明するオブジェクトモデルおよびデータモデルとリンクするために必要ですが、これはその設計への最良のアプローチではありません。 この場合、相互作用モデルをストーリーとして提示する方がはるかに優れています。



Amazonで本を購入するそのようなストーリーの例を次に示します。

1. amazon.comにアクセスします。

2.本を見つけます。

3.詳細な書籍情報を表示します。

4.本をバスケットに入れます。

5.注文します。

各段階で、システムと対話し、テキストを入力し、リストから項目を選択するか、ボタンを押してアクションを実行します。 システムは、私から入力を受け取ったことを確認する視覚的なフィードバック信号を発行して応答します。 履歴の各段階で、システムの状態が変化します。 最後に、世界的な変化が起こっています。私は本を買いました-システムはそのタスクを完了しました！



人が目標を達成する方法を説明するストーリーの別名は、ワークフローです。 ワークフローは履歴であるという考え方は、ヒューリスティックのように機能します。相互作用モデルを単純なもっともらしいストーリーとして説明できない場合、設計は完了していません。



別の重要な考えは、相互作用モデルは常に複雑な階層構造であるということです。 上記の例を展開すると、これを説明できます。

1. amazon.comにアクセスします。

2.本を見つけます。

2.1。 [検索]ダイアログボックスを使用します。

2.1.1。 [検索]ダイアログボックスにカーソルを置きます。

2.1.2。 テキストを入力します。

2.1.3。 部分一致ドロップダウンリストのオプションを表示します。

2.1.3.1。 利用可能なオプションのいずれかを選択します。

2.1.3.2。 検索結果のリストを参照します。

2.1.4。 部分一致のドロップダウンリストのオプションを無視し、[戻る]ボタンをクリックします。

2.2。 検索結果のリストを参照します。

2.3。 本のタイトルをクリックします。

3.詳細な書籍情報を表示します。

4.本をバスケットに入れます。

5.注文します。

追加の詳細が追加されると、完成したソフトウェアの動作を相互作用モデルがより明確に説明することがわかります。



このモデルを一連の階層的に関連するストーリーとして提示することにより、これらのストーリーをランク付けし、ワークフローに必要なストーリーと有用であるが必須ではないストーリーを決定できます。



インタラクションモデルはユーザーがソフトウェアで何をするかのストーリーを伝えるため、プロジェクト参加者はこの特定のモデルについて議論するのが最も簡単であり、理解に役立ちます。 危険なのは-そしてこれがほとんどのソフトウェア開発プロジェクトの問題-チームが相互依存モデルにあまりにも早く、無謀に焦点を合わせ、それが依存する他のモデルを適切に説明しないことです。

オブジェクトモデル

これまで、ユーザーに関連付けられたデジタルマシンのコンポーネントと、ユーザーが製品を使用した経験について説明してきました。 オブジェクトモデルとデータモデルを使用すると、物事の技術面を議論できます。



デジタルマシンのすべてのモデルは重要ですが、オブジェクトモデルは、マシンの「詳細」とそれらの関係を定義するため、最も重要です。 これを例で説明しましょう。 自転車に乗るためのシミュレーションゲームを作成することにしたとしましょう。 オブジェクトのモデルを設計するとき、まず自転車を想像する必要があります。 自転車の詳細はすべて表示できますが、必要なのは自転車と道路と相互作用するものだけです。



オブジェクトのこのような分析を実行する便利な方法は、相互作用モデルをストーリーの形式で提示し、重要な名詞を識別することです。



サイクリストが自転車に乗るとき、彼は足をペダルに乗せてシートに座り、 ハンドルバーを手で保持します。 彼は、 重力の影響を受けて出発点から目的地に到達しないように 、つまり旅行をするように、 傾斜角とハンドルを特定の範囲で制御することによって自転車を制御します。

これは次のように表すことができます。







または、よりコンパクトな形式で：

旅行

>車両

>サイクリスト

>自転車

>ハンドル

>ターン

>傾斜角

>位置

>出発点

>目的地

この表現は、モデル内のオブジェクトとその相互作用の両方を明らかにします。 相互作用モデルで既に発見した階層構造は、2つのモデルが相互接続されているため、当然ここに表示されます。 相互作用モデルのストーリーが詳細であるほど、関係に入るオブジェクトの記述の粒度と精度が高くなります。 逆もまた真です。オブジェクトをサブオブジェクトに分割すると、相互作用の履歴がより詳細になります。



オブジェクトのモデルを図式的に描くことは非常に便利ですが、デジタルマシンには最終的なタッチ、つまり状態データを収集するメカニズムがありません。 この問題はデータモデルによって解決されます。

データモデル

データモデルは、名前と値のペアという単純な原則に基づいて構築されます。 つまり、データを表示するときに、各パラメーターに名前が付けられ、特定の値が割り当てられます。 多くの場合、値は数値で表されますが、テキストでもかまいません。



最初に名前を書き、次に値を書くのが慣例です。例えば：

x = 3

π= 3.14

色=緑

都市=サンフランシスコ

名前と値のペアにより、ステータスデータをキャプチャすることができます。 この例で自転車にこの原則を適用すると、次のように記述できます。

位置：{

緯度：'37：78 '、

経度： '-122：42'

}

オブジェクトの状態を記述するペアは、多くの場合、オブジェクトのプロパティと呼ばれます。 同じように続けて、次のように書くことができます。

トリップ= {

車両：{

サイクリスト：{

名前：「トーマス」

}、

自転車：{

ハンドル：{

ターン：「12」、

チルト角： '3'

}

}、

current_position：{

緯度：'37 .78 '、

経度： '-122.42'

}、

}、

開始点：{

名前：「サンフランシスコ」、

位置：{

緯度：'37 .78 '、

経度： '-122.42'

}、

宛先：{

名前：「ロサンゼルス」、

位置：{

緯度：'34 .05 '、

経度： '-118.42'

}

}

}

これは、ゲームのデータモデルです。 マシン内のすべてのオブジェクトの状態を個別に修正することにより、マシン全体の状態を修正します。



自転車の速度と方向を制御しているとユーザーが感じるために、ゲームコントローラーに入力するデータを数値に変換し、それらを使用してデータモデルを更新し、これらの状態の変化を視覚情報に変換する必要があります。彼がフィードバック信号を受信できるように。







したがって、私がチームで行う開発と実装に関するすべての作業は、ユーザーにいくつかの数値パラメーターを変更する機会を与えることに帰着します。 これを理解すると状況が明らかになり、同時に慢さを混乱させます。

まとめると

「デジタルマシン」とは、デジタル製品を5つのモデルの集合として説明する図です。

1. ユーザーモデル：対象者
2. 価値モデル：なぜ有用なのですか？
3. 相互作用モデル：使用方法
4. オブジェクトモデル：どのように配置されていますか？
5. データモデル：この状態を管理する方法

このスキームは、プロジェクト参加者が人間のニーズを有用な製品に変換する複雑なプロセスに3つの側面で対処するのに役立ちます。

1. デジタルマシンのモデルによって設定される通信のルールは、無意識の仮定と仮定を明らかにし、プロジェクト参加者の合意の程度を評価することを可能にします。
2. 設計プロセスはより柔軟になります。これは、各モデルを個別に処理し、それらを一緒に再構築し、統合システムとして評価するためにしばらく時間がかかるためです。
3. デジタルマシンのモデルを構築するプロジェクト参加者は、想像力と空間的思考のために能力を活用し、製品の仕組みを理解するのに役立ちます。

これらの線に到達する場合、あなたはデザイン理論の深刻な部分を学びました。 しかし、私にとってこのようなアプローチの適用は決して理論ではありません-私は毎日この仕事を私の仕事でうまく使っています。 私は常にモデルについてチームに伝え、ボードにそれらを描き、プレゼンテーションにそれらを含め、各プロジェクト参加者がモデルについて議論しやすいように最善を尽くします。 これにより、最初は新しいチームで不器用になりますが、コミュニケーションの効果は劇的に向上し、元ボスの一人が私にこう言ったとき、私は非常に喜んでいます。あなたがいつも彼らについて話していたこと、それはずっと速く起こりました。」



モデルに関する私の考えを読みやすくするのを手伝ってくれたIan ShenとRaymond Sutejoに感謝します。 難しい質問をしてくれたカリフォルニア芸術大学の元学生にも感謝します。 答えを求めて、デジタルマシンスキームを開発しました。

文学

デジタルマシンとそれを構成するモデルを発明したのは私ではありません。 私のメリット（または欠点）は、この概念を記事で説明し、イラストを提供したという事実にのみあります。 デジタルマシンとそのコンポーネントをさらに詳しく知りたい人のために、いくつかのソースを挙げます。

デジタルカー

他の技術と同様に、デジタルマシンの開発は、第二次世界大戦中に敵のコードに侵入して対空砲の誘導システムを改善する必要があったときに、より洗練された殺害方法を探すことから始まりました。 1945年、Atlantic誌は、 As We May Thinkというエッセイを発行しました。 その著者であるアメリカ人のエンジニアであるVannevar Bushは、最初に、考えられる車について幅広い読者層に語りかけました。 1948年に、クロードシャノンの記事「数学のコミュニケーション理論」が公開され、測定可能な機械的量と見なされた情報の最初の科学的特性が示されました。 さらに、サイバネティックス入門の本であるWilliam Ross Ashbyを読むことをお勧めします-これは簡単な読書ではありませんが、最高の-厳密かつ手頃な-デジタルマシンの定義を提供します。



2011年に出版された Jeff JohnsonとAustin Hendersonによる 「 Conceptual Models：Core to Good Design 」という本に特別な注意を払うことをお勧めします。 著者は絶対に正しいアプローチを説明していますが、トレーニング、情報交換、および実装の目的では、モデルのモジュラーシステムを使用する方が簡単だと判断しました。

モデル、一般情報

古代人が洞窟の壁に絵を描いたとき、世界の理解を単純化するのに役立った最初のモデルが現れました。 主に設計に関するこの概念のより現代的な解釈は、2009年に出版されたHugh Dubberly Model of Modelsの本に含まれています。

ユーザーモデル

ユーザーモデルは、インタラクティブなデジタル製品、環境、システム、およびサービスの設計の実践で長い間使用されてきました。 トピックに関する最高の本-「 インターフェースに関するアラン・クーパー。 インタラクションデザインの基礎 」（フェイス3：インターフェースデザインの要点について）。 Frank Longの記事「 製品設計におけるペルソナの使用」は、ユーザーの集合的な肖像が共感を高め、それによって設計効率を高める条件を示す独創的な実験について説明しています。

価値モデル

この記事で説明されている価値モデルは、2010年に発行されたAlexander OsterwalderとYves Pigneによるビジネスモデル生成の本：A Vision of Visionaries、Game Changers、and Challengersに記載されている価値提案の概念に直接関連しています。



IDEOは2011年に、 ヒューマンセンターデザインツールキットをリリースしました。これは、開発途上国の新しいソリューションを刺激するオープンソースツールキットで 、ターゲットモデルを選択して価値モデルを構築する方法を説明しています。

相互作用モデル

他のプロジェクト参加者と一緒に説得力のあるストーリーの形で相互作用を記述することは、非常に難しいタスクです。 この作業における大きな助けは、Jeff Pattonの「 User Stories 」の本です。 アジャイルソフトウェア開発の技術 」（ユーザーストーリーマッピング：ストーリー全体の発見、適切な製品の構築）、2014年にリリース。

相互作用モデルのさまざまなオプションについて説明しているHugh Dubberly What is Interactionの記事を理解しておくと便利です。

オブジェクトモデル

このようなモデルの構築については、Sofia Wojciechowski Object-Oriented UXの記事で詳しく説明されています。



2017年7月25日



オリジナル記事