第5章-3 - uecklab @ ウィキ

5.3.3

• 全部
  • 担当 mid'k'

（Before the interview ...）
　インタビューの前に、ＵＸチームのメンバーは、ユーザーのフィードバックを必要とするより重要なスプリントにおいて作業の要素のどれが実行されるべきかを見極める。
（Ideally, all UIs ...）
　理想的には、全てのＵＩはユーザーによってテストされるだろう。すなわち、実際には、チームはしばしば、限られた資源の使用によって取引を作っている。
（If a UI ...）
　もし、ＵＩが率直、あるいはユーザーが持っているものと類似しているなら、そのタームは時間を浪費するために十分必要でないと決めるかもしれない。
（But parts of ...）
　しかし、新しく、技巧的なＵＩの一部分は、新しい反復の例を説明するか、あるいは、特別な振る舞いか、起動しているコードにおいてテストされる必要のあるＵＩの要素を知見する。
（For these parts ...）
　それらのＵＩの一部分のための場所が、『道を叩くゴム』である。すなわち、その実装は、実際に予測した通りに働くデザインと十分に一致しているか？　
（Or are they ...）
　あるいは、コードを起動するための翻訳が、システムの有用性の欠陥あるいは変更を十分に説明出来ただろうか？

（The UX team ...）
　ＵＸのチームはまた、トラブルの箇所が存在している次のスプリントや段階において実装されるためのストーリーに焦点を当てる。
（Which stories implement ...）
　ストーリーは、強く相互作用する、あるいは成功か失敗のために詳細化されたビジュアルデザインに強く依存しているという理由のために徹底的にテストされていない、あるいは紙面上での試作化が十分に出来なかったＵＩのどれを実装するだろうか？
（Or are they ...）
　あるいは、全面的な初期のリサーチによってカバーされているユーザーのタスクのための新しいストーリーなのだろうか？
（The UI design ...）
　それらのストーリーのためのＵＩのデザインは、次のスプリントの開始前に始まり、ユーザーによってテストされる必要があるだろう。

（To test the UI ...）

それらのストーリーのためのＵＩをテストするために、ＵＸチームは最後の、そして完全に翻訳されたビジュアルデザインを開発し、そしてユーザーによってどのように試作するのかを選択する。

（If interactivity is ...）
　もし相互作用が問題でないのなら、彼らは翻訳されたＵＩを印刷し、それらをユーザーに紙面で公開するかもしれない。
（Otherwise, they build ...）
　さもなければ、彼らはより多くの、あるいはより少ない、完全に相互作用した試作品のための単純で平坦なイメージによって知れ渡っているオンラインの試作品の構造を造る。
（Remember, this is ...）
　覚えておいてください。これはチームの責任です。
（It is reasonable ...）
　ＵＸチームのメンバーが彼ら自身で制作するよりも、開発者が、彼らと一緒により相互作用する試作品を造るために協力することは理にかなっている。
（That is just ...）
　それは、単なるストーリーの代価のひとつである。

5.3.4

• 全部
  • 担当 mishi

5.3.4　THE SPRINTINTERVIEW

The interview is ….
インタビューは以下に対して実行される：インタビュアーはユーザに対して彼ら自身と彼らのフォーカスを紹介する。
They tell the user …..
彼らは彼らがテストとどのようにプロトタイプサポートのタスクをしたいかをシステムの要素のユーザに知らせる。
Then the interviewer gets …..
その後インタビュアーはユーザ作業の概要を取得し、十分な指向とどのようにプロトタイプを紹介するかについての理解を取得します。
During this initial ….
この初期導入時の間に、インタビュアーはどの様に彼らがインタビューを実行するかと何を彼らがカバーするかについて計画します。
If the team needs …..
もし、チームが新しい設計のテストが必要な場合、インタビュアーはペーパープロトタイピングモードになります。
Sometimes the prototype …..
時々、プロトタイプは実際にペーパーの中では、フェーズ０の間で開発されたプロトタイプより詳細で正確である。（変かも・・・・）
If so, the ……
もしそうだとすると、インタビュープロセスは似ています：ユーザ自身の現実世界の例の中を歩き、どの様にして作業の中でユーザがプロトタイプのサポートをするか話し合われ、修正され、問題に対してその場で変更されたものは発見されます。
An online prototype, ….
オンラインプロトタイプはもちろん、少ない柔軟性はあります。
But the interview …..
しかし、インタビューはまだ特定の過去のイベントをフォローし、それらをリプレイしプロトタイプシステムを使用する。（※この訳は完璧変です）
Interviewer and user …..
インタビュアーとユーザは何らかの問題とどの様に彼らが修正するかを話し合います。
The interviewer ….
もし、重要な変更が行われている場合はインタビュアーは解決策をスケッチすることが出来ます。
It is possible ….
チームが作業のタスクを理解するために必要なことはチームにとって新しいか、彼らが新しい詳細を必要とするかどちらかが可能である。
If the user …..
もし、ユーザがタスクを行う場合、インタビュアーはCIモードへ移動する。
Using observation of …
レトロスペクティブアカウントを構築するための問い合わせと進行中の観測をしようして、インタビュアーはこのユーザによってタスクが行われているかを発見します。
This data is ….
このデータは実装のためのインタビューノートの中でキャプチャされ、後の解釈セッションでチームによって解析される。
A typical session ….
一般的なセッションはインタビューの全ての３つのスタイルを組み込むことが出来るでしょう。
The interview ….
インタビューは２時間程で計画されているが、問題の範囲を調査する時間は十分である必要があるが、ユーザーに時間を遂行させるのが困難になるように計画されるべきではない。（変かも）

