web-dev-qa-db-ja.com

開発者が曖昧さを取り除くためにユーザーシナリオを作成する最良の方法は何ですか？

多くの場合、ユーザーシナリオがあいまいであり、開発者が製品チームと連絡を取って、どのように機能するかを正確に把握したり、さらに悪い場合には、さらに悪い場合には、以下の形式を実装したりしています。それがどのように機能するかを自分で決める。

ユーザーストーリー

アーカイブのユーザーとして
アーカイブしたメールを個人用メールボックスに送信したい
so個人のメールボックスに存在しなくなった可能性のある電子メールに対応できます

シナリオの例

  1. ユーザーがForward（Anchor 1）（内の検索結果パネル1内でクリックする
  2. システムは、を含む確認モーダル1を返しますフォーム2
  3. ユーザーは、フォーム2に自分のメールアドレスを入力して、「送信」（送信ボタン2）
  4. システムはSuccess Modal 1を返し、フェードアウトします（アニメーション1を参照）
  5. システムは、を含むアーカイブ検索ページを返します検索結果の受信トレイ検索結果パネル1

これらの各シナリオには、Invisionウォークスルー、アニメーションなどが付属しています

次に、上記のすべての要素が、新しいHTML要素の測定値と仕様情報の概要を示す個別の静止画像とともに、以下のカテゴリで参照されます。

カテゴリは次のとおりです。

  • ページ
  • パネル
  • テーブル
  • フォーム
  • モーダル
  • アラート

私の質問は、これがこれを行うための最良の方法ですか、それとも開発者にドキュメントを提供するより良い方法を誰かが勧めることができますか？

scenarios
3
David Saunders

ユーザーストーリーはそのように書く必要があります-それらは短く、機能の本質に非常に焦点を当てています。私は彼の本のUser Story MappingでJeff Pattonのアプローチを好みます。

ただし、アジャイルプラクティショナーはドキュメントを好まない傾向がありますが、ユーザーインターフェイスとユーザーとユーザーインターフェイスの間のやり取りには非常に詳細があるため、ある程度の「ドキュメント」が役立つ場合があります。

AxureやBalsamiqなどの設計ツールは、インタラクティブな動作をすばやくデモンストレーションできるため、他の形式で説明する必要がある量を減らすことができます。 Axureを使用すると、フロー図を作成してUI要素にメモを追加できます。また、本当に必要な場合は、デザインからドキュメントを生成することもできます。

結局のところ、これはコミュニケーションの問題に他なりません。どのようにデザインの意図を伝えるか、それは会社ごとに異なります。

理想的には、開発者と同じ場所に配置されるので、開発チームと緊密に連携する適切な方法を選択するのは非常に簡単です。

また、デザインは自分で行うものではなく、開発者との間のcollaborationであることに注意してください。

1
SteveD

BDD言語（Given、When、Then ...およびそのバリアントCucumberおよびGherkin）を使用してシナリオを指定することを考えましたか？

Scenario: Eric wants to withdraw money from his bank account at an ATM

Given Eric has a valid Credit or Debit card
And his account balance is $100
When he inserts his card
And withdraws $45
Then the ATM should return $45
And his account balance is $55

チームがそれに興味を持っている場合、これは自動テストフレームワークとうまく連携します。

https://en.wikipedia.org/wiki/Behavior-driven_developmenthttps://en.wikipedia.org/wiki/Cucumber_（software）

1
kerr

何度か言及された側面を強調したいと思います-デザインはコミュニケーションの仕事です。まず、ユーザーとのコミュニケーションであり、次に開発者とのコミュニケーションです（その間、プロジェクトマネージャーとのコミュニケーションです:-)。

つまり、どのような形式のドキュメントでも、あいまいさをすべて取り除くことはできません。デザイナーは、デザインだけでなく、その意図についても開発者と話す必要があります。理想的には、開発者はすでにユーザー調査に参加しています。

「開発者は多くの場合、製品チームに連絡して明確にする必要がある」という文は、設計者が何を望んでいるかを見つけることが開発者の仕事であるように聞こえます。これはユーザー中心の方法論ではなく、逆です。私の見解では、設計者は設計を作成するときに製品ユーザーだけでなく、設計を伝達するときに設計仕様ユーザー（つまり開発者）も考慮する必要があります。

デザイナーがユーザー中心の手法を製品デザインにのみ適用することがあるのは興味深いことです。内部でコミュニケーションをとるときに同じ考え方を使用しないのはなぜですか？開発者ができる限りデザインにアクセスできるようにすると、使用量が増えます（これは、ユーザーがすべての製品機能にアクセスできるようにすることと同じです）。

あなたの質問に戻りますが、ユーザー調査から製品の発売まで、開発者と定期的に（繰り返しと呼ぶ）話し合うことは避けられないと思います。

0
virtualnobi