最終的に、2つの主な質問に対する答えを見つける時が来ました。「誰が責任を負うべきですか？」と「何をすべきか？」デザインとレイアウトの永遠の闘いの中で...
典型的なWeb UI開発ライフサイクル
この記事は、Webインターフェースの開発が実際にどのように行われるのか、誰がそれに参加するのか、正確に何をするのか、何を担当するのかを検討することから始まります。 Webインターフェースの開発のライフサイクルを構築する方法論は多数ありますが、それらはすべて基本的な段階で統合されています。
ステージ1：開発中のインターフェイスの正式な要件の作成。 この段階の最終結果は、レイアウト上に何を置くべきか、どのように実装するかを説明する短いタスクまたは技術的なタスクです。 プロジェクトの役割を持つ人々はこれに携わっています。ビジネスアナリスト、テクニカルライター。
ステージ2：ブリーフまたはTKのグラフィックデザインレイアウトの開発。 この作業は、デザイナー（Webデザイナー、GUIデザイナー）によって実行されます。
ステージ3：グラフィックデザインレイアウトに応じたインターフェイスのレイアウト（html \ css \ JSコードの作成）。 タイプセッターは機能します（フロントエンド開発者、Web開発者）。
自分を基本的な段階に限定し、「真空中の球面状態」でのみ高品質の結果を得ることができます。 実際には、各段階で多くの問題が発生しますが、サブステップを導入し、インターフェイス開発のライフサイクルを複雑にすることで解決する必要があります。
障害から生じる問題とサブステップの例は次のとおりです。
- 一般的なビジョンの欠如または主題領域の理解の欠如-それは、ブリーフまたはTKのテキスト記述に限定されるとうまくいきません。 いくつかのプロトタイプを作成し、追加の調査を実施する必要があります。
- 見栄えの良いインターフェースは使いにくいかもしれません。 これを回避するには、作業にユーザビリティスペシャリストを関与させ、使いやすさなどのために追加の検査を実施する必要があります。
設計レイアウトの品質を評価する際の客観性の問題から始めて、発生する問題とその解決方法について詳しく説明します。
正式な設計評価の問題
Webインターフェースの設計とは、インタラクションの設計とWebページの外観の設計に取り組むことを意味します。 外観は、グラフィックデザインレイアウトで便利に伝えられます。 つまり 設計作業は、レイアウトの作成に帰着します。
概して、レイアウトの評価は主観的です。 多くの場合、美しい、いい、楽しい、きちんとした、そして接頭辞が「not」であるそれらの変形などの言い回しに基づいて構築されます...レイアウトの品質は個人の好みによって判断されます。 問題が発生します：主観的な基準に従って、一般的にレイアウトを正式に評価することは可能ですか？ できます。 そして、最も効果的な方法は、フォーカスグループのテストです。対象オーディエンスからの人々のグループが募集され、レイアウトが開発され、デモンストレーションが実行されます。その後、調査参加者はアンケートに記入し、これらの主観的なパラメーターに関する個人的な意見に基づいて推定値を設定します。 平均値は、レイアウトの品質の適切な評価です。
このフォーカスグループテストは実際にどのくらいの頻度で行われますか？ 残念ながら、めったにありません。 通常、デザイナーと顧客の個人的な意見に同意することになります。 さらに、経験によると、請負業者は常に自分の仕事を適切に評価できないため、顧客は役に立たない、または品質に有害な意見さえ持っています。 その結果、エンドユーザーは苦しんでいます。そのため、レイアウトが作成されているように見えます。
正式なレイアウト評価への別のアプローチは、「Steve Jobs Principles」とも呼ばれるユーザーインタラクションの原則に基づいています。
開発者はユーザーの意見を考慮せず、ユーザー自身がユーザーのニーズを決定します。なぜなら、 開発者は状況を全体的かつ適切に見ている専門家および専門家であり、ほとんどの場合、エンドユーザー自身は自分が望むものを知らず、以前は疑っていなかったニーズを満たす結果しか味わえません。
これらの原則によれば、家庭用コンピューターの時代の初めに、アップルは競合他社の製品の「正方形の実用的な」外観とは対照的に、これらのまさにPCをデザインアートの作品に変えるソリューションを作成しました。 消費者自身は、コンピューターのようなそのような実用的なものがスタイリッシュなデザインの決定になりうるという事実を望んでいることに気付いていませんでした。 しかし、消費者の意見を考慮に入れていないデザイナーによって作成された実装を見た後、彼らはそれにもかかわらずそれを高く評価しました。 しかし、これはWebページの外観の開発に戻る別の話です...
はい、多くのデザインスタジオは、中央アジアの代表者からのフォーカスグループなしで、同様の原則に従ってレイアウトの評価に取り組んでおり、レイアウトがどうあるべきかを独自に決定し、非常に成功した高品質の結果を得ています。 すべてはフォーカスグループと同じです。ここでは、同じ分野で働いている数人の経験豊富なデザイナーで構成されるエキスパートグループのみが組み立てられ、レイアウトも提示され、評価されます。
しかし、繰り返しますが、実際に実行するデザイナーと顧客以外の少なくとも誰かで構成される専門家グループは、実際にはどのくらいの頻度で集まりますか？ これについてはすでに話しているようです...
設計レイアウトの品質の正式な評価は可能ですが、実際にはめったに実行可能ではありません。 個々の評価は主観的であり、これは、Webインターフェースの開発に関する他の問題の中でも特に...
グラフィックレイアウトの感覚とWebページのレイアウトの不一致
字幕で聞こえる問題は、Webデザイナーの間でよく知られています。
レイアウトがどれほど高品質で詳細に描かれたとしても、グラフィックイメージのままであり、「デッド」レイアウトとも呼ばれます。 動的な要素（ドロップダウンメニュー、影のクリックの変更など）がないWebページデザインを開発している場合でも、レイアウトは最終ページとは異なる感じがします（静的ページでもテキスト、スクロール、その他）。
この問題と使いやすさの懸念。 グラフィックレイアウト（要素の場所やレイアウトの評価など）を使用して、ユーザビリティの専門知識を部分的に実行することもできますが、インターフェイスの便利さを完全に理解でき、操作する際のすべての落とし穴を特定するために、最終的な完成したWebページのみを使用できます。
ここで、デザイナーとレイアウトデザイナーの両方の別の不幸-コンテンツの不足があります。 簡単に言うと、「ページ上のテキストがあり、写真があります」と書かれています。 そして、それはどんな種類のテキストで、どんなサイズで、いくつの段落と見出しが入っていますか。 どんな絵があるのか、どんなカラースケールであるのか、どんなプロポーションがあるのかは示されていません。 次に、設計レイアウトで「魚」（スタブ）を使用する必要があります—サードパーティのテキスト、写真。 レイアウトにも使用する必要がある場合があります。 そして、最終的な作業コンテンツが既にページに配置されている場合、最終結果に恐怖を感じ、
最初の設計レイアウトが肯定的に評価されたとしても、最終結果の評価はさらに悪化する可能性があります。
Webインターフェイスを開発するときにこれらの問題をすべて回避する方法
最後に何がありますか？ レイアウトのN番目のバージョンを描き、「レイアウトの要件をより正式に設定する必要がある」と正当に宣言する、熱烈なデザイナー。 それほど面倒ではないレイアウトデザイナーがM回目にページをめくる。 この状況は、長期間、期限の失敗、予算の超過、そして「誰が責任を負うべきか？」および「何をすべきか？」という永遠の質問によって補完されます。
Webインターフェイス開発のライフサイクルの標準モデルを変更することで、このすべてを回避できました。 少し調整すると、次のようになります。
ステージ1：コンテンツの準備。
ステージ2：開発中のインターフェイスの機能と正式な要件の説明を含む簡単な概要を作成します。
ステージ3：使用される条件（ブラウザで直接）でインターフェイスを迅速に開発し、すぐに完成したWebページとして、専門家とユーザビリティの継続的な評価を行います。
すべての問題は自然に消滅し、最終結果は常に高レベルになります-Webインターフェイスの開発の既存の一般的なライフサイクルと比較して、開発の時間とコストが数倍削減されます。 問題は、なぜ誰もがまだそのような成功したスキームを使用していないのですか？ 実際、今このアプローチは勢いを増しています。
これは、記事の冒頭で示したリンク（ http://habrahabr.ru/post/238485/ ）に記載されていましたが、ここで再度複製します。
- サンクトペテルブルクWSDでは、ほとんどのレポートがこのトピックに当てられていました-http ://webstandardsdays.ru/2014/06/28/ ;
- これは、BEMupのAlpha Lab（ https://tech.yandex.ru/events/bemup/6-september-2014/talks/2189/ ）のAnton Vinogradovによるレポートで述べられており、Yandexアプリケーションレイアウトの例を使用してトピックを調べました。タクシー
- PSの休息に関するイリヤ・プハルスキーの報告（ https://vimeo.com/85995812 ）も同様の問題を明確に説明しています。
その記事のテキストとそれに対するコメントで、論文が、そして最も重要なことには、このアプローチの実装方法が表現されました：「デザイナーがタイプセッターになり、インターフェースを既製のレイアウトとしてすぐに開発する必要があります。」
同じ場所で、説明されたアプローチの関連性について述べたコメントで他の例が表明されました-これらは最近登場した特殊な製品です。 まず、これらはwww.axure.com 、 http : //froont.comなどのWebページのラピッドプロトタイピング用のソリューションです。 第二に、これはレイアウトの視覚的開発時に既製のレイアウトがすぐに生成される新しい世代のプログラムとサービスです（「旧世代」の同様の製品とは異なり、これらのソリューションはハイエンドのタイプセッターによって書かれたかのようにクリーンで簡潔なコードを生成します）： http ：//macaw.co、https://webflow.com
プロトタイプを作成するための製品は、視覚的な結果をすばやく得ることができるという点で優れていますが、簡潔でクリーンなレイアウトの問題はなく、それらで作成された本格的なインターフェースについてはなおさらです。 高品質のコードを生成するソリューションは単純とは言えず、すぐには機能しません。 逆に、グラフィックレイアウトを最初に作成してから「手動で」作成する必要がある場合と比べて、逆に作業時間は同程度またはそれより長い場合があります。 同時に、どちらも使用される条件でレイアウトを操作する機会がありません（つまり、ブラウザで直接、エディタの作業要素が欠落している）。 そして、自動保存とプロジェクトホスティングの機能は、第三者に中間結果への継続的なアクセスを提供します（品質評価、ユーザビリティの専門知識など）。
これらすべての欠点がなく、提案されたWebインターフェース開発のライフサイクルを完全に実装できるソリューションが表示された場合、それは時間の問題です。 すべてのトレンドは、まさにそのような製品につながります。
この記事に記載されている問題とその解決策に興味がある場合は、 http ： //www.youtube.com/watch？v = nIOVU9_KRKAでこの短いビデオを視聴するボーナスとして提供しています。
シリル、
プロジェクトマネージャー、 モックアップエディターSletchBuilder
デザイナーのSergey Sevenvampireとウェブ開発者のAnton skruttyとのコラボレーション 。