5.3.5

• 全部
  • 担当 end

THE INTERPRETATION SESSION
解釈セッション
As with CIs and paper prototype interviews , the data from the interview is analyzed in an interpre-tation session .
CIと紙プロトタイプのインタビューと同様に、インタビューからのデータは、解釈セッションで分析されます。
The UX team and any part of the full project team that is interested goes through the events of the interview , in order .
UX チームと興味を持っている完全なプロジェクトチームのどんな一員でも、インタビューのイベントを経験します。
The team writes notes to capture issues and also validations .
チームは問題、更には確認を捕えるためにメモを取ります。

Afterwards , the team evaluates the results of the session .
その後、チームはセッションの結果を評価します。
Any notes about a proposed design - a design for a story that has not yet been implemented - are used to change the design and , eventually , produce a revised prototype .
提案されたデザインについてのどんなメモ（まだ実行されていないストーリーのための計画）でも、デザインを変えて、結局、修正されたプロトタイプを生じるのに用いられます。
Notes identifying issues in the last sprint are more complicated .
最後のスプリントで問題を識別しているメモは、より複雑です。
The team redesigns the interface to solve the problem and writes a story card to represent that fix .
チームは、問題を解決するためにインタフェースを再設計して、その修正プログラムを表現するために、ストーリーカードを書きます。
The story card will be prioritized in the next sprint planning session .
ストーリーカードは、セッションを計画している次のスプリントにおいて優先します。

This is the preferred method of handling rework .
これは、再処理を取り扱う好ましい方法です。
Some teams prefer to do rework through the bug fix process , treating Ul problems as bugs to fix .
一部のチームは、バグフィックスプロセスを通じて調整することを好みます、そして、Ul問題を修正するバグとみなします。
This can work , but tends to bury UI problems with the rest of the bugs , and it breaks the rule of doing no work without a user story to justify it .
これは動けるが、残りのバグに関するUI問題を埋める傾向があります、そして、それを正当化するために、ユーザーストーリーを除いた仕事をしないという原則を破ります(?)。
In truth , large bug lists are a danger sign on an agile project .
実は、大きなバグリストは、アジャイルプロジェクトで危険な兆候です。
They represent technical debt ;
それらは、技術的な負債を表します;
worse , any priority 1 bugs on the list mean that the system is not , in fact , ready to ship at the end of the sprint .
更に悪いことに、リストに載っているたった一つのバグでも、システムが、実際、スプリントの終了後に導入する準備ができていないことを意味します。
It is better to prioritize fixing them into the next sprint , even if other user stories have to be put off.
たとえ他のユーザーストーリーが延期されなければならないとしても、それを次のスプリントに優先して取り付けること方がよいです。
And it is better not to add to them with UI changes that could be handled through the user story process .
そして、ユーザーストーリープロセスによって取り扱われることができたUI変化でそれらを増さないことは、よりよいです。

Note that this way of working requires continual customer visits throughout the sprints .
この働き方がスプリントを通して継続的なカスタマー訪問を必要とすることに注意すべきです。
This is inevitable if user feedback is to drive iterative change .
ユーザーフィードバックは、反復的な変化を引き起こすことであるならば、これは回避不能です。
An effective customer team will have someone charged with recruiting users and planning visits .
効果的なカスタマーチームには、ユーザーの募集や計画的な訪問によって告発される誰かがいます。
Many teams find it simplest to plan these visits ahead of time , on one or two fixed days of the week .
多くのチームは、1週間のうち１～２の固定日に早め、訪問することが最も単純なプランであるとわかります。
Then , rather than scrambling to set up a user visit once they have something to test , the team scrambles to finish their prototypes in time for the next visit .
それから、一旦彼らがテストするのを持つならばユーザー訪問を準備するために急ぐよりはむしろ、チームは次の訪問に間に合って彼らのプロトタイプを終えようとします。
The first approach creates delay waiting for users to respond and arrangements to be finalized .
最初のアプローチは、ユーザーのレスポンスと手配を待っている遅延をつくります。
The second encourages progress , as designers work to get enough in place to make the visit productive .
デザイナーが生産的に訪問することによって、満足のいく取り組みを行い、セカンドアプローチは進展を促します。