チャプター5
冒頭
（Given the abobe ...）
前述した、最も良い実践、そして、ユーザーを中心とアジャイルの分野における仕事をするために知られていることが与えられると、アジャイル開発を真にユーザー中心のものにする、あるいは逆に、ユーザー中心の開発をアジャイルにするためのデザインや開発のための全体的な取り組みを建造することが可能となる。
（This approach makes ...）
この取り組みは、ユーザーのリサーチや経験に基づくデザインのための、前述したアジャイル開発のフェイズ０による、一貫したデザインの為の機会を作る。
（With a sound ...）
ユーザーの勝算を理解するための印象を用いると、チームは、よいユーザーストリーを書くことが出来、アジャイル開発のスプリントで彼らが解決する問題を知り、そのための最初の目的を持つであろうと確信することが出来る。
（In the rest ...）
このセクションの残りでは、私たちは、開発の各部分それぞれがどのように、アジャイルメソッドが依存しているＵＸの見方とユーザーの反復両方の実装を組み立てることが出来るかを示す。
（For user-senterd ...）
ユーザー中心の技術のために、私たちは、筆者とカレン・ホルツベルトが共同開発したコンストラクチャ・デザイン（ＣＤ）を信頼している。
（For agile techniques, ...）
アジャイルの技術のために、私たちはチャプター４で記述した最も良いアジャイルの実践を描写し、スクラムとＸＰ両方からのコンセプトを実装する。
フェイズ０：[初期のユーザーリサーチ、可視化、紙面上での試作品のテスト] → [計画の公開] → [スプリント] → [スプリント] → [スプリント] →
図５.１：標準的なアジャイル開発の構造。コーディングは標準的な目標とプロジェクトの構造がフェイズ０に定められた時に始まる。このフェイズは、プロジェクトの展望に依存し、２～８週間の辺りに決めてよい。
5.1
Few projects start …..
いくつかのプロジェクトは完全に白紙の状態から始まります。
Existing products …..
既存の製品とシステムは新しい開発のためのコンテキストを提供します。
An existing product …….
既存の製品は追加の特徴または追加の役割のサポートが必要かもしれません。
The competition may …….
競争は新しい特徴が出てくるかもしれません。そして、企業はキャッチアップするためにスクランブル（奪い合う？）することが出来ます。
An internal system ……
内部システムは再定義されたビジネスプロセスをサポートする必要があります。
A business may …….
ビジネスは多すぎるスタンドアローンツールを使用しているため苦労し、それらを統合しているのかもしれません。
(See Section 6.3 …….
（大きいスコープ―新しい製品開発と大規模なプロジェクト に対処する方法の議論のためにセクション６．３を見てください。）
In each case, ……
それぞれのケースで、開発は、システムの範囲の一般的なアイデアから始まります。これまでのところ、特定のタスクの詳細な契約はどのようにしてこれらのタスクがサポートされるか、または、どのようなシステムの用件かについてサポートされる。
The team is not ……..
チームはまだユーザーストーリを書いていません。―彼らが言うべき契約についてはまだない。また、顧客のチームはまだ十分なユーザーについての信頼できるガイダンスの提供について知りません。
Starting the project …….
フェーズ０のプロジェクトを開始するとチームは自分自身を組織するチャンスと彼らのユーザについて調査する事と彼らが構築する必要がある解決策の種類を理解することを与えられます。
This is the process …….
これは、スプリント中の反復のための基礎となるBPUF―Big Picture Up Fontを構築するためのプロセスです。
5.1.1
5.1.1
CONTEXTUAL INQUIRY AND AFFINITY DIAGRAMS
文脈上の質問(?)とアフィニティ(親和性)図
The first step is to discover how users approach their work .
最初のステップは、ユーザーが自分の仕事へのアプローチ方法を発見することです。
This study of work practice - how people structure and perform the jobs they do - is essential to designing effective systems .
仕事の練習(?)の研究(人々が自分のする仕事を構築して、果たす方法)は、効果的なシステムを設計することが不可欠です。
And the best practice for understanding work practice is Contextual Inquiry ( CI ) .
そして、仕事の練習(?)を理解するための最高の練習は、Contextual Inquiry（ CI ）で す。
In a Contextual Inquiry , project team members interview users in their workplaces , watching them work and talking to them about what they are doing and why .
Contextual Inquiryでは、プロジェクトチームのメンバーが彼らの職場でユーザーにインタビューします、そして、彼らが働くのを見て、彼らが何をしているか、なぜそうしてるのかを話します。
If the project is building a consumer product , the team interviews consumers in their home , cars , stores , or other life contexts , observing the life task the new product will address .
プロジェクトが消費者向けの製品を構築しているならば、チームは消費者の家、車、店、または他の生命のコンテキスト(?)のことで消費者にインタビューします、そして、生活課題を観察して新製品で対処します。
At this point , the primary focus is not on design at all .
この点で、主な焦点は、まったくデザインの上にありません。
The focus is on how people perform the work , what they are trying to accomplish , how they go about it , and what gets in their way .
焦点は、人々がどのように仕事を実行するか、彼らが何を達成しようとしているか、彼らがそれにあたりどのように動くか、そして、何が邪魔になるかです。
Any kind of field research needs some training , but that is no reason for limiting this work to UX professionals .
どんなフィールド調査でもいくらかのトレーニングを必要とします、しかし、それはUXプロの仕事に限ったことではありません。
Developers and other team members can be trained to assist , and even untrained engineers can go along as observers .
開発者と他のチームメンバーは援助するために訓練を受けることができます、訓練されていないエンジニアでさえオブザーバーとして行くことができます。
This supports the agile "one team " value , promotes cross fertilization across team members , and ensures all team members understand the users ' problems at a visceral level .
これはアジャイルの「1つのチーム」の価値を支えて、チームメンバー全体でチームを促進して、すべてのチームメンバーがコアレベルでユーザー の問題を理解するようになります。
The Contextual interview
- P29 2段落目(Throughout...の直前)まで
The first principle of CI is to observe the work directly, as the user works.
CIの第一の原則は、ユーザーが働くように、仕事を直接観察することです。
For traditional work, this means going to the user's office and sitting with them, watching the user interact with online systems and with paper files and forms.
伝統的な仕事では、これはユーザーのオフィスに出向き、彼らと共に座り、オンラインシステムや紙のファイル、フォームに対するインタラクトを見ることを意味します。
The interviewer can see the informal notes and cheat sheets the user has created to help track the job and the piles the user creates to organize and stage a job.
インタビュアーは形式ばっていないメモ書きや、ユーザーが仕事の再現を楽にするために作成したチートシート、ユーザーがまとめ、行なってきた積み重ねを見ることができる。
He or she can see the use of Excel to do the real organization and calculation before loading up the results into the office tool.
彼ないし彼女は、結果をオフィスツールに読み込ませる前に、実際の組織や計算をするためにExcelの利用法を見ることができる
Interruptions and informal communication happen while the interviewer is there, revealing tacit aspects of the work that might otherwise remain unarticulated.
中断や、打ち解けたコミュニケーションはインタビュアーがそこにいる間に起こり、言葉にはされない仕事の様相。
If the task requires moving arround, the interviewer goes with the user, runnning up and down halls, driving to remote sites, crawling through access tunnels,or riding vicycles to get around a huge assembly plant (all real examples, by the way).
もし、タスクが移動することを要求するならば、インタビュアーはユーザーと共に行き、穴を上下に走り、遠隔地に運転していき、トンネルを貼って進み、大きな組み立て工場に自転車でいきます。(ちなみに全て実際の例です。）
If the design is for a comsumerproduct, the interview is conducted wherever the life task is performed:in the home or car, in public, while commuting or shopping.
もしデザインが消費者向けのものであれば、インタビューはライフタスクが行われる場所ならどこでも行われる。例えば、家や車の中、公共の場、通勤中、買い物中など。
Nor is the interviewer constrained to only the events that occur during the interview.
インタビュアーがインタビューの間に起こったイベントを強制されることはない。
Retro-spective accounts give the interviewer a way to recover detailed task information about events in the recent past.
レトロスペクティブアカウントはインタビュアーに最近のイベントについての詳細なタスク情報を復旧する方法を与える。
Together, the interviewer and user replay a specific event of interest, using artifacts and probing questions to reveal the detailed steps of the task.
それとともに、インタビュアーとユーザは、関心のある特定のイベント、成果物の使用、タスクのステップを明らかにするための問題の調査をリプレイする。
In this way, the interviewer can learn about and capture the details of important tasks and situations whenever they happened, as long as it is within the recent past.
この方法では、それが過去最近である限り、インタビュアーは重要なタスクのディティールとそれらが生じたシチュエーションを学び、キャプチャーすることができます。
Throughout the interview,
インタビューを通して、インタビュアーとユーザはユーザが何をして、どうしてそれをしたかについて
プロジェクトのデザインの方向性に何を意味するかについて議論をすることに従事する。
These discussions reveal the
これらの議論はユーザの行動の根底にある（さらに暗黙の知識である）意図や戦略を明らかにする。
Note that the interviewer does not
インタビュアーの文章は仕事の疑問や問題には焦点を合わせない、しかしながらそれらはインタビューで必ず明らかにされる。
Unlike a usability test,
問題の判明にはっきりと焦点を当てた使い勝手よさのテストとは違い、CI（継続的インテグレーション）のゴールは
ユーザの仕事の訓練を理解することだ。
This understanding allows the team to
この理解することは、チームに単に既存の問題の修正をさせるというよりは
むしろユーザの仕事を変える解法を想像することを許可します。
For example,
たとえば、1990年代の間にオフィスでの仕事の訓練のCIはユーザが電話やカレンダー、ローロデックス（<=名詞管理のやつ）、
デイタイマー式の自己管理手帳と一緒に彼らのデスクに集められる傾向にあるとあきらかにした。
This implied that these tasks --
これらのタスク（通信や連絡先の識別やスケジュールやタスクの管理）は仕事の作業中に一緒に行ったことを意味する。
They made a natural whole.
それらは自然全体を作った。
This recognition anticipated by
この認識はここ数年ではアウトルックのような製品でe-mailやアドレス帳や
カレンダーやタスク管理を兼ね備えたものの導入が予想されていた。
CIs give to represent users
CIはインタビュアーにユーザにチームのユーザにに代表する必要があると理解を与えた。
ユーザのタスクや必要に関する知識や、批判的に、その集団のために働くデザイン代替案かそうでないかの第六感。
Internalized knowledge and
内在された知識や第六感は貴重だが、しかし、知識はデザインの基礎になっているなら確保や外部化されるべきである。
That is done in impretation session.
それは通訳セッションで行われる。
The interpretation session
The interpretation session
Data from any sort...
いかなるフィールドリサーチのデータも扱いにくい。
The interviewer's notes...
インタビュアーのメモは長く、構造化されておらず、(そのメモの?)写しは作るのが難しく、理解するのが難しく、もし、ビデオが使われていれば、操作が面倒である。
Interpretation sessions give the team...
解釈セッションはチームにフィールドデータを扱う方法を与える。
In an interpretation...
解釈セッションでは、チームはインタビュアーの詳細なインタビューメモを通して毎回のインタビューを振り返る。
The interviewer retells...
インタビュアーは、合法的にインタビューのストーリーを始めから終わりまで再び話す。
The rest of...
チームの残りはデザイン上に関連があるカギとなる情報を取り込む。
Individual observations are...
個々の観測は、付箋に後に書き込まれたリストにおいて捕捉され、親和性の下でつかわれる。
The work practice...
ユーザーの仕事の実行は仕事のメソッドで捕捉される(5.1.3を参照)
By the end of...
解釈セッションの終わりでは、このユーザーからのすべての重要な情報は書き下され、使う準備がなされる。
From the agile...
アジャイル視点からは、顧客を理解するためにアジャイルカスタマーチームによって利用された覚え書きを(確かに、親和性と作品としても)控えておくことは重要である。
This is not an...
これは、仕事が完了していたあるグループによって作られ、ほかによって消費されたドキュメントでない、そして、それは、アジャイルチームに破門されるだろう。
This process enables...
このプロセスは、アジャイルカスタマーが、「どんなユーザーが、どんな練習をして、したがって、どんなプロジェクトが彼らを助けるために行われるかもしれないのか」を理解するのを可能にする。
5.1.2
p30 5.1.2 THE AFFINITY DIAGRAM
So far, the team has forcused ...
昔から、チームは個々のユーザに焦点を当ててきた。
But products support ...
しかし、製品は個々のユーザではなく、市場全体をサポートする。
Even internal systems ...
内部的なシステムでさえも、その瞬間にたまたましている作業を個々にではなく、役割や仕事をサポートする。
So it is important ...
だから作業の共有の構造、独立した個々のユーザを、ユーザを超えて存在するバリエーションを失うことなく、を見られることが重要である。
Affinity diagrams have ...
アフィニティ・ダイアグラムは構造化されていない膨大なデータをまとめる方法として、広く使われるようになった。
An affinity diagram ...
アフィニティ・ダイアグラムはCIを通してユーザデータを集めることで作られ、すべてのユーザを越えて鍵となる問題を明らかにする。：その作業、ユーザの目的やどのように達成するか、苦しい点、仕事周り、使われたツール、など、の鍵となる要素。
The team builds ...
チームはユーザにインタビューしたあとで、チームを観察し、アフィニティを作る。
An affinity is built from ...
アフィニティは、まず類似した情報をグループにする、それらに分類名を付ける、それらの小さなグループから大きなグループを作る、ボトムアップから作られる。
It is not built by ...
それは大きな分類や予め決められたカテゴリに合わせてデータを整理することから始めるわけではない。
The result is that ..
その結果アフィニティは、よりチームの考えていたアイデアに影響を及ぼさないデータの重要性を反映する。
This is essential to push ...
これは、洞察や新しいアイデアの発見、どのようにデータが集まるかに起因する客観性、を推進することに不可欠である。
An affinty can be ...
アフィニティは１，２日でチームによって作成できる。
5.1.3
（The affinity collects ...）
収集と組織化のアフィニティは、全てのユーザーの学習に由来する。しかし、それは仕事における実践の一貫性の構造を示さない。
（There is no place ...）
タスクの分析を行うアフィニティウォールが存在する場所はない。例えば、その分析はタスクを完遂するためのユーザーの実演のステップを示す。
（There is no organized ...）
仕事が発生する、あるいは人々がそれを完遂するために人工物を使う物理的な環境の組織化された描写は存在しない。
（Work models are the ...）
ワークモデルは、仕事の実践の構造を見せるための適切なツールである。
（They drive design ...）
それらは、異なるデザインの取り組みがどのようにその仕事を支援するだろうか、あるいは支援しないだろうかを提案することにより、デザインの考案に至らせる。
（Work models are built ...）
ワークモデルは、説明のための会議の間、文脈調査法（製品を使うシチュエーションに焦点を当てることにより、ユーザーの隠れた要求を調査する方法）におけるデータの収集により作られる。
（Like the affinity ...）
アフィニティのように、それらは作業の一般的な構造を示すため、ユーザーの中で統合される。
（Contextual Design defines ...）
コンテクスチュアルデザインは、ワークモデルの５つのタイプを定義する。しかし、アジャイルプロジェクトのためのフェイズ０は大抵、初期の場合シーケンスモデルに依存する。
（That is because ...）
これは、より長いプロジェクトの文脈が、市場のリサーチや、ビジネスのプロセスの再構築や、あるいは変更された既存のシステムを通して既に定義されているためである。
（Models that help ...）
より長い文脈を理解するための支援をするモデルは、より焦点を当てられたプロジェクトにおいて必要とされていない。
（If your project ...）
（もしあなたのプロジェクトがそこまで焦点を当てられていないのなら、コンテクスチュアルデザインは、全てのモデル、そしてユーザー中心の方法における概念化と観念化を描写する）
図5.3：デザインの意味合いを明らかにするため、どのように見えない観察者（黄色い付箋）がグループ化されるかを示すアフィニティのセクション。インタビューの間に与えられる写真は、アフィニティの中にまた組み込まれてもいい。
The sequence model
Specific tasks are ……
特定のタスクは分析され、シーケンスモデルで表現され、ほぼ全てのプロジェクトはそれらを構築することになるでしょう。
Sequence models ……..
シーケンスモデルはユーザーが実行する関連タスクの共通の構造を示している。
They show the high …….
彼らは、タスクの高レベルの構造、使用された異なる戦略、ユーザが達成しようとしている事、仕事で問題になっている事を示す。
Sequence models are …….
シーケンスモデルは現在の作業の練習から構築されている。しかし、彼らの重要性は正確である。何故なら彼らは物事を現在の手法で動けなくなっているデザイナーを保つのを助けるためです。（ちょっとおかしいです）
Incremental development ……
インクリメンタル開発はこれまでのタスクの全体的な構造を見たりまたは、どのようにサポートされるかについての根本的な再設計について考えることなしに、いずれかによって修正された痛点（問題点？）の修正に焦点を当てたリスクを実行する。（これもおかしいかも）
Sequence models show …….
シーケンスモデルはユーザーの意図を達成するために必要な多くの面倒なステップを示しています。
They show how different ……
彼らは、どのように異なった戦略が異なる意図を意味するかと、システムの中の異なったアプローチでユーザがもっと直接的に彼らの意図を達成する事が出来るかの提案を示す。
They show how whole …….
彼らは全体のタスクがシステムの制約を克服するかをどのようにして作成されるかと、除去されるかもしれないこれらのタスクについてどのように提案されるかを示す。
By looking at the …..
一緒にタスク全体を見ることによって、彼らは全体の解決策のための修正ポイントについて考えることによってチームを移動する。
Sequence 1: ……
シーケンス１：顧客からのEmailを監視する
U1-1-1 Intent ….
意図：優先的な顧客と販売の機会は迅速に処理される
U1-1-2 Trigger …
トリガ：メールが１時間にわたりチェックされていなかったことを自覚しろ
U1-1-3 Go to …
技術サービスの郵便受けへ言って送り主と題名を調べてください
U1-1-4 Set priorities …..
電子メールを介してどのように働くかのための優先順位を決める
U1-1-5 See a request …….
一部を交換するための勧告のためのリクエストを参照しろ
Figure 5,4 ………
図5.4 シーケンスのステップを示された部分的なシーケンスモデルはキャプチャされる。この特定のイベントが起こった時このユーザによって正確なステップで行われたことは記録されます。
The artifact model
The artifact model .
アーティファクト(人工品)モデル。
People create artifacts to help them do their work .
人々は、彼らが仕事をするのを援助するために、人工品をつくります。
They may keep a list of contact numbers on a piece of paper by their computer ;
彼らは、コンピュータによって紙の上で連絡先番号のリストを保管するかもしれません ;
they may use a spreadsheet to calculate discounts and then circumvent the tool in the system that is supposed to calculate discounts for them .
彼らは、割引を計算するためにスプレッドシートを使用するかもしれないし、割引を計算すると思われるシステムで、ツールを回避するかもしれません 。
Each artifact offers insight into how the user approaches their work and what they need to support it .
各々のアーティファクトは、ユーザーがどのように彼らの仕事にアプローチするのか、そして、彼らがそれを支持するために何を必要とするかという洞察を提供します。
Each artifact offers details for how to get that support right :
各々のアーティファクトは、サポートしている権利を取得する方法の詳細を提供しています：
Exactly what information does the user keep for each contact ?
正確に、ユーザーは接触ごとにどんな情報を保ちますか？
How are they calculating the discount , and how is that different from what the system would have done ?
どのように彼らは割引を計算していますか、そして、どのようにそれはシステムがしたことと異なりますか？
When artifacts are important to the users ' work , it may be useful to capture them .
アーティファクトがユーザーの仕事にとって重要であるとき、それらを捕らえることは役に立つ場合があります。
Sometimes an artifact suggests that the system must do something and do it a certain way , such as calculate a discount a certain way .
時々、アーティファクトはシステムが何かしなければならなくて、特定の方法をそれにしなければならないことを示唆します、例えば、特定の方法で、割引を計算するとか。
Other artifacts provide the exact details needed to implement a story , such as the specific contact information needed by users .
他のアーティファクトは、ストーリーを実行するために必要な正確な詳細を提供します、例えばユーザーによって必要な特定の連絡先です。
Even if the details are not written into the story - and since stories are high-level , they may not be- developers will come asking what to do in the implementation and the UX designer needs to be ready with an answer .
たとえ詳細がストーリーに含まれていない、(そして、ストーリーから高レベルである、そうでない場合もありますが)、開発者は実施において何をすべきかについて尋ねてきます、そして、UXデザイナーは答えを準備する必要があります。
Figure 5.5:An artifact model showing the important aspects of the artifact (a digital camera) and information about how it is used.
図5.5：アーティファクト（デジタルカメラ）の重要な側面を示している人工物モデルとそれが使要されている方法についての情報。
5.1.4
5.1.5
- P35上部3分の1(In the session...の直前)まで
Creating a system vision -
高いレベルでのシステムが何をするかのコンセプトはシステムのビジョンを作ることでの
ユーザの要求を書くことの先駆として必要とされる。
To see why,
理由として、典型的な要求として考えられるのが、ネットワークモニターの役割を手助けするとかかれるだろう
「ネットワークモニターとして、通信回線がキャパシティーの90パーセントに到達するとき私は警告をみるでしょう。
それにより私は速度低下によるネットワークの停止を防ぐことができる。
”No,”Someone might say,
「ノー」とだれかは言うだろう。「そのシステムは自分自身でネットワークの通信量のバランスを回復すべきだ。」と。
”No"another team member might replay.
「ノー」と別のチームのメンバーは返すだろう。「私はそのシステムはそれができるとは考えない。
しかし、私たちは彼らが他にどうすることもできないネットワークの警告のモニタリングを
面倒くさがるべきではない。彼らは圧倒されるでしょう。
Who is right?
だれが正しいのか。
The traditional answer from agile
アジャイルメソッドによる伝統的な答えは、アジャイルのカスタマーまたは製品のオーナーそしてチームは彼らの意見に従うべきだ。
But that is not
しかし、それは私たちにとって十分ではない。
We need to say how
私たちはそれらの役割が理解を深める方法を言う必要があるように彼らは正しく信頼できる答えを与えるだろう。
As we showed above,
上で記したように、そのチームのユーザを代表する人々はまれに実際のエンドユーザとなる。
Even if they were,
もし彼らがいたとした場合でも、エンドユーザ自身は信頼できる答えの与え方を知らないのでしょう。
How should they know if
どのように彼らが圧倒されるかどうか知っているだろうか。
- P35下部3分の1(A vision is built...の直前)まで
In the session...
紙のプロトタイピングのセクションで(5.1.8参照)、私たちは何が正しい答えかをどのように決めるかという疑問を取り上げる。
For now, notice...
今まで、どの話者も、システムは何をするべきか、どのように構造化されるべきか、どんな大規模なサポートの提供をユーザーはするべきか、にたいして、まったく違ったアイデアを持っている。
Should the system...
システムは自動的であるべきか、オペレーターのためにたくさんの仕事をするべきか、否か。
Should we expect...
私たちはユーザーが1日中問題を見つけるために画面の前に座っているのを期待するべきか、それとも、彼らはほかの仕事と一緒に(その事実から?)そらされるのか?
These are the...
これらはシステムを定義する際の基本的な問題点です、(これらというのは、範囲や、目的のワークプラクティスでのインパクト、基本的な機能や提供された構造、振る舞いの詳細などのこと)そして、彼らは、リリース計画の前に解決する必要がある。
Often they are not...
しばしば、彼らはそうはしない、そして、結果は、リリース計画ミーティングがただストーリーカードを書くだけではない。
Participants have to...
参加者は全体のシステムをデザインしなければならず、彼らの頭では、手順のサポートがなく、1回で全体をみる方法がなく、その時、ストーリーカードに暗黙のデザインの結果を書き込む。
This makes for...
これは難しい(困難な?)話し合いで作られる。
Instead, the BPUF
代わりに、BPUFベストプラクティスは、どんなシステムで、何をするためのものなのかを全体的に理解する最初のスケッチの後にリリース計画に入ることを提案する。
The Contextual Design...
それを行うべき文脈上デザインは、チームとして一緒に製品のビジョンを組み立て、そのあとに文脈上の問合せとともにユーザーデータを集めて解析し、親和性を構築し、製品のモジュールを作り上げる。
5.1.6
- 4段落(A storyboard lays out...の直前)まで
（It is possible ...）
視覚から直接ユーザーストーリーを書くことは可能である。
（Each element of ...）
それぞれの視覚の要素は、ひとつ、あるいはそれ以上のユーザーストーリーを取り込むことが出来る。そしてそれは、優先度を決め、アジャイル開発の運用に慣れることが出来る。
（But the vision ...）
しかし、その視覚自体は、まだ有用にはなっていない。
（Any stories based ...）
どのストーリーも、ユーザーに経験され、反復される必要があるであろう視覚を元にしていて、それを正しく習得するために数回の反復を必要としている。
（The lag between ...）
視覚の制作とそのテストの間のラグは、あるいは多くのスプリントの後、長いものになるだろう。
（It is better ...）
ユーザーがすぐに視覚のテストや反復をするのはより良いことである。
（This puts off ..）
これは、アジャイル開発の開始を遅らせるが、最初のストーリーがユーザーの現実の要求を反映することを確かなものにする。
（Less rework will ...）
少ない再処理は、スプリントの間に、ユーザーのフィードバックに応える必要があるだろう。
（In Contextual Design, ...）
コンテクスチュアルデザインにおいて、視覚の概念は、紙で模型を作ることと、ユーザーにそれを反復してもらうことによってテストされる。
（Users can respond ...）
ユーザーは、具体的なユーザーインターフェースを効果的に反応することが出来る。すなわち、抽象的な概念に反応することは、彼らにとって非常に難しいことである。
（A quick, high-level ...）
素早く、高度なユーザーインターフェースのデザインは、デザイナーとユーザーの間のコミュニケーションデバイスとして働く具体的な視覚の描写を提供する。
（Detailed UI desigh ...）
詳細なUIのデザインは、開発のスプリントまで安全に遅らせることが出来る。
（However, jumping directly ...）
しかしながら、視覚からUIデザインへと直接至ることは、欠陥を残す可能性がある。
（The task flow ...）
システムへと差し込むそのタスクは、一貫性があり、ユーザーにとって便利なものでなければならない。
（Unless task support ...）
タスクの支援が直接デザインされない限り、いくつかの活動は支援されないかもしれない。あるいは、いくつかの段階のシーケンスはシステムに上手く差しこまれないかもしれない。
（These ploblems will ...）
これらの問題は、試作段階の反復の間に発見され、処理されるが、それは正面に立たせるよりも遅く厄介なものである。
（Storyboads help the ...）
ストーリーボードは、それらがそのような問題をより速く発見し、処理することを助けてくれるのである。
A storyboard lays out …..
ストーリーボードはどのようにして提案されたシステム内で特定のタスクを完了するかについてレイアウトする。
Like laying out a …..
映画のためのストーリボードのレイアウトのように、各ストーリボードのセルはタスク内のステップがどのようにして実行されるかを示します。
It shows the users …..
これは、ユーザアクションまたは、他のイベントによってトリガされる他のシステムの動作、彼らがとる行動、これらのスクリーンに表示されるデータ、彼らと対話するUIのスクリーンの関係するユーザを示す。
Each storyboard ensures ….
各ストーリボードはタスクが一貫的か、スタートからゴールまで円滑かつ効率的に実行できるか、それがヒューマンプロセスの記録をとる事が出来るか、オフラインシステム、外部システムのユーザが途中で使用する必要があるかもしれない事を確保します。
Each storyboard covers ……
各ストーリボードはシングルタスクとケースをカバーしています。
For example, ….
例えば、ストーリーボードはネットワークを監視する人々がどのようにして停電などの緊急事態に対応し、通知する方法を示しているかもしれない。
Another storyboard might …..
もう一つのストーリーボードは彼らがどの様にして、システムの異なった要素を使用するハッカー攻撃などの異なる種類の緊急事態に対する反応を示してくれるかもしれません。
Other storyboards would …..
他のストーリボードは、タスクをカバーします。
Usually 6-12 …..
通常、6-12のストーリボードは典型的なシステムの主なワークプラクティスをカバーするためには十分である。
A storyboard typically ….
ストーリボードは通常は作成するのに数時間以上かかります。
Figure5.7: A vision:hand-drawn in …..
図5.7：ビジョン：チームの短い対話セッションの中のhand-drawnである。 これは、ユーザーが新しいシステムと対話する方法と彼らのタスクを達成するための行う仕事を外に示しています。
Figure 5.8: A storyboard showing …..
図5.8：ストーリボードはどの様にしてユーザとシステムの間の対話は表示されるかを示す。（カメラはこのストーリボードに設計されています。）
5.1.7
5.1.7
USER ENVIRONMENT DESIGN
ユーザー環境設計
Storyboards keep specific tasks coherent , ensuring that it is possible to go from step to step of the task in the system .
ストーリーボードは特定のタスクの一貫性を持ちます。そして、タスクのシステムにおけるステップ間の移動ができることを確実とします。
But thinking only about individual tasks tends to create systems that are collections of wizards , each focused on supporting one task one way .
しかし、個々のタスクだけについて考えることは、ウィザードのコレクションされているシステム(?)を作成する傾向があります。そして、各々が1つの方法で1つのタスクを支えることに集中します。
Good systems are like houses :collections of rooms or spaces , each supporting a range of activities , each connected to other spaces in the house in ways that make sense for the work people do .
よいシステムは、家のようなものです：部屋またはスペースのコネクションは、それぞれの活動の範囲をサポートし、働く人々のために意味をなす方法で、家の中の他のスペースに各々つながりました。
Houses support many life tasks , many unforeseen by the architect ;good systems do the same .
家は多くの生命の作業を支えます、そして、多くが建築家によって予期せぬことです;良いシステムは同じ操作を行います。
The User Environment Design (UED) gives the Customer Team a way to represent , at a high level , the structure of the system as experienced by the user .
ユーザーによって経験されるように、User Environment Design（UED）はカスタマーチームに、高水準で、システムの構造を表現する方法を与えます。
It docs not show details of appearance or implementation ;instead , it just shows the places in the system and how they connect .
それは、外観や実装の詳細が表示されません；その代わりに、それらはシステムの場所と彼らが連絡する方法を示します。
It is like a floor plan for a software system or the site map for a web site .
それは、ウェブサイトのソフトウェアシステムまたはサイトマップのための間取り図のようです。
Focus Areas are the places in a UED .
フォーカスエリアは、UEDの中の場所です。
Like the rooms of a house , they are experienced as a coherent place .
家の部屋のように、それらは一貫した場所として経験されます。
They will be implemented as a coherent part of the UI such as a screen , page , or pane .
それらは、UIの一貫した一部として実装されます。例えば、スクリーン、ページ、パネルなど。
Each Focus Area has a purpose , the work that it is intended to support .
各々のフォーカスエリアには、目的があります、それが支持することを目的とする作業です。
Each Focus Area provides function , describing what the system shows and does for the user in that place and what commands the place makes available to the user to invoke system behavior .
各々のフォーカスエリアは、システムがその場所でユーザーのために何を示して何をするか、そして、場所がシステムを実施するためにユーザーに対してどんな命令を利用可能にするか、を述べる機能を提供します。
In addition , each Focus Area provides access to other Focus Areas , allowing the user to move through the system .
そのうえ、各々のフォーカスエリアはアクセスを他のフォーカスエリアに提供します、そして、ユーザーがシステムを介して動くのを許可します。
Building a UED for a typical agile project takes 2-3 days .
典型的なアジャイルプロジェクトのためにUEDを造ることは、2～3日かかります。
Figure 5.9 :A partial UED showing the core of an email system .
図5.9：電子メールシステムの中核を示すUEDの部分。
最終更新：2011年06月03日 01:18
