UXとデザインスペック
私は大きなmコマースプロジェクトに取り組んでおり、チーム内で無駄のないUXの原則を適用しようとしています。残念ながら、私は開発チームがデザイナーと同じ場所に配置されていないという事実に制限されており、私が毎週のやり取りを作成しようとする限り、彼らは各スプリントの最後に仕様を受け取ることを好みます。
私は、プロジェクトの成功を損なうことなく、このドキュメントに入る作業量を最小限に抑える仕様を作成する方法を検討してきました。
現在、Axureを使用して、ワイヤーフレーム、デザイン、および相互作用などの注釈を配置しています。次に、PDFを作成します。これは開発者向けに印刷します。デザインやUXに変更があるたびに、このドキュメントを再作成する必要があるため、これは本当に時間がかかり、効果がないことがわかります。印刷してくださいや。。など。
誰かがこれを行う別の方法を試しましたか？理想的には、すべての人がアクセスでき、リアルタイムで変更でき、同じ場所にいないチームに簡単に配布できる、生きたドキュメントであるスペックを備えたオンラインWikiを入手できるようにしたいと思いますか？
誰もが同じ状況を経験し、いくつかの洞察を持っていますか？
この「リーン」部分の場合：設計ドキュメントを次のように分割します。
- スタイルガイド-常に最新
- 個別のデザイン-目的を果たした後、最新の状態に保たれていません。
WikiまたはConfluenceは、デザインからスタイルガイドにリンクできるため（また、ConfluenceおよびJiraを使用する場合は、開発チケットをデザインに直接リンクできるため）、ドキュメントに最適です。
開発チームが毎日のスクラムミーティングを行う場合、チームで機能する場合は、Skype経由で呼び出す可能性があります。
Axureを使用している場合は、すでに Axure Share に公開するアクセス権があります。注釈とメモは引き続きページですぐに利用でき、誰でもいつでもアクセスできます。ワイヤーを更新して再公開すると、同じURLが使用されるため、生きたドキュメントのようになります。
私はいつもこれを使用しており、チーム間でアイデアや仕様を共有するのに非常に役立ちます。公開から公開に変更する内容については非常に明確である必要があることに注意してください。これをページのメモなど、グループ間のコミュニケーションに最適な方法で含めることができます。
仕様のオンラインWiki
「コンポーネントライブラリ」の使用を検討してください。最初のセットアップには時間がかかりますが、プロジェクトを効率化することができます。アイデアは、個々の要素を文書化することです。たとえば、検索フィールドのデザインパターンがあるとします。このパターンをコンポーネントライブラリに記述し、ビジュアルを追加し、理想的にはサンプルプレゼンテーションレイヤーコードを追加することもできます。次に、この要素に名前/番号を付けて、ワイヤーフレーム内で参照します。
誰もが同じ状況を経験し、いくつかの洞察を持っていますか？
うん。いつも。これはまだ（悲しいことに）企業生活の「規範」です。企業のプロジェクト管理と開発は、依然としてウォーターフォール手法に深く関わっています。彼らにとって、「アジャイル」は「より速い滝」を意味するだけであり、そのため、ドキュメントが重いシステムになります。一部はCYAですが、一部は頑固さのためです。
私はプッシュバック以外に魔法の解決策はありません。押す、押す、押す、押し続ける。私たちが行ったいくつかのこと：
- axureで「スケッチ風」モードを使用して、開発者に早い段階で表示します。作成中のソリューションの策定を支援できるように、レビューに参加するよう要求します。これは、彼らに後でより多くの負担をかけます。
- Axureで注釈を付けます（ページに直接メモを追加するだけです）。それはプロジェクトのメモを置く場所であり、他のドキュメントの山を作成しないことを主張します。
- サインオフプロセスを回避します。これは、ある時点でデザインが「完了」し、それが構築されるという信念があった滝の時代からの別のホールドです。これは決して真実ではないため、「サインオフ」の概念は時代遅れです。
- UX/UI担当者が開発者と進捗状況を確認するように要求します。実際のテストの前にUI担当者がUIの問題を指摘することで、時間と頭痛を大幅に節約できます（特にテストチームがUIに目を向けることはほとんどないため）。
- コンポーネントライブラリで作業します。
私はあなたの幸運を祈ります。 ;）
私が取り組んでいる最近のトライアルプロジェクトは、Axureを使用して中レベルの忠実度のプロトタイプを作成し、Axshareを介して共有しています。これにより、多くのことを書き留める必要なしに、仕様にかなり入り込むことができました。これは、毎日のスタンドアップによって助けられます。次に、終わりに近づくと、デザインが作成されます（PSDで、理想的ではありませんが、それがチームの機能です）。次に、それぞれに最小限の注釈を付けてPDFを作成します。画面。過去に非常に詳細な仕様を作成した人としては、その場しのぎのように感じますが、奇妙なことに機能します。これらはすべてドロップボックスで共有されます（私の見解では、ベースキャンプのほうが良いでしょう）。
ストーリーのあるシステムがありますが、私の経験上、wikiなどは読まれない傾向があります。いくつかの単語とドキュメントは、正しい方法で構築される可能性が高くなります。また、プロジェクトのペースを維持するには、毎日の会議が不可欠です。開発者はアジャイルを使用して作業しており、私は一種の無駄のないバージョンを実行しています。 UXはアジャイルプロセスの外側にあり、スプリントにフィードします（バックログを効果的に補足します）。スプリントでUXを実行しようとしないでください-その方法は狂気です。
この方法は、仕様が網羅的ではないため、ギャップも発見します。全体のストーリーがしっかりしていて、機能の主要な部分が十分に検討されていれば、「ジャストインタイム」で解決できるため、これは問題ありません。
それは本当に、適切なタイミングで適切な量の情報を提供することであり、非常に細かい詳細を1つもカバーすることなく構築を開始することを恐れないことです。
「作成PDF開発者向けに印刷する...」
ではなぜAxureを使うのでしょうか？これは、マシンガンを使ってアリを殺すようなものです。 Axureは、PDFまたは印刷物では実現できない相互作用を示すのに適しています。
開発者がどのように機能するかを見ると、少なくともそれが比較的静的なサイトやアプリではなく開発を求められている場合は、UIを描画する以上のものがあることが明らかになります。
クリック可能なプロトタイプだけを使用する場合のいくつかの問題は、
- ユーザーフローが明確でない（または見逃されやすいコーナーケース）
- 重要な相互作用/機能性は見落とされやすい
- タスクを「完了した」という気持ちはほとんどない
- データ入力/出力のエラー処理を示すのに複雑で時間がかかる
そうは言っても、あなたが求めるものを手に入れるために提供されるべき最低限のセットは
- 各画面の主な相互作用/目的を含むユーザーフローのフローチャート（プロジェクトスコープの概要もわかります）
- 各画面での相互作用の詳細な説明
- ワイヤーフレーム、またはさらに良いことに、クリック可能なプロトタイプ
- 設計の詳細とアセット（PSD、CSS、ロゴなど）
このためのツールはほぼ二次的なものです。それがすべての環境で実行されるツール（つまり、Webベースの優先）であり、既存のログインをサポートしている場合に役立ちます（例としてGoogleドキュメントのGoogleログイン）。より低い障壁は賭けのツールを使用することです
「誰もがアクセスでき、リアルタイムで変更され、流通できる生きたドキュメント...」
開発にはある程度の安定性が必要です。多くの場合、多くの開発時間を無駄にせず、不満につながるため、常に変更する必要はありません。しかし、それが彼らの経験だったのか、それが彼らが恐れていることなのかもしれません。
多くの場合、仕様または特定の形式の要求の背後にある理由についての率直で率直な会話は、懸念を理解し、対処し、代替の解決策を見つけるのに役立ちます。