web-dev-qa-db-ja.com

PSDモックアップとHTMLモックアップの長所/短所

通常のPSDモックアップではなくHTMLモックアップに目を向けている記事( これ および これ )を最近読みました。

記事では、彼らは特定の長所を引用しています:

  • 変更が大幅に速くなりました(色の変更、フォントの変更など)。
  • ページをHTMLとしてレイアウトする場合、最終製品がどのように見えるかに非常に近いものをクライアントに表示します。
  • ウィンドウのサイズを変更することで、液体レイアウトの効果を確認できます。

短所:

  • すべてのビジュアルデザイナーがHTMLでモックアップを作成できるわけではありません。それは二人の仕事でなければなりません。 HTML担当者とPhotoshop担当者。

どちらのアプローチでも、賛否両論は何だと思いますか?

24
milesmeow

Webサイトまたはアプリケーションを構築している場合、できるだけ最終製品に近い形式でモックアップを設計するため、HTMLモックアップははるかに優れています。これにより、期待をはるかに簡単に設定できるようになり、最終製品で可能なことだけに制限され、柔軟性が大幅に向上します。

この慣習は徐々に「ブラウザでのデザイン」として知られるようになりました。ブラウザーでの設計は、その性質上、ウォーターフォール方式を回避します。 Photoshopのモックアップは、ビジュアルデザイナーとインタラクション/ UXデザイナーの間に障壁をもたらします。Photoshopで作業する人は遠く離れており、最終的な製品や付随するブラウザーの制約を考慮することなく、視覚的な忠実度を完全に考慮して配置できます。 photoshopのモックアップの準備ができると、UXチームに渡されて次のステージに進みます。これは、反復的なフィードバック指向のプロセスを促進するものではありません。

私は ブログ投稿 を数か月前に書きました。ここで私が参考にしたいくつかの役立つ記事があります(リンクしたMegan Fisherによる記事を含む)。

他のデザイナーや開発者は彼に同意します:

  • 37signals ' Photoshopをスキップする理由 はプロセスを説明しています。Photoshopのモックアップはインタラクティブではありません。アプリの流れを感じさせるものではありません。早い段階で詳細に集中することをお勧めします。
  • Meagan Fisherの24ways.orgの記事 Make Your Mockup in Markup は、Clarkeの原則について詳しく説明しており、HTML構造から始めて、デザイナーが複数のページレイアウトをすばやく反復できることを説明しています。
  • これら ブラウザーでの設計に関する12のヒント Design Shackでのオーバーは、いくつかの優れた洞察も提供します。
18
Rahul

それは忠実度の問題です。

問題は、焦点を合わせている内容によっては、どちらのドキュメントも他のドキュメントより忠実度が高くなる可能性があることです。

HTMLプロトタイプは、中程度の複雑さのインタラクションさえも本当にモックアップする唯一の方法です。 PSDファイル内でインタラクションデザインを完全に文書化する方法はありません。

逆に、ビジュアルデザインが常に微調整/改善/反復されている環境では、PSDがビジュアルデザイン要素を処理するためのより良い「記録のドキュメント」である可能性があります。

結局のところ、それはPSDとHTMLの違いではないと思います。プロジェクトとチームメンバーごとのニーズの詳細に応じて、両方の量が必要です。

13
DA01

HTMLモックアップを使用することの潜在的な欠点の1つは、たとえそれが何であるかをクライアントに伝えたとしても、クライアントがアプリケーションを完成したと考える可能性があることです。

真剣に、実際の製品を構築するために通常使用するツールを使用してモックアップを見たときに、クライアントとマネージャーの両方を知っている人がいます。実際に作業を行うのに数週間(またはどれほど長い)か。

モックアップを1ステップ削除すると、この誤解を解消できる可能性があります。

ただし、動的モックアップを使用すると、システムの動作方法とアプリケーションのナビゲート方法をクライアントとユーザーがよりよく理解できるようになります。

7
ChrisF

インタラクティブなモックアップを準備するのはビジュアルデザイナーの仕事ではなく、UI/UXデザイナーの仕事です。正しい-多くの場合、主に予算上の理由により、それらは同じものですが、仕事は大きく異なります。

あなたの質問は実際にはStatic vs. Dynamicモックアップと言い換えることができます。

私の意見では、動的モックアップはほぼ静的モックアップより常に優れています:

