私はAxureを日常的に使用しています。最初は、ワイヤーフレームのすべての相互作用をカバーしていました。もちろんそれは「クリック可能」になります(まあ、おそらくいくつかの要素は除外されますが、これらをワイヤフレーム化すると過労になるか、不適切な認識につながるため、説明する必要があります)。しかし、副作用として、多くのレベル(クライアント、グラフィックデザイナ、プログラマ)では、ワイヤフレームを完全に理解したり、ユーザーフローに逆らったりするなど、十分に関与していないため、これらのアクションは非表示のままです。
それで、私は説明的な方法をとることに決めました。 Axureではアイテムの説明を追加できますが、クリックして説明を表示する必要があります。プログラマーにとっては明らかですが、クライアントにとっては、実際にはクリックするのに十分な関与がありません。そのため、ワイヤーフレームにアクションやラベルを追加する代わりに、Axureでレイアウトをスケッチし、(ラベルのように見えるように)白い文字のオレンジ色のボックスを追加しました。何度も説明ボックスをすべて非表示の動的パネルに配置し、「クリックして説明を表示する」を追加しました。
しかし、このアプローチには1つの大きな問題があります。複数の状態を持つスクリーンをワイヤフレーム化するには、複数の状態をカバーするために、構造内のビューを乗算する必要があります。その結果、構造が特大になり、「なんてこった、それはとても大きくて複雑すぎる」ということになります。クライアントから。したがって、それも完璧なソリューションではありません。 (Photoshopのレイヤーカンプのようなものがここでは便利でしょう...とにかく、インターフェイスをさまざまな状態に切り替えるボタンでカバーできます)。
それから私は両方を組み合わせ始めましたが、今度は再びアプローチを変更して、可能な限り相互作用をカバーし、他の場所に説明ボックスを追加します。また、WIMP後のアイコンをいくつか使用して、ワイヤーフレームのどの要素がクリック可能、スクロール可能、ドラッグ可能かなどを示し、クライアントがワイヤーフレームを確認していることを示します。
私の質問は:
ワイヤーフレームがクライアントによって表面的に見直される状況にどのように対処できますか?
もちろん、それはクライアントが解釈を任されたままの状況にのみ言及し、場合によってはワイヤーフレームを通過しますが、それらと対話する意味でこれらが自明になるようにしたいと思います。
クライアント向けの提案を行っているときにも同様の状況があり、クライアントはAxureの使用に精通しているが、プロトタイピングには使用せず、ワイヤーフレームの作成にのみ使用していました。ただし、この提案では、サイトのユーザーフローを考え出して、Axureを使用してそれをどのように構造化するかを確認するよう求めていました。
私たちが従ったアプローチは
こちらがPDFのスクリーンショットです