チャプター6
In this final section, we discuss typical project situations and how they might appropriately be handled.
この最後のセクションでは、我々は典型的なプロジェクトのシチュエーションと、彼らが適切に処理される可能性があるかを議論します。
We start with simpler situations and work back up to the large, complex projects.
我々は、シンプルなシチュエーションと大規模で複雑なプロジェクトのバックアップから始めます。
6.1 JUMPING ON A MOVING TRAIN
動いている電車に飛び乗る。
UX practitioners are likely to find themselves dropped into a project that is already using an agile methodology.
UXの専門職たちは、既にアジャイルの方法論が用いられているプロジェクトになっていることに気づくかもしれない。
The team may have at least a few sprints under their belt and may be following agile methods more or less faithfully.
チームは、少なくとも2,3のスプリントを持っている可能性があるし、多かれ少なかれ会い忠実にアジャイルメソッドに従っている可能性があります。
The challenge for the UX practitioner is to help them improve how they work with their customers and better integrate the UX work.
UXの専門職の課題は、顧客と共に働く方法を改善し、UXの作業をよりうまく統合する手助けをすることです。
In this case, it is neither possible nor desirable to stop and do all the pre-work of phase 0.
この場合、それは不可能であり、中断してフェイズ0のプレワークを全て行うことは望ましく有りません。
Instead, UX designers should move towards greater user involvement through a series of steps, without ongoing development.
代わりに、UXデザイナーは進行中の開発なしに、一連のステップを通じてユーザーとの関係を築いていけるに違いない。
1. Do User Tests in the Users’ Workplace.
ユーザーの職場でユーザーテストをしろ。
If the team is not currently working directly with actual end-users, start setting up field visits with users.
もしチームが現在実際のユーザーと直接一緒に働いていないならば、ユーザーと実地調査を行いましょう。
Arrange them so that you can see users do real work and understand the real work context.
ユーザーが実際の仕事を行っているのを見られるよう、また実際の仕事の前後関係を理解できるように準備してください。
These visits can be planned ahead, as discussed above, and the exact focus of the interview adjusted to reflect project needs.
これらの調査は、前述のように事前に計画することができます。また、そのインタビューの正確な焦点はプロジェクトのニーズを反映するよう調整可能です。
Initially, use the interviews to prototype UIs that will be needed in this sprint or the next, so that the user data directly informs the development process.
最初に、ユーザーのデータが直接、開発プロセスの情報になるように、このスプリントまたは次で必要とされるプロトタイプのUIへのインタビューを使用してください。
This makes them easier to justify to a possibly skeptical team and management: "We’ve planned this story into this sprint. I want to test it out with customers to get the UI details right.”
これにより、チームとマネジメントが出来る限り懐疑的なチームであると正当化しやすくなります。「我々はこのスプリントにこのストーリーを計画してきた。私は正しいUIの詳細を得る為にユーザーと一緒にテストをしたい。」
If the team currently brings users in to test product iterations, move at least some of these sessions out to the field.
もし、現在チームが製品のイテレーションをテストするためにユーザーをつれてくるならば、少なくともこれらのセッションのうちのいくつかを外に移動しましょう。
Use the customer visits to run hybrid interviews, where part of the visit supports detailed design of new UIs and part provides user test and feedback of completed implementations.
ハイブリッドインタビューを行うために顧客訪問を使いましょう。訪問の一部は新規UIの詳細設計に役立ち、他の一部は実装が完了したものに対するテストやフィードバックを供給します。
Look at the stories to be implemented in the next sprint , according to the release plan.
次のスプリントで実装される要求を見つけるのは、リリースプランに応じる。
Start work on the UX design for those stories.
それらの要求からUXデザインの仕事は始まります。
Mock them up and get some user feedback before the sprint starts.
スプリントが始まる前にそれらを模擬し、何人かのユーザのフィードバックを得る。
If a design is well thought out , make your prototype detailed and test the look and interaction;
if it is a new design for a task you understand less well ,
make a rough prototype and test the basic concept and function .
もしデザインが良く考え抜かれていたとして、プロトタイプを作り、そして、見た目や相互作用のテストをするでしょう。
もし、あなたがあまりよく理解していないタスクのデザインをするとき、
大まかなプロトタイプをつくり、基礎的な概念と機能のテストをするでしょう。
Spend part of the inter view getting feedback on stories for the current sprint.
現在のスプリントの要求のフィードバックを得るのにインタビューの一部を使います。
↓こいつはやばいぜ>)意下訳注意↓
Since users' work hangs together - it is not split into heat little boxes ,
as user stories are - this is natural and easy to do.
ユーザの仕事が一緒にハングされる（ユーザの要求としてのきちんとした小さな箱に分割されない）とき、
それは、自然であり行うことが簡単である。
Typically , organizations collect two kinds of user data:marketing requirements of
wish lists and desires and the results of usability tests.
典型的には、組織は二つの種類のユーザのデータを集めます。
マーケティングは希望のリストや欲望、ユーザビリティテストの結果を要求します。
Once field interviews are happening ,the team can start collecting actual work practice data.
かつて、実地インタビューが起こった。そのチームは実際の仕事の実地データを集めることをはじめた。
Start with observational notes and sequence models for tasks of interest to the project.
関心のあるプロジェクトのタスクの観察ノートやシーケンスモデルを用いてはじめます。
These are straight-forward to capture and can be quickly consolidated.
それらは、簡単にキャプチャーされ、すぐに統合することが可能です。
Use the initial part of the interview as a more general CI to capture this data;
then move into a feedback session on the design or implementation to be tested.
このデータをキャプチャーするより一般的なCIとして、デザインや実装のテストされる
フィードバックセッションに移動するとき、インタビューの最初の一部が使われる。
After collecting work practice data during a few interations , the UX team will have enough to be
worth stepping back and evaluating the overall direction of the project compared with the needs of the users.
2・3の反復の間じゅう仕事の実地データを集めた後に、UXのチームはユーザのニーズとの比較した
プロジェクト全体の方向性のステッピングバックと評価をする価値を十分持っているでしょう。
Either between releases or during a programmer's holiday , consolidate the work practice data ,
building models and an affinity diagram.
実際の仕事のデータを統合する、リリースまたはプログラマーの休日の間、モデルと親和図法が構築される。
Build a User Environment Design of the system as implemented to date and extend
it using the stories not yet implemented.
これまでに実装されたシステムのユーザの環境デザインを構築することとまだ実装されていない使われる要求を拡張すること。
Walk through the data and UED , to identify where the project is failing to address important work issues or
where the proposed implementation seems problematic .
データとUEDをウォークスルーすることで、プロジェクトが、重要な仕事の問題の対処に失敗したときや、
提案された実装では問題があるときに識別されます。
The UX team designs fixes , tests them with users (perhaps using rough paper prototyping) ,
and writes stories to capture these changes.
UXチームの設計の修正は、それらをユーザとテストし（たぶんラフなペーパープロトタイプを用いるだろう）、
そして、それらで変わったものをキャプチャーし、要求を書き直す。
6.2
When an existing...
現存する製品やシステムは、新機能とともに拡張されてきて、フェーズ0はチームにサポートされてきた新しいタスクについて学ぶ機会、(:どのように構造化され、どのような戦略を採用するのか、そして、どんな問題が起こるのか)を与えた。
Contextual interviews and...
文脈上の面接とシーケンスモデル(順序モデル)はチームがこれを理解する利益を助ける。
Example 6.1
Typical problem statements...
技術的問題文は、新規タスクをカバーし、新しい機能セットを追加し、新技術を実装するための現存するシステムを拡張する。
Users need to track...
ユーザーはセンターツールの呼び出しでメトリックをたどったりレポートしたりする。
Users need to be able to...
ユーザーはサーチャーを確保できるようにし、情報ライブラリの中でアラートを設定するためにサーチャーを利用する必要がある。
Users need to organize...
ユーザーはプロジェクトとして調査を整理したどる必要がある。
The team conducts...
チームコンダクターは、彼らが持っている技術とともに現在の方法を使うタスクを行うユーザーと面接する。
During interpretation sessions,...
解釈セッションの間に、チームは、親和性のノートと同様にタスクを表すためにシーケンスモデルを統合するのと同じように、順序モデルをとらえる。
This coherent view...
このまとまったタスクのビューはデザインの洞察力を導く。
It leads the...
それは、チームが、どのように程よくサポートされているタスク全体を理解し、どのようにシステム内の違ったアプローチが、より直接目標を達成するユーザーを助けることができるのか。
The team (including...
チーム(UXデザイナー、開発者、興味をそそられた利害関係者を含む)は違ったオプションを探索し、単純なアプローチに落ち着くためのビジョニングセッション実施する。
Because this is...
新しいタスクにより、それをサポートするための新しいユーザーインターフェースが必要になってきたようだ。
These new interfaces...
これらの新しいインターフェースはペーパープロトタイプを使ってデザインされてテストされた。
Since they are new...
新しくなってから、デザイナーは彼らがいきなり最初のほうで正しいことになると仮定することができない。だから、繰り返しの開発の前にユーザーとともにペーパープロトタイプのいくつかのラウンドをおこなうことは、チームが実際にユーザーメソッドを理解することを理解し、機能するソリューションを持っていることを確実にし始める。
User stories are...
ユーザーストーリーはビジョンと最終のプロトタイプに基づいている。
This process works...
プロセスは、少数ののサポートするタスクが存在するときに機能する。そして、タスクを行うユーザーの役割のセットは制限される。
Interviews need to be run...
面接は最低3つの、タスクへアプローチする範囲を理解するそれぞれの役割の表現とともに行われる必要がある。
6.3
MAJOR NEW RELEASE
When a project is ...
プロジェクトが重要で新たな機能をもった新たな製品やリリースをプランしているとき、そのプロジェクトはドメイン（領域：提供する領域？スコープ？）や展望（将来を心に描く）をソリューション全体で理解するための戦略的デザインからはじめるべきである。
Such a project may make ...
プロジェクトは仕事のプラクティスに重要な変更を与えるだろう、また全体の新しいシステムやインターフェースをデザインするだろう、そして、いくつかの役割やタスクに影響を与えるだろう。
In this case, the limited ...
この場合、フェーズ０の限定的なスコープは市場・問題のドメイン・発展可能性のあるソリューションの範囲を理解するために十分ではない。
Significant new function imples ...
マルチなタスクをサポートする新しいUIのオーバーラップを暗に意味する重要な、まだ理解されていない他の方法の相互作用をする新しい機能
It imples multiple ...
それはマルチな役割を暗に意味する ― 4-6は典型的である。
The team needs to use ...
そのチームは全範囲の調査や、プラクティスやデザインソリューションのコンセプトを理解するためのデザインツールを使う必要がある。
Here is a rough ...
ここでは、どのようにそのようなプロジェクトが構造されることが出来るのか、のおおまかな説明である。
Fuller details on each ...
それぞれの部分のすべての詳細をコンテクスチュアル・デザインから探されることができる。
Example 6.2
Typical problem statements ...
典型的な問題の主題は、戦略的デザインフェーズからスタートする必要性を指し示す。
"We need to be the next ..."
我々は次のiPhoneを私たちのドメインにする必要がある。
"We are purchasing a new ..."
私たちは新しいソフトウェアシステム事業を苦労して得ている。そして、私たちのビジネスをサポートするために、それを注文でつくる必要がある。
"We need to revamp our ..."
私たちは、変化する市場で分配する私たちの製品を、改良する必要がある。
The team needs to ...
チームは、仕事のプラクティスやデザインをもっと徹底的に理解する必要がある。
They will need to start ...
彼らは活発なユーザーリサーチプロセスからスタートを必要とするだろう。
The team should start with ...
チームは、仕事のプラクティスを理解し、次のバージョンに先送りにする(address)ための、タスクやワークコンテキストを見るために、15-30のCIとともにスタートするべきである。
They build a affinty and ...
彼らはアフィニティやシーケンスワークモデルを、問題や最近完了したタスクを表すために造る。
If whole workgroups or multiple ....
もし全体のワークグループあるいは複数のワークグループがサポートされるのなら、彼らはおそらくフローモデルを欲するでしょう、またおそらくはコンテクスチュアルデザイン等からの他のワークモデルを欲するでしょう。
Table 6.1
Supporting a new release ...
８週間のフェーズ０とともに新たなリリースをサポート。
This structure gathers data ...
この構造は3-4の役割をサポートする、１２ユーザからのデータを集める。
If your organization will ...
もしあなたの組織がフェーズ０に８週間をかけることを許容しないなら、これはインタビューの数（また、したがって、サポートされることができる役割の数）を減らすことによって、あるいは、１または両者２つのペーパープロトタイプの試験のラウンドを除外することによって、の改めて詳しく調べられることができる。
Just remember, if you eliminate ...
思い出しなさい。もしあなたがそれらのラウンドを除外したなら、あなたはスプリントの間、ユーザともっと多くのイテレーションを共にする必要があることを予期できる。
（図は頑張って。）
（They respond to ...）
彼らは、視覚的なプロセスを用いたデータに反応する。視覚的なプロセスは、プロジェクトチーム全体と、必要不可欠な鍵となるステークホルダーによる展望を計算し、統合された単一の視点を用いたアプローチをキャプチャする。
（This vision covers ...）
この視点は、その解決法を用いることにより、その内容が変更されるための仕事の訓練全体を高いレベルでカバーするのである。
（Then, because the ...）
この時、その仕事の訓練はより入り組んでいて、タスクとシステムの間の相互作用はより複雑であるために、チームはユーザーとシステムの間の相互作用を処理するためのストーリーボードを使う。
（The storyboards are ...）
このストーリーボードは、システムの構造を見せるためのユーザーエンヴァイオロメントデザイン（ＵＥＤ）において一緒に用いられる。それはすなわち、それらの間のアクセスを用い、ユーザーが携わっているであろう異なるタスクの全てを支援する一貫したスクリーンが機能をどう組織するのか、ということである。
（The high-level system ...）
この、ＵＥＤにおいてキャプチャされる高度なシステムの構造は、おおざっぱなＵＩの開発や、紙面上での試作によってテストされ、そしてユーザーへのインタビューの２ラウンド目でテストする。
（In the experience ...）
筆者の経験において、このテストの２ラウンドは、基本的な構造と機能の根本的な問題を解決する。（詳細化されたＵＩのデザインは、個々のワークストリームによって動作する）
（At this point, ...）
この時点で、全体的な解決法が設計される。
（The high-level function ...）
高度な機能と構造は、既知のものである。
（The solution is ...）
この解決法は、一貫性があり、矛盾がない。そして、ユーザーの仕事の訓練全体の統合された支援を提供する。
（From this high-level ...）
この高度な解決法から、個々のワークストリームは定義されることが出来る。
（Each of these ...）
これらのワークストリームの各々は、それ自体のアジャイルプロジェクトである。
（Each work stream has ...）
それぞれのワークストリームは、５～１５人のチームによって実装することが出来る限定的な視野、そしてより良く定義された発展のための製品を持っている。
（Each work stream does ...）
それぞれのワークストリームは、チャプター５に記載したような仕事をする。すなわち、それらの構成要素の詳細を解決するための、省略されたフェイズ０は、特徴的なストーリーとユーザーによって確認され、反復されたスプリントを定義するための計画を発表する。
（Phase 0 can ...）
フェイズ０は、省略することが出来る。何故なら、その構成要素は戦略的なプロジェクトからのデータとデザインによて設計されるからである。しかし、それらは詳細なタスクの情報と低レベルでのＵＩのデザインを必要とするようである。
（The key point ...）
ここでのキーポイントは、大きく、戦略的なプロジェクトは、単なるシステムの変更よりもプロセスの支援を必要としていることである。
（Agile methods excel ...）
アジャイルメソッドは、良く定義された限定的な視野の製品の制作を課すこと、そして便利な仕事のソフトウェアを素早く制作することに優れている。
（But when the ...）
しかし、その視点がとても大きいのならリサーチやデザイン、そして計画された仕事は、一貫したシステムを造るためのアジャイル開発を優先する必要がある。
[戦略的なデザイン：初期のユーザーのリサーチ、観念化、構成要素のテスト] ＞ [始点の開発の努力；並行的ストリームの計画；ロードマップの定義]
＞ 構成要素のためのフェイズ０ ＞ 計画の発表 ＞ スプリント ＞ スプリント ＞ スプリント ＞
＞ 構成要素のためのフェイズ０ ＞ 計画の発表 ＞ スプリント ＞ スプリント ＞ スプリント ＞
＞ 反復の建築的計画 ＞ 一貫性のクロスシステムのための進行中のＵＸストリーム
図6.1：大きなスケールのアジャイルプロジェクトの構造。戦略的なデザインと計画は、目的を定め、異なる構成要素において並行的なワークストリームを定義する。それぞれの構成要素は、アジャイルのスプリントによって追従するユーザーのデータに基づく詳細な設計を行う。
最終更新：2011年06月24日 15:24
