ワイヤーフレームの変更をチームメンバーに配信する方法
私は小さなプロジェクトチームでインタラクションデザイナーとして働いています。製品は開発中であり、まだ一般にリリースされていません。
最初は、製品のすべての機能が1つのドキュメントのワイヤーフレームで設計されています。この場合はPowerPointです。ドキュメントには、チーム全体が理解できるように十分な情報が含まれています。
これはすべて正常に機能しています。開発者とデザイナーはドキュメントを見て、それを設計および開発します。
アプリケーションがユーザーと一緒にいくつかのテストを実行できる状態にある場合は、それをテストします。もちろん、テスト後に、いくつかの対話を変更する必要があります。
- 時々私はドキュメント自体でそれを変更し、サーバーから新しいバージョンをプルするようチームメンバーに伝えます。
- 時々私はバグを埋め、開発者に通知されます。
- ときどき、3枚の新しいスライドを1人にメールで送信して作業します。
- 時々私は人の変化を共有します。
私はこの状況に遭遇し続け、誰かがこれに対処する方法についていくつかのヒントを持っていることを望んでいました。
新しい変更について、あなたとあなたのチームメンバーにどのように通知しますか？チームメンバーに変更をどのように伝えますか。書類はどのように注文しますか？私を助けることができるツールはありますか？
ワイヤーフレームを正規の場所に置くことは、混乱を避けるための最良の方法です。ワイヤーフレームをフィーチャに分割する傾向があります。私は通常、一度にサイトの1つの機能/セクションに取り組んでいます。これにより、巨大なマスタードキュメントの問題を回避できます。
開発者に連絡する場合は、開発者が取り組んでいるストーリーにワイヤーフレームをアップロードします。ワイヤーフレームを更新したら、ストーリーを新しいもので更新します。
チームの残りのメンバーは、basecampやバックパックなどを使用して、それらを1か所で保存および更新します。
さらに一歩進んで、ホストされたバージョンのbalsamiqモックアップであるmyBalsamiqを使用しました。彼らはバージョンの変更を追跡し、ユーザーからのフィードバックを持っています。私にとって、それはこの問題を解決する最良の方法でした。ストーリーに特定のバージョンを添付して、機能の作業を続けることができます。
私のアドバイス：
しないでください！
悲しいかな、あなたが説明しているのは、他のものすべてのソースドキュメントとしてワイヤーフレームに依存しているチーム構造におけるほぼ普遍的な問題です。
私見、ワイヤーフレームはアイデアを紙に書き出すことを目的としています。ラフスケッチです。早い段階で簡単に修正して、みんなのアイデアをまとめるのは簡単です。
その時点で、UXチームが製品の構築プロセスを開始するためのベースラインドキュメントになります。ワイヤーフレームは「完了」し、今後の設計変更（それらの多くは変更されます）はワイヤーフレームの外側で処理する必要があると考えます。ワイヤーフレームの維持は時間と組織の負担が大きいという単純な理由からです。
理想的な世界では、チームは巨大ではなく、管理しやすいサイズであり、アジャイルプロセスに参加する全員が更新を処理できます。
いつもそうであるとは限らないこと、そして私たちの多くが膨大な量の紙のドキュメントを作成することに熱中している大規模な組織に行き詰まっていることは避けられないことを理解しています。そのような状況では、私は他の人が言ったことに同意します...理想的には、ワイヤーフレームは誰もがライブでアクセスするWebページです。更新が必要な場合は、その1つの場所が更新され、デフォルトで全員が最新バージョンを取得します。 HTMLでない場合、ユーザーがバージョンをオフラインにして完全に同期しなくなるリスクがあります。
確かに、それを機能させるには、HTMLスキルを備えたUXチームが必要ですが、これは多くの組織でもう1つの問題です。 ：/
Visioでワイヤーフレームを作成するときは、スクリプトを使用して目次を自動生成します。次に、レイアウト名を微調整して、「-」または「+」を付けることにより、マイナー/メジャーな変更を示します。スクリプトは、前の目次とカラーコードを各行と比較します。小さな変更は緑になり、大きな変更は青になり、新しいページは赤になります。
プロセスはツールよりも重要です！コミュニケーションとワークフローの適切な構成により、使用するツールに関係なくワークフローが機能します。
4shared.comを使用してファイルを共有し、必要に応じて設定を構成します。誰かがドキュメントを更新すると、チーム全体に通知が送信されます。