私の意見の主な理由は、それらが正確なユーザビリティテストに使用できることです-何かをしていることを想像することは、実際にそれを行うこととは大きく異なり、かかる時間、クリックの量、移動などを実現します。システム内の流れの実際の感触。

ただし、代償が必要です。動的なモックアップを作成するには、通常かなり時間がかかります。さらに、1つのボタンを押してシステムで何かを行うと、すべてのボタンが同じように機能することが期待されます(一部はメインシナリオとの関連性が低い可能性があります)。

静的モックアップを使用すると、顧客と開発者にユースケースを案内するのが簡単になる場合があります。画面を1つずつ「正しい」順序で表示し、すべてのユースケースは意図したとおりにカバーされています。動的なものを使用すると、ユーザーに「あまりにも多くの」自由が与えられ、主要なユースケースを見逃してしまう可能性があります。

ちなみに、HTMLモックアップを作成するためにプログラマーである必要はありません。プログラマー以外の人がこのようなモックアップを作成できるツールはたくさんあります(たとえば、Axure、Balsamic、Flair Builderなど)。

5
Dan Barak

レスポンシブデザインの人気が高まっているため、動的モデル(おそらくHTML)を使用することはmoreでさえ理にかなっています。初期の大まかなレイアウトを設計するとき、私は常にブラウザのサイズを変更して、多くの幅でレイアウトがどのように機能するかを確認しています。

静止画像でレスポンシブデザインを指定しようとすることは不可能であり、複数の静止画像でそれを表現することは時間がかかり、過度に複雑です。

2
obelia

事例の答え

最近、Photoshopでメインテンプレートが設計されたサイト(以下、「PS」と呼びます)で作業しましたが、サイトの個々のセクションを設計する必要がありました。非標準のUI要件を持ついくつかのセクションで作業していて、Photoshopでモックアップするか、HTML/CSSでそれらを実行するかを決定する必要がありました。私は後者を選びました[〜#〜] very [〜#〜]感謝しました。

実際には、ページのコンテンツとナビゲーション要素をHTMLでマークアップすることから始めました。それを手に入れたら、CSSを試してみて、何が効果的かを見てみました。私は非常にすばやくいくつかの完全に異なるレイアウトを作成し、実際にブラウザーでそれらをすぐにテストすることができました。ほとんどすぐには機能せず、すぐに放棄できることがわかっていたいくつかのオプションがありました(通常はPSでデザインを完成させていました)。 Photoshopでは不可能だったインタラクティブ(表示/非表示など)の要素も追加できました。

たとえば、HTMLとPSの比較でwayより速くなるものがあります。セルとヘッダー内に可変のテキストコンテンツを含むPSのテーブルを視覚的にデザインするには、実際の努力が必要です。これはHTMLで超高速であり、実際にどのように見えるかを実際に確認できます。

もちろん、CSSですべてを行うことはできないので、これは今のところあなたを手に入れるだけです。たまにPhotoshopに戻って特定の部分の画像を作成することもありましたが、大部分はCSSだけでできることを見て驚いたのです。

私の見解

私はまだこれをケースバイケースで取ります。しかし、私は間違いなく将来的にHTMLモックアップに傾倒するつもりです。

2
jessegavin

VBは最初、いくつかのモックアップをすばやくノックアップする方法として作成されたと思います...そのことを念頭に置いて、「正しい」答えはおそらくHTMLモックアップの道を進む。

しかし、私はタイプしているときに新製品のモックアップを作成している最中です。率直に言って、PSD形式のように見栄えの良いhtmlモックアップを作成することに伴う努力は価値があるとは思えません。複雑なレイアウト設計を使用して、テキストや画像などを希望する場所に正確に表示するには、同じレベルのスキルを持つフォトショップアーティストよりも、Web開発者に長い時間がかかります。

また、テキストや基本的なデザインだけでなく、Photoshop(または同様のグラフィックスパッケージ)を使用してそのデザイン作業を行うことになります。問題を複雑にするのはなぜですか。

確かに、インタラクティブなモックアップを使用する正当な理由がある場合(たとえば、特定のインタラクティブなディスプレイがどのように機能するかを示す大規模なユーザーグループ)、追加の努力は価値があります。

しかし、アプリケーションのいくつかのウィンドウがどのように見えるかをクライアントに示しているだけの場合、余分な労力の正当化がそこにあるとは思いませんか?

1
Sk93