効率的なレスポンシブデザインプロセス

レスポンシブデザインプロセスはどのようなものですか？ 効率的だと思いますか？ 次の記事は、Smashing Book 5（目次）のeBookバージョンで最初に公開されたBenCallahanの章「ResponsiveProcess」からの抜粋です。 -ed。

「このRFPへの成功した回答者は、私たちのチームが評価するための3つの静的な設計オプションを提供します。」 私はマルチオプション設計アプローチを採用することの大ファンではありませんでしたが、私はそれを理解しています—クライアントがこれを必要とする場合があります。

「これらの各オプションは、ホームページ、リストページ、詳細ページの3つの独自のレイアウトのデザインを提供します。」 わかった。 現在、最大9つの静的設計ファイルがあります。 これは少し手に負えなくなっています。

「これらのユニークなページデザインはそれぞれ、モバイル、タブレット、デスクトップのサイズを考慮に入れる必要があります。」 私は数学が得意ではありませんでしたが、この計算はできます。 27個の静的設計ファイル？！ 起こらないだろう。

これは、私が少し前に受け取った提案依頼書の実際のリクエストです。 クライアントはより効率的なアプローチに非常に従順だったことがわかりました。 しかし、この経験は本当に私に考えさせられました…このようなことをすることについての最も難しいことは実際にこのようなことをすることではありません。 あなたがこのようなことをしている間、それは人々と協力しています。

ほら、そこにあるほとんどすべての潜在的なクライアントはすでにウェブサイトを持っています。 私たちにとって、それはほとんどのクライアントが過去のウェブプロジェクトからの彼ら自身の荷物とともに、一連の期待を持ってこれに来ていることを意味します。 その荷物は、クライアントがプロジェクトにアプローチする方法、そしてあなたに劇的な影響を与える可能性があります。 これらの期待の悪影響を減らすのを助けるために、私はそれらを管理する最良の方法はそれらを設定する人になることであると思いました。

この章の私の目的は、最初から始めてWebプロジェクトをより成功させるのに役立つことです。 初日から何が起こるかについてクライアントの期待を設定するのを助けることによって、そして同じことをするためにプロジェクトのライフサイクルを通して働くことによって。

レスポンシブWebデザインのプロセスにおける主な違い

お気に入りのテキストエディタを開く前、Macawを開く前、スケッチパッドを取り出す前、またはテキストでスカルプトを開始する前に、顧客がプロセスを理解できるようにする必要があります。 これを行うには多くの方法がありますが、私の一番のお気に入りは、新しいプロセスでそれらを販売しようとすることです。 私の経験では、契約が締結される前であっても、早い段階であなたの考え方に価値を示すことが最善のアプローチです。 これはあなたが話していることをあなたが知っているという自信をあなたのクライアントに与えますが、それはまたあなたが新しい方法を試すために彼らの信頼を得る必要があることを意味します。

これを促進するために、私のチームには4つの理想があります。私は、コラボレーション、反復、適応、優先順位付けという4つの理想を念頭に置いて相互にやり取りしています。 これらの特定のアイデアがあなたをまっすぐにそして狭く保つ理由を簡単に説明しましょう。

コラボレーション

分かってる。 どこにでもいる誰もがコラボレーションについて、そしてそれが素晴らしい仕事をするためにどのように必要かについて話し合っています。 さて、あなたは何を知っていますか？ それは本当です。 もちろん、チーム内でコラボレーションする必要がありますが、最近必要な別の種類のコラボレーションがあります。それは、クライアントとのコラボレーションです。 私はあなたに重要なリマインダーを持っています：クライアントも人です。 彼らはウェブデザインと開発に関してあなたの専門知識を持っていないかもしれませんが、彼らはあなたがこれまで以上に彼らのビジネスについて多くを知っています。

繰り返しますが、最初から始まります。 Sparkboxでは、新しいクライアントを参加させるために、より協力的になる方法を探していました。 その一環として、見積もりを作成するための新しいアプローチを採用しています。 顧客が私たちのところに来て、私たちが1週間姿を消し、完璧なソリューションで戻ってくることができるように彼らのプロジェクトを説明する代わりに、私たちは見積もりを手伝ってくれるように彼らを招待しています。 それは非常に簡単です—私たちはそれを共同見積もりと呼び、クライアントはそれを気に入っています。

まず、調整可能なフィールドがいくつかある基本的なGoogleスプレッドシートから始めて、作業にかかると思われる金額を計算します。 プロセスの非常に早い段階で、通常は30分の電話の後でこれを行うため、広範囲から始めます。 次に、それをクライアントと共有し、一緒に取り組みます。

これが重要である理由は次のとおりです。私たちは、クライアントと最初に行うことについて協力します。 私たちは、彼らのためではなく、彼らと一緒に仕事をするときに、私たちがより多くの価値を付加することを彼らに知ってもらいたいのです。 これは、私たちがお金を口の中に置く方法の1つにすぎません。

また、クライアントをチームのコミュニケーションチャネルに招待します。 私たちはSlackとBasecampの大ファンです。 これらのツールは、質の高いコラボレーションを促進するために必要な、正式なドキュメントと非公式の会話の素晴らしい組み合わせを提供します。

ダニエル・モールによるリーディング・イズ・ファンダメンタルのウェブサイトのオープンな再設計では、ダンがどのように顧客を彼と一緒にプロジェクトに参加させるかを垣間見ることができました。 Brad Frostは、プロジェクトの進行状況を追跡するためのツールである「ProjectHub」と呼ばれるGitHubプロジェクトでさらに一歩進んだものです。

これらはすべて単なるツールであることを忘れないでください。 ツールは役に立ちますが、本当に必要なのは私たちの考え方の変化です。 友人のケビン・シャロンは、私に非常に心に訴えることを一度言ったことがあります。 彼は、「 『いいえ』と言えないのなら、それはコラボレーションではありません」と語った。 私はあなたのことを知りませんが、私はクライアントと多くの関係を持っており、彼らが求めていたものがうまくいかないことを経験から知っていたとしても、私には押し戻す権限がありませんでした。 これらのクライアントは、解決する必要のある問題ではなく、解決策を提示します。

私はそれを認めることを恥ずかしく思いますが、反対のことが真実であるクライアントとの関係もありました。 時々私の欲求不満は私を良くします、そして私は私のクライアントがプロジェクトの一部である必要があることを忘れます。 お客様からアイデアを聞いてすぐに反対した場合、私たちはお客様が共同プロセスを拒否したのと同じように有罪となります。 多くのWebスタジオは、クライアントが有意義な方法で貢献できるほど創造的または技術的であると信じていないために、プロセスでこの種のコラボレーションを許可することを望んでいません。

コラボレーションは双方向です。 あなたの顧客の見方を彼らがあなたの仕事の真の貢献者になることに向けてシフトすることは、彼らを含め、あなたがより良い製品を作るのを助けるあらゆる種類の新しい方法をもたらすでしょう。

繰り返す

私たちは定期的に、機能の小さな高品質のサブセットを驚異的な速度で提供する機会を探しています。 このようなアプローチを取ることは、早い段階で進歩を示し、あなたが学んだことによってプロジェクトを進めるための勢いを生み出す本当の機会を提供します。

クライアントの働き方を変えることで政治的な課題があるかもしれないと感じた場合は、ここにプロのヒントがあります（そして私たちが行うすべてのプロジェクトでこれを感じます）：繰り返し働くことは懐疑論者を支持者に変えるのに役立ちます。 ほとんどの人は、プロジェクト全体よりも小さなフェーズで新しい方法を試してみる可能性がはるかに高くなります。 繰り返しになりますが、ここでの重要なポイントは、顧客の信頼を得るために、早い段階で価値を実証することです。

反復が現れる1つの方法は、プロトタイピングです。 私たちは常に重要な課題を特定し、可能な解決策を提案し、プロトタイピング、改訂、繰り返しを通じてその有効性を証明または反証する機会を探しています。

多くの場合、大規模なプロジェクトを開始する前に、有料の発見フェーズから始める機会を探します。 あなたが結婚する前にそれをデートと考えてください。 これにより、プロジェクトと、このクライアントとの連携についてさらに学ぶ機会が得られます。 両当事者は、協力関係が適切であるかどうかを判断することができます。

最初のエンゲージメントにはさまざまな形態がありますが、主な目的は次のとおりです。

1. プロジェクトの範囲をよりよく理解する
2. 最大の課題に対する可能な解決策を特定して証明する
3. クライアント/ベンダーの適合が正しいかどうかを判断する
4. あなたが有能であることを証明する
5. 上記の支払いを受ける

あなたのクライアントはこのアプローチを高く評価し、あなたは将来の仕事のための素晴らしい基盤を構築するでしょう。 そして、プロジェクトの理解を劇的に変える何かを学んだ場合、あなたは小さな段階にのみコミットするでしょう。 この学習は、プロセスの次のステップに大いに役立ち、より良い解決策に向けてあなたを押し進めます。

私たちには長年一緒に働いてきた顧客がいます。 実際、私たちは最近、彼らと一緒に30番目のプロジェクトを開始しました。 私にとって、これは私たちが協力するための相互に有益な方法を見つけたというサインです。彼らは私たちが提供するものに価値を見出し、私たちは彼らとの仕事に創造的かつ技術的に満足しています。 この関係を成功させた理由を特定するために、私は反復的なアプローチに戻り続けます。 彼らが問題とそれを解決する方法についてのアイデアを持って私たちに来たことが何度もありました。 12週間のプロジェクトをかじるだけでなく、考えられる解決策をテストし、初期投資を大幅に削減する、より小規模で反復的なフェーズを定期的に提案しました。 このアプローチを取ることで、私たちは彼らの信頼を得ることができました。 その信頼は持続可能な関係を築くために不可欠であり、反復はそのすべての中核です。

適応

レスポンシブウェブデザインが登場したとき、私たちが構築していた製品に固有の柔軟性が私たちのプロセスに浸透しているという考えに驚いたことを覚えています。 サマンサウォーレンはそれを最もよく言いました：「あなたのプロセスはあなたが設計している製品と同じくらい敏感でなければなりません。」

真実は、この種の仕事のための完璧なプロセスはありません。 あなたと私は、私たちが提示されている制約を受け入れる必要があります。 プロジェクト、クライアント、スコープ、タイムライン、予算、チーム、技術スタック、サポートマトリックスはすべて異なります。 このビジネスで成功している組織は、プロジェクトの制約の範囲内で作業でき、それでも時代を超越した作業を行うことができる組織です。

プロセスに関する私の見解は、顧客に説明するのが明らかに難しいです。 機会があれば、私はおそらく、プロジェクトに関与している数人の主要人物（クライアントを含む）を数週間部屋に閉じ込め、それを理解する権限を彼らに与えます。 私からそれを取ってください、クライアントは一度に何週間も部屋に閉じ込められるのが好きではありません。

代わりに、非常に厳格なプロセス（各ステップがレイアウトされ、文書化される）と即興的なプロセス（チームが最善のアプローチを見つけることを信頼する）の間のバランスを見つける必要があります。 このバランスを見つける際に考慮すべき多くの要因があります。 まず、次の3つを示します。チームの規模。 チームの経験; そしてプロジェクトの重要性。

チームの規模

チームが非常に小さい場合は、プロセスに大きな柔軟性を持たせる方がはるかに簡単です。 同じ部屋に座っている2、3人は、多くの構造がなくても、何が起こっているかを追跡できます。 チームのサイズを最大6または7にすると、プロジェクト全体の進行に対する各プレーヤーの影響を理解するのが難しくなり始めます。 チームを10、15、またはそれ以上に増やすと、ほとんど不可能になります。

これは私にとって非常に個人的なことです。 パートナーと一緒にSparkboxを最初に始めたとき、私たちは4人しかいませんでした。 私たち一人一人にはかなり明確な役割があり、多くのプロセスなしでかなり効果的に運営することができました。 私たち全員が1つの大きな部屋に一緒に座っていたので、私たちのビジネスのあらゆる側面について絶えずコミュニケーションがありました。

現在、23人のフルタイムの人々と3人の見習いがいます。 私たちは確かにいくつかの場所ほど速く成長していません—私たちは成長について非常に慎重です—しかし、「成長痛」というフレーズは依然として真実です。 私たちは、いつ、何を、どのようにコミュニケーションするかを常に実験しなければなりませんでした。 私たちにぴったりのバランスを見つけることができるのは、この実験を通してのみです。

ここでの教訓は、チームの規模が、特定のプロジェクトに採用できるプロセスの種類に影響を与えるということです。 一般に、プロジェクトに参加する人数が多いほど、必要な剛性も高くなります。 チームの規模が小さくなると、あまり正式ではないプロセスで逃げることができます。 チームの脈動を監視し、物事がスムーズに進むようにプロセスを調整するのは、プロジェクトマネージャーの責任です。

チームの経験

経験の浅いチームで作業している場合は、より厳密なプロセスを使用すると、全員が同じページにいることができます。 実際、経験の浅いチームには、経験を積むためのコンテキストとして具体的なプロセスが必要だと思います。 より厳格な環境で成功を示した後でのみ、プロセスのレイヤーを剥がし始めることができ、チームがそれをどのように機能させるかについてより自由になります。

これもまた、私にとってはかなり個人的な概念です。これは主に、プロジェクトのチームを編成する方法が原因です。 私たちは、プロジェクトごとに独自のチームを編成しました。 プロジェクトの過程でさえ、チームの内外で人々を交代させる可能性があります。 これは、特にそれらの個人の経験が大きく異なる場合、課題を生み出す可能性があります。 ほとんどの場合、成功するには、さまざまな人々がさまざまなレベルのプロセスを必要とするという事実を意識する必要があることを意味します。 私たちのプロジェクトマネージャーはこれを注意深く監視し、必要に応じて調整します。

経験豊富なデザイナーや開発者がたくさんいるので、このバランスは主に経験の浅い人々を広めることです。 高度なスキルを持つチームに1人または2人の新しい開発者を追加すると、すべての人の水準が上がります。 新しい開発者は経験豊富な人から学び、経験豊富な人は新しい開発者に教えることで学びます。 これはお互いに有利になります！

プロジェクトの重要性

プロジェクトがいかに重要であるかという考えは、アジャイルマニフェストの最初の署名者の1人であるAlistairCockburnという名前の紳士から来ています。 「クリスタルメソッド」に関する彼の著作の中で、コックバーンはこの声明を完成させることによって重要性の範囲を説明しています。

欠陥は以下の損失を引き起こします：

1. 快適さ（重要ではありません）
2. 裁量金（やや重要）
3. エッセンシャルマネー（クリティカル）
4. 人生（非常に重要）

私たちの製品がより重要であるほど、私たちのプロセスはより厳格でなければなりません。 あなたが中小企業と大企業の両方で働いたことがあるなら、あなたはこれを経験したかもしれません。 地元の小さな会社は、危険にさらされていない（重要度が低い）ため、仕事の自由度が高くなる傾向があります。 大企業は、プロセスで良い結果が得られない場合、失うものがはるかに多くなります（重要度が高くなります）。

私がこの業界で始めたばかりのとき、私はほとんど専ら地元の小さな企業と仕事をしていました。 付箋紙、メール、電話で隔週でプロジェクトを管理しました。 今、私ははるかに大きな組織に関わっています。 これらのプロジェクトを管理するには、毎日のスタンドアップ、回顧、スプリント計画会議に参加する必要があります。 私たちは、バーンアップを構築し、JIRA（問題追跡ソフトウェア）で作業し、私が認める以上に速度を計算していることに気づきます。 これはすべて、作業の重要性によるものです。十分な数のわずかな割合でも、依然として膨大な数です。 これらの大企業はこれを理解しており、それらの手ごわい損失から彼らを保護するためのプロセスを実施しています。

優先する

設計する画面のサイズが小さくなると、優先度を伝達するためのオプションも小さくなります。 考えてみてください。私たちは通常、サイズ、位置、順序、コントラストなどを使用して、ユーザーがどこに焦点を合わせるべきかを理解できるようにします。 小さな画面では、オブジェクトのサイズや見出しの位置でできることはたくさんあります。 大画面のエクスペリエンスに焦点を当てているときと同じような自由はありません。

このため、システム全体のコンテンツと機能の優先順位を理解することが重要です。 Luke Wroblewskiは、クライアントが本当に重要なことを理解できるように、まずモバイルデバイスについて考えるように促しました。 真実は、優先順位をしっかりと理解していなければ、レスポンシブWebデザインは単なる推測にすぎないということです。

私たちは、プロセスの非常に早い段階でお客様に直線的に考えさせることで、これをお客様に奨励してきました。 （以下の「実行方法」のセクションでは、これを行うために使用するツールの種類を共有します。）直線的に考えることには、人々に最も重要なものを選択するように要求するという利点があり、合意が必要なのはこの優先順位です。 プロジェクトでこれをすぐに確立することで、基盤を構築するための受け入れられた基盤が築かれ、プロジェクトの後半で自分自身が尋ねるであろう多くの質問に対する答えが提供されます。

最近、クライアントがワイドスクリーンのワイヤーフレームをすでに組み立てた状態で私たちのところにやってきたプロジェクトがありました。 彼らはいくらかのお金を節約するためにこれをしました、そして私達はこのように彼らと一緒に働くことを試みてうれしく思いました。 私たちがデザインを始めたとき、クライアントは私たちの仕事に満足していませんでした。 プロジェクトの途中で、ワイドスクリーンのワイヤーフレームがコンテンツと機能の優先順位を適切に識別していないことに気づきました。 これが私たちが抱えていた問題の核心でした。 プロジェクトの勢いを取り戻すために、コンテンツ分析と優先順位付けを実行することになりました。 以前にそれを行っていれば、プロジェクト全体でより効率的に作業できたはずです。 残念ながら、彼らがお金を節約するのを助けるために、私たちは、最初に適切な基盤を築いただけで回避できたであろういくつかの手直しを実行しなければなりませんでした！ 学んだ教訓—優先順位を早期に確立します。

4つの理想

次のプロジェクトに進むときは、クライアントをプロジェクトに含める必要があることに注意してください。 彼らのために働くだけでなく、彼らと協力する機会を探しましょう。 早い段階で価値を実証すればするほど、より多くの信頼を得ることができることを忘れないでください。 反復はこれを行うのに役立ちます—小さく始めることを恐れないでください！ また、特定のプロジェクトやクライアントが必要とするものに合わせて、作業方法を調整する必要があることを忘れないでください。 最後に、プロジェクトの早い段階でコンテンツと機能の優先順位を確立するために懸命にプッシュします。 これにより、プロジェクトの後半で、特定の種類のコンテンツの重要性について疑問が生じたときに配当が支払われます。

これらの4つの理想を超えて、日常でどのようなプロセスが機能するかを検討する際に、少しフレームワークを提供したいと思います。

プロセスを検討するためのフレームワーク

私たちのプロセスは常にその人生のために戦っています

ほとんどのプレゼンテーションやプロセスに関する記述について私を驚かせるのは、共有している人々がどれほど自信を持っているかということです。 多分私たちは外れ値ですが、私たちのプロセスは常にその人生のために戦っています。 新しい働き方ができたら、やってみます。 何かをするためのより良い方法のヒントさえあると思うなら、それを発見しようと試みます。 これが私たちの配線方法です。 多くの方もこのように配線されているように感じます。

私たちのプロセスが決して完了しないことに同意しましょう。

線形ハンドオフからのシフト

業界のほとんどは、成果物を壁に投げかけるのをやめなければならないことに同意しています。 代わりに、多くの人が、プロジェクトの期間中に適切な人が関与することでチームメイトの共感が高まり、すべての人の水準が上がることを期待して、チームを再編成する方法を考えています。 トレント・ウォルトンは、「再編成」と呼ばれる彼の投稿でこれを雄弁に説明しています。 その中で、彼はあなたのチームの構造があなたが使用できるプロセスの種類をしばしば制約し、私たちがより小さな学際的なチームを検討することを奨励していると述べています。 私たちはこれが真実であると見ており、非常によく似たアプローチを取っています。 正直なところ、私たちの過去の線形プロセスは、おそらく常に少し非効率的でした。 レスポンシブウェブデザインは、その非効率性をはるかに明白にしただけだと思います。 レスポンシブな仕事に取り組むことで、クライアントの組織構造について話し合うことができました。RWDが本当に組織の変化の触媒であるという証拠が増えています。

より多くのプロジェクトのために、より多くの分野を関与させる必要があります。 私はこれを、私たちの目が最終製品である成果物にしっかりと焦点を合わせたプロジェクトをスパイラル化するものと考えるのが好きです。 それぞれのスパイラルが通過することで、私たちはすべての分野を巻き込み、すべての決定ポイントでより明確になります。 コンセプトは単純です。プロジェクトの期間中、チーム全体が役割を果たすことができるようにします。 言い換えれば、プロジェクトのある領域で変更を加えることが他の領域に与える影響を認識し、受け入れることです。

私のチームと私は、私のビジネスメンターとのやりとりのおかげで、このアイデア（プロジェクトを通じてスパイラル）にたどり着きました。 彼の名前はジェフで、彼はとても鋭い男です。 彼はいくつかのかなり大規模な組織のCFOであり、先見の明のあるリーダーが会社の財務を把握するのを支援することでキャリアを築いてきました。

私たちが最初にジェフと会ったとき、私たちは危機的状況にありました。 私たちの前には大きな課題がありました。それは、私のパートナーも私も対処方法を知らなかったということです。 ジェフは私たち全員を座らせ、「終わりを念頭に置いて始める」ように私たちに求めました。 彼は、私たちがこれからの困難な時代を乗り越えた後、それがどのようになるかを説明してほしいと思っていました。 彼は私たちが私たちの会社の人生でこの時期の成功を定義することを望んでいました。 ジェフと会い続けると、私はイライラし始めました。 私たちが座るたびに、私たちが直面している問題を解決するために必要なアドバイスを彼が私たちに与えてくれることを望みました。 代わりに、彼は絶えずますます多くの質問をしました。 これは数週間続き、私にとっては困難な時期でした。

ジェフと私のパートナーとのミーティングで、すべてが理にかなっていることを決して忘れません。 私たちの会議は他のすべての人と同じように始まりました。 私たちは自分たちの前で問題についての現在の理解を経験し、私たちが得た新しい洞察を共有するのに少し時間がかかりました。 今回だけ、私たち一人一人が解決策が浮かび上がってくるのを見始めました。 完全には明確ではありませんでしたが、焦点が合い始めました。 私たちが検討していた3つのオプションのうち、1つは他のオプションよりもはるかに魅力的に見え始めました。 過去数か月にわたって学んだことは、間違いなく、直面している問題に対処するための最良の選択肢につながりました。

このレッスンは私にとって非常に貴重でした。 それが私に教えてくれたのは、線形プロセスでは、すべての情報を入手する前に意思決定を行う必要があるということです。 ビジュアルデザインを考慮せずにワイヤーフレームのセットを作成するために知っておく必要のあるすべてをどうやって知ることができるでしょうか。 フロントエンドコードを試さずに、インターフェイスデザインを完成させるにはどうすればよいでしょうか。 コンテンツから始めて、ユーザーエクスペリエンスの設計を行い、ユーザーインターフェイスの設計を行うなど、これらの各成果物が他の成果物に与える影響を無視します。 代わりに、私たちは彼らがお互いに通知できるようにする必要があります。 私たちは彼らに呼吸し、調整し、プロジェクトから学んだことを使って彼らを前進させる余地を与える必要があります。

これはまさに、ジェフが私たちを押し進めていたスパイラルプロセスです。 質問をするそれらの週は、問題の理解を私たちに知らせていました。 決定を下し（UIデザインを承認し）、それが決して変わらないかのように進む（OK、フロントエンド開発者、このデザインをコーディングする）代わりに、Geoffは、必要なすべての情報がないことを認識させました。最善の決定を下すために。 ジェフは、「最後の責任ある瞬間」が決定するまで待つことを望んでいました。

私はスパイラルのこのアイデアを私たちが毎日行うことに翻訳しようとしました、そして私はこのような視覚化に着陸しました：

上のパイのスライスにあなた自身の分野を入れてください—アプローチを説明するために画像は簡略化されています。 これらのドットは、従来の意味での成果物ではないことに注意することが重要です。 これらは、クライアントと一緒に座って、「1つの成果物」に向けた進捗状況を確認する機会を表しています。 つまり、クライアントを失望させることを恐れて、成果物の精緻​​化をやめます。 ホワイトボードのスケッチでうまくいくときに、Illustratorでワイヤーフレームを美しく見せることは非常に非効率的です。 成果物と呼ぶのをやめ、アップデートと呼ぶようになりました。

この種のワークフローは、プロジェクトに必要な分野のタイプを簡単に交換できるため、あらゆる種類のプロジェクトで使用できるほど柔軟です。 プロセスの周りの式典は、関係する人々の経験に応じて、より厳格またはより即興的にすることができます。 重要なのは、すべての人が関与していることを確認することです。

このアプローチは、正しい情報が得られるまで決定を遅らせます。 ある分野で下された決定が他の分野に影響を与えることは間違いないことを認識しています。 それはチームへの会話を開き、関係者全員からの賛同を必要とします。 正式ではありませんが、より効率的です。 予測は難しいですが、はるかに優れた製品を提供できる可能性があると思います。

学際的な貢献を模索する必要があることに同意しましょう。

効率が重要

私たちが世界中にずっといたら、私たちは自分たちのプロセスについて心配する必要はありません。素晴らしいアイデアに出くわすまで、何かを試すことができました。 あなたも私も、そうではないことを知っています。

Sparkboxでのプロセスに加える調整の多くは、何かを達成するためのより高速な方法を探しているためです。 スピードの向上の約束は、より大きな顧客の非常に才能のある社内チームと協力する機会を得る方法でもあります。 誰もが効率の向上を求めています。

良いプロセスは効率的なプロセスでもあることに同意しましょう。

進化し続ける。 学際的。 効率的。 このようなものの要点に飛び込むとき、私はこれら3つのことを念頭に置いてほしいと思います。 これらのアイデアを、新しいアプローチを検討するためのフィルターとして使用できます。

十分な理論

それは十分な理論です。 この作業の要点を見てみましょう。 私は、Webプロジェクト全体で常に3つの質問をしていることに気づきました。

1. 私たちは誰のために構築していますか？
2. 私たちは彼らにその経験から何を得てもらいたいですか？
3. どのように経験を提示する必要がありますか？

目標は、適切な人（誰）に適切な方法（方法）で適切なこと（何）を言う方法を見つけることです。 あらゆる種類の優れたコミュニケーションの秘訣は、これらの質問に答えることです。 もちろん、プロジェクト全体を通して他の多くの質問をします。 このサイトではどのようなナビゲーションパターンを使用する必要があるのか​​、それともすべてのページの上部に広告が本当に必要なのかなどの質問があります。 私は、あなたが出てくる他のすべての質問に答えるときに、誰が、何を、どのようにあなたを正しい方向に導くかについての答えを持っていることを提案しています。

うまくいけば、あなたはすでにダンモールの章を読んでいます（この章の直前）。 その中で、彼はあなたが誰と通信しているのかを理解することに関するいくつかのコンテキストを提供する素晴らしい仕事をしています。 インタビューとキックオフミーティングについての彼の説明は、あなたを正しい方向にしっかりと動かすでしょう。

同様に、Eileen Webbによる次の章は、レスポンシブプロジェクトのコンテンツ戦略に関するものです。 それは徹底的な章であり、彼女は私たちがこれまで以上にうまくコミュニケーションしようとしていることについての質問に答えます。

したがって、この章の残りの部分では、3番目の質問「どのように」に答えることに専念します。 私とSparkboxの私のチームにとって最も役立つツールの種類をあなたと共有し、それらがあなたにも役立つと信じています！

それを成し遂げる

先に述べたように、私たちが提示しているコンテンツと機能の優先順位を理解することは、効果的にコミュニケーションするために重要です。 この真実が私たちの仕事に現れるいくつかの方法があります。

コンテンツ優先ガイド

コンテンツ優先ガイドは、「一部コンテンツモデリング、一部ストリップダウンワイヤーフレーム」です（EmilyGrayによる「コンテンツ優先ガイド」を参照）。 ミニコンテンツモデルのように、優先順位が高く、クライアントとのコラボレーションがあります。 （コンテンツ優先ガイドの実用的な例については、https：//bit.ly/content-priority-guideを参照してください。）

コンテンツ優先ガイドでは、各ページにどのような種類のコンテンツが存在する必要があるかを説明しています。 これらは、ブログ投稿のタイトル、プライマリイメージ、本文のコピーなどの単純なものでも、はるかに複雑なものでもかまいません。eコマースサイトの製品詳細ページで必要になる可能性のあるすべてのコンテンツタイプを検討してください。

また、各コンテンツタイプの説明も可能です。 製品の簡単な説明がある場合、優先ガイドには、「製品とその独自性を説明する1つの文」と記載されている場合があります。 ヒーロー画像のようなアイテムの場合、特定のケースに関連する場合は、写真のアートディレクションに関する詳細を提供できます。

コンテンツ優先ガイドは、再利用可能なコンポーネントをすばやく特定するのにも役立ちます。 これは、そのコンテンツの管理を計画するときに非常に役立ちます。再利用可能なパターンを認識することは、コンテンツを管理するためのより効率的なシステムを構築できることを意味します。

最も重要なのは、優先ガイドが優先順位になっていることです。 特定のページで本当に重要なことについての議論を引き起こします。 これは、ビューポートの幅全体でサイトがどのように応答するかを検討するときに非常に役立ちます。 また、実際のコンテンツが含まれていないため、コンテンツの種類の内容と理由についての会話が容易になります。これは、すぐにコピーを書き始めると見落とされがちです。

クライアントが優先順位を付けるのが難しい場合（そしておそらくそうなるでしょう）、スプレッドシートに最も重要なものに関するこれらの決定を配置し、チェックするオプション（一次、二次、三次など）を与えることができます。結果は同じです。各ページのコンテンツタイプの優先リストですが、そこに到達するためのプロセスは、クライアントにいくつかのオプションが与えられている場合、クライアントにとって少し親しみやすいと感じるかもしれません。

情報アーキテクチャ

システムに存在する必要のあるコンテンツの種類と優先順位を十分に理解したら、そのコンテンツをどのようにグループ化するか、およびユーザーに使用してほしいコンテンツのパスを検討することが重要です。 このような考え方は、使えるサイトを作るために欠かせません。

私は最近、アーロン・クインが情報アーキテクチャについて話すのを見ました、そして彼は本当に私に固執する何かを言いました。 彼は、情報のグループ化に関しては、私たちの常識に頼りすぎているのではないかと示唆しました。 代わりに、彼は、ユーザーが私たちが構築したものとどのように対話するかを計画するときに、常識に関するコンセンサスを検討することを私たちに主張しました。 その理由を簡単な話で説明しましょう。

1年以上一緒に仕事をしているクライアントがいます。 彼女は、私たちが彼女の構築を支援した非常に成功したSAAS製品をブートストラップしました。 この女性は信じられないほど頭がいい。 彼女は毎日ウェブ上で働いています—それが彼女が生計を立てている方法です。 少し前まで、私は彼女の製品の次のことについて彼女と話していました、そして彼女は私にこれを言いました：「私たちは私たちのサイトのタブにいくつかの変更を加える必要があると思います。」 彼女のサイトのどこにタブを実装したかを必死に思い出そうとしていたので、一時停止しました。 私の混乱を感じて、彼女は彼女が望んでいたことについてもっと説明し続けました。 しばらくして、彼女がナビゲーションについて話していることに気づきました。 この精通したウェブ起業家が彼女のナビゲーションを「タブ」と呼んだことは目を見張るものでした。

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

Let's agree that a good process is also an efficient process.

Ever-Evolving. Multidisciplinary. Efficient. As we jump into the nuts and bolts of this stuff, I want us to keep these three things in mind. We can use these ideas as a filter through which we consider new approaches.

Enough Theory

That's enough theory. Let's get into the nuts and bolts of this work. I find myself constantly asking three questions throughout our web projects:

1. Who are we building for?
2. What do we want them to gain from the experience?
3. How should we present the experience?

The goal is to find a way to say the right things (what) in the right way (how) to the right people (who). The secret to great communication of any kind is answering these questions. You will, of course, ask many other questions throughout your project. Questions like what kind of navigation patterns should I use on this site, or do we really need an ad at the top of every page? I'm suggesting that having the answers to who, what and how will lead you in the right direction as you answer all the other questions that come up.

Hopefully, you have already read Dan Mall's chapter (just before this one). In it, he does a great job providing some context around understanding who you're communicating with. His explanations of interviewing and kick-off meetings will move you solidly in the right direction.

Similarly, the next chapter by Eileen Webb is all about content strategy for your responsive project. It's a thorough chapter, and she answers the questions around what it is we're trying to communicate better than I ever could.

So, the rest of this chapter is dedicated to answering that third question, “How?” I'll share with you the kinds of tools that have been the most helpful for me and my team at Sparkbox and trust that they will also help you!

それを成し遂げる

As I mentioned earlier, understanding the priority of the content and functionality we're presenting is critical to communicating effectively. Here are a few ways this truth manifests itself in the work we do.

Content Priority Guide

A content priority guide is “part content modeling, part stripped-down wireframe” (see “Content Priority Guide” by Emily Gray.); like a mini content model, in priority order, and with client collaboration. (See https://bit.ly/content-priority-guide for a working example of a content priority guide.)

The content priority guide tells you what types of content should exist on each page. These could be simple things like the title, primary image and body copy on a blog post, or they could be much more complex: consider all the content types you might need on the product detail page of an e-commerce site.

It also allows for explanation of each content type. If you have a short description of a product, the priority guide may say, “One sentence describing the product and what makes it unique.” For an item like a hero image, you could provide some details about the art direction of the photo if that was relevant for a specific case.

Content priority guides also help you quickly identify reusable components. This is very helpful as you plan out the management of that content — recognizing reusable patterns means you can build a more efficient system to manage the content.

Most importantly, a priority guide is in priority order . It provokes a discussion about what's truly important on any specific page. This helps tremendously as you consider how a site will respond across viewport widths. And because it doesn't contain actual content it facilitates great conversation about the what and why of types of content, which can easily be overlooked if you start writing the copy immediately.

If your clients have difficulty prioritizing (and they probably will), you could place these decisions around what is most important into a spreadsheet and give them options to check — primary, secondary, tertiary, etc. The result is the same: you have a prioritized list of content types for each page, but the process to get there may feel a bit more friendly to the client if they're given some options.

情報アーキテクチャ

Once you have a good understanding of the types and priority of content that needs to exist in the system, it's critical to consider how that content should be grouped and the paths through the content you want your users to take. This kind of thinking is crucial to the creation of a usable site.

I recently saw Aaron Quinn speak about information architecture and he said something that really stuck with me. He suggested that we might be relying too much on our common sense when it comes to grouping information. Instead, he made the case for us to consider consensus over common sense when planning how our users will interact with what we build. Let me explain why with a quick story.

We have a client we've been working with for over a year now. She has bootstrapped a very successful SAAS product which we helped her build. This woman is incredibly smart; she works on the web every day — it's how she makes a living. Not too long ago, I was having a conversation with her about what was next for her product and she said this to me: “I think we need to make some changes to the tabs on our site.” I paused because I was desperately trying to remember where we had implemented tabs on her site. Sensing my confusion, she went on to explain more about what she was hoping for. After a few moments, I realized she was talking about the navigation. It was eye-opening that this savvy web entrepreneur referred to her navigation as “tabs.”

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

During some recent usability tests, I noticed that on small screens many users never attempted to locate or use navigation. These days, most of our small-screen navigation experiences are hidden behind obscure icons (hamburger, anyone?). I believe our expectation that users will properly identify, trigger and use our navigation is unfounded.

In an effort to combat this, we've begun considering a simple question — can someone use this site without the navigation?

Literally, remove the navigation from your site and see if your users can reach the content they want. In other words, plan out the content in such a way that your users can feel their way through the experience. Chances are, a good number of them will browse this way. We'd better be ready for them.

スタイルの比較

I learned about style comparisons when I had the opportunity to present with Dan Mall and Yesenia Perez-Cruz at Artifact Conference in Austin, Texas. Dan shared a story about how he was working to build a new office. Here's the relevant excerpt from his blog post:

“I could create an illustration or a 3D rendering of what I want my new office to look like, but that doesn't take advantage of his [the contractor's] great ideas. It's dictation, not collaboration. Instead, I show him a Pinterest board my wife and I created. I tell him that I love these beams or this mix of materials, and we can have a conversation. I revise my ideas through his expertise, and vice versa. This is how building a website should go.”

Not only is this a brilliant approach to building a new space, it can be applied directly to what we do each day. Our creative director, Jeremy Loyd, has been creating super-simple PDFs for our clients that ask them whether they think their brand would best be represented online with:

• A dark or a light site
• A flat or a textured site
• An illustrated or photographic site
• Whatever other style comparisons are relevant

あなたはその考えを理解します。 The point is that it only takes a few minutes to put this together, because it doesn't really require any design. You can use screenshots of existing sites that embody the qualities you have questions about.

An approach like this is very useful when there isn't much clarity about the design direction up front. It helps us make sure we're in agreement about the direction we're headed. Truthfully, this is really just a simple tool to facilitate a conversation, to get people thinking and conversing about design.

One other trick from my friend Dan Mall which you can use to really drive this home is to quickly edit your client's logo into a screen capture of someone else's site. There is something about seeing their brand associated with a specific style which provokes a reaction. This makes for very fruitful conversations.

ユーザーエクスペリエンスデザイン

No title in our industry is more overloaded and misunderstood than “user experience designer.” It means so many different things to so many different people. Recently, I've even noticed a trend toward expecting all designers and developers to do this work. And while I believe the best organizations have teams full of people who care about user experience, I also believe it has a deeper role to play.

I think about user experience as the glue that binds our design and our development together. It's what separates web design from other kinds of design — that our work is intended not only to be observed, but also to be interacted with. That interaction is so important. In my mind, a great user experience designer has an instinct for what will be easy for a user to understand. However, this must be balanced with the idea that design without testing is guesswork . For this reason, a great user experience designer knows how to research their users, how to collaborate with UI designers, how to prototype possible solutions, and how to select and execute usability studies to capture and analyze data which properly informs design and development.

それは多いです。 And since I'm not formally trained in user experience or human factors, I'm probably not qualified to write about each of those things. Instead, I want to focus on one lesson I've learned (see “Test the Aggregate”) and then share the kinds of updates we do with our customers to help us all agree on usability decisions across screen sizes and input methods.

Test The Aggregate

I work with internal user experience teams at larger clients, and one challenge I'm continually presented with is the desire to test the experience they are building at individual breakpoints. In other words, I've seen teams create three (or more) separate prototypes — for mobile, tablet and desktop — and then proceed to test each one independently. When this happens, each of these separate experiences will evolve on its own, usually resulting in three unique experiences which will be very difficult (if not impossible) to build in a responsive way.

To combat this, lately I've shared how critical it is to test the aggregate experience. Instead of building three separate prototypes for usability studies, build a single prototype with HTML and CSS that actually responds. We usually do this statically with an evolving set of front-end build tools (you can learn more about our front-end stack in the article “We Heart Good Tools: An Update on Our Build Process”) which means we can work quickly with fake data.

This concept is about letting go of the control you think you have. It's about making decisions which benefit the whole (the aggregate) even though they may require compromises in certain contexts. It recognizes that changes made at one of the breakpoints in your system will inevitably affect the experience at other breakpoints. It's about embracing the benefits you get with a single code line and adjusting our usability studies to account for this.

迅速に構築する場合は、ビューポートの幅全体で単一サイトソリューションのテストに集中する必要があります。 ブレークポイントだけでなく、全体のユーザビリティを測定する必要があります。 これは、ほとんどの人にとって最も使いやすいエクスペリエンスを作成するのに役立ちます。

そして今、これらの目標を達成するためにクライアントと一緒に使用するいくつかの更新。

コンテンツのプロトタイプ

WebデザイナーはCSSを学ぶべきだと聞いたことがありますか？ そうですね、同意します。コンテンツストラテジストはHTMLを学ぶ必要があると思います。 このため、そして他の多くの理由から、私たちはWeb開発プロセスのかなり早い段階でコンテンツのプロトタイプを作成してきました。 実際のコンテンツを明確に把握し始めるとすぐに、そのコンテンツをハイパーテキストでマークアップし始めます。 これが私たちがHTMLで行うことですよね？ コンテンツを最もよく理解している人々よりも、セマンティックタグでコンテンツをラップする方が良いのは誰ですか？ Markdownのようなツールも同様に機能しますが、Markdownに直接ジャンプする前に、いくつかの基本的なHTMLを学ぶのが最善だと思います。 この方法でコンテンツを作成している理由を理解することは、実際にHTMLを作成することと同じくらい重要です。 Markdownのようなツールは、アクションとそれらのアクションの出力の間に抽象化レイヤーを追加します。これは、何が得られるかを理解すれば、問題のない抽象化です。

コンテンツのプロトタイプを作成するときは、ほとんどすべてのスタイルを意図的に除外しています。 私たちはそれらをかなり醜いままにしているので、私たちが何も設計していないことは非常に明白です。 これにより、会話はコンテンツとそのコンテンツの優先順位に集中し続けます。 これを顧客に示すと、顧客はすぐに物事の順序にたどり着きます。これはまさにあなたが望んでいることです。その優先順位を正しく取得してください。 また、通常、次のように、グループ化を表示するのに十分なCSSを含めます。

醜いと言った。

また、コンテンツのプロトタイプをリンクで溢れさせます。 これらを作成する理由の1つは、ユーザーがページ間を移動して、コンテンツのフローが機能するかどうかを確認できるようにするためです。

この種の醜いアップデートを見るためにクライアントを準備する必要があることを忘れないでください。 そうでなければ、彼らは確かに彼らのプロジェクトにあなたを巻き込むことについて考え直します。 ただし、ブラウザで未加工のコンテンツがマークアップされていることを確認することには、何か強力なことがあります。

重要な注意点の1つ：純粋にセマンティックなマークアップは、おそらく本番環境に移行するものではないことを認識しています。 これは理想的ですが、今日のWebでの作業の現実は、スキルセットが大きく異なる個人やチームが保守および拡張できる必要があるということです。 ただし、この純粋なバージョンのマークアップから始めることは、私たちの理想を思い出させる素晴らしい方法です。 次に、スタイリング、再利用性、拡張性などを考慮してマークアップを調整するとき、私たちが行うすべての変更が私たちを理想から遠ざけることを非常に認識しています。 すべての変更は妥協案であり、変更を加える前にそのように深く検討する必要があります。

静的ワイヤーフレーム

過去数年間、より伝統的な静的ワイヤーフレームにはかなりの嫌悪感が見られました。 彼らはまだ多くの価値を追加できると思います。 また、すべてのプロジェクトで必要になるとは限らないと思います。 私たちがそれらを使用するとき、私たちは通常、優先順位に集中するのを助けるために、狭い幅でそれらを行います—これは不便です—。 私たちの視覚的な不動産を制限することは、この焦点を強制します。 KeynoteからBalsamiqまで、これを行うために多くのツールを使用してきました。 正直なところ、これらのツールのいずれかがその仕事をします。 快適なものを見つけて、仕事に取り掛かりましょう。

スケッチもたくさんします。 ホワイトボード、鉛筆と紙、さまざまなスケッチアプリ。 私たちはこのようなものの写真を撮り、それをクライアントと共有し、意図的にすべてを非常に生のままにします。 生っぽさは私たちが行うことの重要な部分です。 これは、研磨の恩恵を受けないドキュメントの研磨に時間を浪費していないことをお客様に知らせるのに役立ち、フィードバックに焦点を合わせ続けます。 最後に必要なのは、ワイヤーフレームの色について誰かがコメントすることです。

インタラクティブワイヤーフレーム

従来のワイヤーフレームからの脱却の一環として、よりインタラクティブなアプローチが採用されています。 アジャイルマニフェストがドキュメントよりも動作するソフトウェアを促進するように、私たちの業界の多くは、プロトタイプを介して相互作用の意図を示すことは、静的に説明しようとするよりもはるかに強力であると信じています。 最近では、ラピッドプロトタイピングに利用できるツールは非常に優れています。BootstrapやFoundationなどのフレームワーク。 BourbonやPureCSSなどのCSS（またはSass and LESS）ツールキット。 InVisionやMarvelなどのビジュアルプロトタイピングツール。 MacawのようなビジュアルWebデザインおよび開発ツールや、Keynoteのようなプレゼンテーションツールでさえ、非常にインタラクティブなワイヤーフレームを作成するために使用できます。

このアプローチの利点は、説明しようとする代わりに、アイデアを人々に示すことができることです。 写真が千の言葉の価値がある場合、プロトタイプは千の写真の価値があります。

現在、これを理解している組織と協力しています。 彼らの目標の1つは、ラピッドプロトタイピングをプロセスの早い段階で導入して、プロトタイプをユーザビリティ調査や本番コードに使用できるようにすることです。 彼らとの私たちの仕事は、彼らのすべてのWebプロパティで使用できるコンポーネントのシステムを作成することに焦点を当てています。 このシステムは、最終的にはチームがインタラクティブなワイヤーフレームを非常に迅速に構築できるようにするためにも使用されます。 ブランドを念頭に置いて構築するため、インタラクティブなワイヤーフレームは製品リリースと非常によく似ており、UXテストに非常に役立ちます。

この種のアプローチは、Webプロパティの長期的な成功に焦点を当てています。 これは、プロトタイプの作成にすべての分野を関与させ、その設計と開発中に学んだことをさらなる決定に役立てることによって、前に説明した「1つの成果物」ワークフローを具体化します。 後付けとしてCSSをハッキングするのではなく、成熟したフロントエンドシステムを構築する組織へのシフトが見られていると思います。 組織に実際のユーザーでWeb作業の静的バージョンをテストする機能を提供することは、近い将来、これを標準として定着させるための主要なステップです。

UIの設計と開発

「優れた設計は問題解決です。」

— Webデザインの芸術と科学、Jeffrey Veen（2000） 。

デザイナーであるあなたのそれらのために、この引用は非常に真実を鳴らします。 多くの人が私たちの仕事を装飾として見ていますが、それだけではありません。 過去数年間、私はジェフの発言の感情に心から同意していることに気づきましたが、設計者がソリューションを過度に洗練する傾向があることも強く認識しています。 これは、私が「スイッチングポイント」と呼んでいるものにつながります。

設計のアクティビティを3つのフェーズ（美的感覚の確立、問題の解決、およびソリューションの改善（上記のとおり））に分割すると、問題解決からソリューションの改善への移行が切り替えポイントになります。 これは、Webの媒体に移行する最後の責任ある瞬間です。 これを行わないと、その改良フェーズを複数回実行することになり、非常に非効率的です。

PSDの調整に何時間も費やし、それを開発者に渡してビルドし、1〜2週間後にもう一度確認したことがある場合は、この痛みを経験しています。 静的ピクセルをプッシュしてリファインおよびリファインするために行ったすべての労力は無駄になります。 デザインがメディアを変更するとすぐに（Photoshopまたはその他のツールの静的デザインからブラウザーのHTMLおよびCSSに）、別の改良パスが必要になります。 切り替えポイントの背後にある考え方は、これがいかに非効率的であるかを認識することです。 静的ツールを使用して改良する代わりに、基本設計をできるだけ早くコーディングし、最終媒体であるWebで改良を処理します。

これには多くの場合、デザインの組み合わせが必要であり、文字通り一緒に座って、これらの改良を実現する必要があります。 これは時々遅くて痛みを感じることがありますが、実際には関係者全員にとって非常に有益です。 デザイナーがフロントエンド開発者と彼らが見たいスタイル調整の種類を共有するとき、フロントエンド開発者は洗練されたデザインで何が重要であるかを学びます。 フロントエンド開発者が要求された変更を行う間、設計者はそれらの変更がどのように行われるかを確認し、おそらく少しCSSを学習します。 このプロセスにより、誰もが賢くなります。 これは、次にこれら2つのペアが実行されるときに、はるかに高速になることも意味します。

最近では、UIの会話を開始するための多くのツールに慣れている必要があり、プロセスの早い段階でそれらのデザインのコーディングをシフトする必要があります。 これを行うためのいくつかの方法を見てみましょう。

スタイルタイル

サマンサウォーレンは、ウェブの「視覚言語を定義する」方法としてスタイルタイルを導入したときに、新境地を開拓しました。 ブランディングのバックグラウンドを持つ私たちの人々は、すぐにスタイルタイルがどれほど価値があるかを見ました。

スタイルタイルは非常にシンプルです。 それらには通常、カラーパレット、タイポグラフィの選択、テクスチャ、図像またはイラストのスタイルが含まれます。 それらは意図的にフルページのコンプではありません。 代わりに、それらは、正しい方向に進んでいるかどうかを判断するのに十分な設計を表しています。 このため、クライアントが必要なものを表現した場合に最適に機能しますが、同じページにいると完全に確信しているわけではありません。

私は、主にその速度のために、スタイルタイルを高く評価するようになりました。 Photoshopでホームページとサブページをデザインするのに1週間を費やしていたところ、今では数時間でシンプルなスタイルのタイルを作成できます。 これにより、時間とお金を節約し、正しい方向に進んでいるという自信を得ることができます。

サマンサはスタイルタイルサイトにいくつかの例を持っています、そして実際のプロセスでのそれらの使用をカバーするいくつかの素晴らしいリソースが以下にリストされています：

• 「GetYour（Visual）Style On」：イェセニアペレスクルス、ダンモール、テキサス州オースティンで開催されたArtifact Conferenceでの私のプレゼンテーション（2013年5月13日）。
• 「スタイルタイルを使用したより迅速な設計決定」：テキサス州オースティンで開催されたイベントでのサマンサウォーレン（2015年2月）。
• サマンサウォーレンとのスタイルガイドポッドキャスト

それらの静的な性質のため、私たちはそれらをあまり頻繁に使用しません。 私たちの最初のデザインの方向性は、通常、要素のコラージュまたはスタイルのプロトタイプで確立されます。どちらも次に説明します。

要素のコラージュ

ダンモールは、「特定の論理や順序のない異種のピースのアセンブリ」として要素コラージュを紹介しました。 それらの多彩な性質は、あなたが見ているものが完成したデザインではないことを明らかにします。 むしろ、要素のコラージュは、システム内で一緒に存在する可能性のあるさまざまなコンポーネントのコンテキストをクライアントに提供します。 それらは、ワイヤーフレームの骨に肉を付けるのに役立ちます。 彼らは私たちが進んでいる方向を想像するのに役立ちます。 それらは私たちが私たちのサイトの構成要素を視覚化し始めることを可能にしますが、全体を見失わないように私たちを励まします。

要素のコラージュの利点の1つは、表示するコンポーネントを選択できることです。 クライアントは、検索がユーザーにどのように表示されるかを本当に気にしていますか？ すごい！ たぶん、あなたはその懸念に対処するためにいくらかの時間を費やすべきです—それを要素のコラージュに入れてください。 クライアントは、召喚状のボタンに執着していますか？ それらを要素のコラージュに入れます。 この選択と選択の考え方により、プロジェクトで最も重要なものに合わせて各コラージュを簡単に調整できます。 あなたのクライアントはこれを非常に高く評価するでしょう。

最近のプロジェクトでは、クライアントのWebプロパティの1つを再設計するための設計の方向性を確立する必要がありました。 Katie Kovalcin（私たちのデザイナーの1人）は私たちのチームのデザイン作業を主導しており、彼女はホームページのコンプを行う代わりに2つの要素のコラージュを作成することを選択しました。

これら2つのデザインコンセプトの作成に費やした合計時間は約16時間でした。 ケイティに2つのホームページコンプをするように頼まれたら、これにはどれくらいの時間がかかるだろうかと尋ねると、彼女は次のように答えました。

「このステップでは、彼らの新しい美学を理解しようとすると、ページの階層をレイアウトして相互作用を理解しようとしているときに、その美学を見つけるのは難しいでしょう。 したがって、美的感覚を理解する方法としてホームページ全体をレイアウトすることは、私たちがどれだけの作業をしなければならないかにもよりますが、時には最大1週間かかることがあります。 おそらくそれぞれ25〜30時間近くだと思います。

しかし、要素のコラージュから離れると、使用するボタンのスタイル、フォント、色を把握するためのスクランブリングがあまりないため、ページレイアウトやその他すべてのものを進めるのは非常に簡単でした。 。」

つまり、要素のコラージュを使用することで、美的感覚を確立するために費やした時間を4分の1にしました。

上記のケイティの引用には、もう1つの非常に興味深い表現があります。 彼女は、「ページの階層をレイアウトし、相互作用を理解しようとしているときに、その美学を見つけるのは難しいでしょう」と述べました。 言い換えれば、ホームページのコンプから始めることは、あまりにも早く、あまりにも多くを達成しようとしています。 最初に小さな一歩を踏み出すと（要素のコラージュやスタイルタイルを使用して）、目の前にある設計上の課題を分割して克服することができます。 これにより、クライアントはより頻繁に会話に参加できるようになり、進行中に学習できるようになり、すべてがより良い仕事につながります。

スタイルのプロトタイプ

スタイルのプロトタイプは、インタラクティブなスタイルのタイルと考えることができます。 スタイルタイルに含める可能性のあるものと同じタイプ（ブランドマーク、見出し、段落スタイル、ボタンスタイル、リンク処理、推奨色）がスタイルプロトタイプに含まれています。 唯一の違いは、さらに一歩進んでコーディングすることです。

これらの利点は、実際のWebタイプ、実際の色、実際のホバー状態、Webベクトルを使用したイラストのスタイル、およびタイプと基本的なレイアウトがどのように応答するかを表示できることです。 クライアントに、選択したブラウザでそれらを確認するように依頼します。 これにより、ブラウザをサポートすることの意味についての会話が始まります。 たとえば、 border-radiusをサポートしていないブラウザを使用している場合、丸みを帯びた角は表示されません。

また、約1日でスタイルのプロトタイプを作成できます。これにより、スタイルタイルと同じ効率のメリットが得られます。 彼らは彼らと対話することができるので、クライアントはそれらを愛しています。 彼らは彼らの携帯電話やタブレットでそれらを見ることができます。 彼らは彼らと遊び始めることができます。

最後に、私たちのほとんどがWebデザイナーがコーディングを学ぶべきだと信じている世界では、スタイルのプロトタイプはHTMLとCSSを書くための素晴らしい入門書です。 それらの単純さのために、コーディングをしていない設計者でさえ、それらを構築する方法を理解することができます。 彼らはそれを知る前に、見たい変更を静的にモックアップするのではなく、本番CSSを改良する自信があります。

元のSparkboxサイトを設計したとき、および最近再設計したときは、スタイルのプロトタイプを使用して設計の方向性を確立しました。

アトミックデザイン

Jeremy Keithは、「モバイルWebはありません」というタイトルの彼のBreaking Development基調講演で、「サイトのアトム」から設計を開始するというアイデアを最初に紹介しました。 ブラッド・フロストは、2013年6月に、Webの「コンポーネントのシステム」の設計に取り組むためのメンタルモデルの概要を説明したときに、この用語を形式化しました。

基本的な前提は、コンポーネントの再利用可能なシステムを作成するために、作業で5つのレベルの粒度を考慮する必要があるということです。 最小レベルはアトムと呼ばれます。 単純なHTML入力または入力のラベルについて考えてみてください。 これらの原子を組み合わせて分子にすることができます。 おそらく、検索分子はボタン、ラベル、および入力で構成されています。 これらの分子を組み合わせて生物を形成することができます。 Webサイトのヘッダーには、検索、ブランド、ナビゲーションの分子が含まれている可能性があります。 これらの有機体は、テンプレートとページを形成するためにまとめられます。 テンプレートは一般的なデータでいっぱいです。 ページは、実際のデータが挿入されたテンプレートです。 この理論はすべて、よりモジュール化され、再利用可能で拡張可能なコードを作成するのに役立ちます。

この考え方に沿ってプロジェクトに取り組んだときに私が学んだことの1つは、リファクタリングから進化させると、原子設計がはるかに簡単になるということです。 私たちが作業する一般的な方法は、原子、分子、または有機体についてあまり心配することなく、HTMLおよびCSSで小さなコンポーネントを構築することです。 次に、インターフェイスでUXとUIの問題を解決したら、そのコードをアトミ​​ック構造にリファクタリングできます。 この逆のアプローチは、分子と生物の違いを考えすぎないようにすることを意味します。 代わりに、システム自体が進化するにつれて、さまざまなレベルを進化させることができます。

アトミックアプローチの結果は、システムに統合できるパターンのライブラリです。

パターンライブラリ

パターンライブラリは、まさにそのように聞こえます—システムに存在するパターンのライブラリです。 最近、パターンライブラリソリューションに取り組んでいる人はたくさんいます。 ブラッド・フロスト、アンナ・デベンハム、ジーナ・ボルトン、バーモン・ペインターなどの人々がこのトピックについて話し、書いています。 実際、BradとDave Olsonは、今日利用できる最も有名なツールの1つであるPatternLabを作成しました。 パターンラボは、特定のコンテンツをHTMLモジュールから分離できるため優れており、パターンのシステムを簡単に構築できるアトミックフレームワークを提供します。 また、開発中のテスト用にいくつかの優れた機能が追加されています。 全体をローカルで実行するのは非常に簡単で、クライアントに簡単に表示できるシンプルなインターフェイスを備えています。 パターン駆動型の設計を検討している場合は、ここから始めるのが最適です。

現在、この分野では多くのことが起こっています。さらに学びたいと思っている私たちのために、他にも多くのリソースがあります。 Bradは、AnnaDebenhamおよびBrendanFalkowski（および他の数人）と協力して、Webサイトスタイルガイドリソースを作成しました。 これは、パターン駆動型の設計と開発をカバーする多くの例、記事、講演、ポッドキャストなどの膨大なコレクションです。

これまでの最大の課題は、パターンがバックエンドシステムに統合された後、パターンライブラリを最新の状態に保つ方法を見つけることです。 私はこれに対する完璧な解決策をまだ見ていませんが、それに取り組んでいる多くの明るい心があります。 この問題を解決するために熱心に取り組んでいる組織の素晴らしい例として、ロンリープラネットのRizzoをチェックしてください。 完璧な長期的な解決策がなくても、このように設計することで大きなメリットが得られます。 それはあなたがモジュール式に考え続けることであり、これは私たちが行うフロントエンドの仕事を統合し維持することをはるかに簡単にします。

ブレークポイントはどうですか？

プロセスについて話したり書いたりするときはいつでも、ブレークポイントの選択について尋ねられます。 不思議なことに、この会話は、私たちの応答性の高い仕事ではほとんど発生しません。 確かに、一部のクライアントは、システムのブレークポイントを文書化するという名目で、分析のレビューとデバイスの優先順位付けに多大な労力を費やして私たちのところにやって来ます。 この考え方は、私にはあまり意味がありませんでした。

最初に言ったのはスティーブン・ヘイだったと思います。「小さく始めて、サイトが壊れたらブレークポイントを追加してください。」 私たちのサイトには多くの場合、数十のブレークポイントがあります。それらのほとんどは、一般的なデバイスサイズと一致していません。 コンテンツとデザインが調和して機能しなくなったら、修正します。

現在、StephanieRiegerがメジャーブレークポイントと呼ぶものとマイナーブレークポイントと呼ぶものには違いがあります。 （ブレークポイントやツイークポイントと呼ばれることも聞いたことがあります。）それぞれについて説明します。

主なブレークポイント

レイアウトにシフトがあり、設計変更で別々のモジュールが連携する必要がある場合は、共通のブレークポイント（メジャーブレークポイント）を使用します。 おそらく、小さいビューポート幅の製品のスタックリストを大きいビューポート幅の2列レイアウトに移動するレイアウト調整があります。 この場合、同じビューポート幅で発生する必要のある他の多くの変更がある可能性があるため、このレイアウトシフトが発生する場所を追跡する必要があります。

私たちが行う作業のほとんどには、3つから6つの主要なブレークポイントがあります。 これらはワークフローでSass変数として設定されることが多いため、後で1か所で変更を加えることができます。 また、サイトの主要なセクションに一連の主要なブレークポイントがあることもよくあります。 たとえば、サイトのヘッダーに3つの主要なブレークポイントがあり、フッターに3つの完全に異なる主要なブレークポイントがあるとします。 これにより、作業がモジュール化され、システム全体との一体性を維持しながら、これらのセクションを独立して進化させることができます。

マイナーブレークポイント

タイプや間隔をさらに微妙に変更する必要がある場合でも、メディアクエリを使用してこれらの調整を行うことができます（マイナーブレークポイント）。 これらは通常、フォントサイズ（行の長さを抑えるため）やビューポートの幅が大きくなるにつれて間隔を広げるなどの1回限りのスタイル変更です。 これらの小さな調整は、あなたの仕事を本当に際立たせることができる細部への深い注意を示しています。

これらにプリプロセッサ変数を使用する代わりに、通常はハードコードされた数値を使用します。 場合によっては、プリプロセッサ計算を使用して、これらを主要なブレークポイントとの相対関係に保つこともあります。 たとえば、30em $bp_header-show-navというメジャーブレークポイントがある場合、 $bp_header-show-navブレークポイントよりも5emの見出しのフォントサイズを調整したい場合があります。 この場合、それは35emで発生します。 将来のある時点でそのメジャーブレークポイントを32emにシフトすると、37emでマイナーな変更が発生します。 メジャーブレークポイントが変更される可能性があると思われる場合は、マイナーブレークポイントを比較的考慮して考えると役立ちます。 最善の決定を下すには、ケースバイケースで判断を下す必要があります。

参考文献

ブレークポイントの詳細については、次の記事を確認してください。

• 「ブレークポイントはありません」
• MarkBoultonによる「TheIn-Between」
• StephanieRiegerによる「実用的なレスポンシブデザイン」

移行

最近では、すばらしいサイトを構築するだけでは不十分です。 また、構築するものの寿命も考慮する必要があります。 アトミックデザインのようなアプローチは役に立ちますが、もっと多くのことをする必要があります。 現在、私たちのプロジェクトのほとんどには、ある種のトレーニングコンポーネントが含まれています。私は、クライアントにCMSの使用法を教えることについて話しているのではありません。 組織は、Webが提供する価値を真に理解し始めると、Webプロパティを所有および維持するための独自のチームを構築することを決定しています。 私たちが長持ちするものを作りたいのなら、私たちの仕事を引き受けるチームがそれを適切に維持できることを確認する必要があります。 このため、Web用に構築するために使用する手法についてさらに詳細なトレーニングを行っています。

幸いなことに、移行に取り組むための多くの一般的な方法があります。 ソース管理で作成するすべてのリポジトリには、便利なreadmeファイルがあります。 コードをサポートする自動テストを提供します。 また、クライアントがサイトの速度を維持し続けることができるように、プロジェクトのパフォーマンス予算を移行するいくつかの方法に取り組んでいます。 アトミックシンキングに加えて、私たちが構築するサブシステムの実用的な例も提供します。 たとえば、顧客のブランドのコンテキストですべてのWebプロパティでタイポグラフィがどのように機能するかを検討するのが一般的であるため、このタイポグラフィシステムに関する詳細なドキュメントと、その使用方法を示す例のページも提供する場合があります。 私たちの仕事へのこれらの種類の追加は、私たちのチームからクライアントのチームにコードを渡すときに、はるかに簡単な時間を作ります。

これらすべてに、より深い影響もあります。 構築しているシステムを誰が保守するかを理解することも、テクノロジーの選択と開発手法に関して行う決定に影響を与えるはずです。 つまり、クライアントのWebチームがコマンドラインからAssembleとローカルサーバーでGruntを使用する準備ができていない場合は、クライアントの機能により適した作業方法を見つける必要があります。 あなたは彼らのためにこれを構築していることを忘れないでください。

また、クライアントのWebデザインおよび開発チームをプロジェクトに招待することも非常に有益です。 プロジェクトをクライアントのチームをトレーニングする機会として使用することは、信じられないほどの価値を示し、競合他社の中から簡単に選択できるようにします。

プロセスを超えた人々

ワークフローを絶えず進化させることで私が学んだ最後のことの1つは、使用することを選択したプロセスは、それを使用する人々よりもはるかに重要ではないということです。 より良いウェブ製品を作りたいのなら、まずは人材を育成することから始めましょう。 これにより、プロセスやワークフローを微調整するよりもさらに進んでいきます。

チームを幸せに保つ

これらの同じ線に沿って、MihalyCsikszentmihalyiによるFlowを読むことをお勧めします。 この本では、彼は個人の幸福をよりよく理解するために彼が行った研究について説明しています。 彼は、彼が「フローチャネル」と呼んでいるものを説明し、 x軸に沿ったスキルレベルとy軸に沿ったチャレンジレベルをグラフ化します。 フローチャネルは、スキルが適切な課題に直面する領域です。 スキルに対するチャレンジが多すぎると不安が生じ、スキルに対するチャレンジが少なすぎると退屈になります。

これは、私たちが日常業務のどこに挑戦するかを考えることによって、私たちがしていることに変換することができます。 Sparkboxでは、学習の文化について話します。 それは（うまくいけば）私のチームのスキルが継続的に向上していることを意味します。 したがって、幸せになるには、継続的に増加するスキルに合わせて、継続的に増加する課題を見つける必要があります。 このイノベーションの必要性と、クライアントの予算における経済的責任とのバランスを取るのは私たちの責任です。

これは注意が必要です。 私たちにとって、それは私たちが車輪の再発明をやめる必要があることを意味します。 すべてのプロジェクトで同じ問題を繰り返し解決するのではなく、十分にテストされたインターフェイス要素のライブラリを検討するようになりました。 つまり、各顧客がイノベーションのためにどこにお金を使うべきかを理解する必要があるということです。 そして、私たち全員が同じページにいるように、それらのクライアントと私たちのチームの間にはかなりの透明性が必要でした。

結局、それはより多くのコンテンツチームになります—それは彼らが正しい方法で彼らに挑戦するので彼らがする仕事を愛するチームです。 そして、それはより多くのコンテンツクライアントになります—彼らがどこにそしてなぜ投資すべきかについてのあなたの推薦を尊重するものです。 これは関係者全員にとって素晴らしいことです。

以降

これは私があなたに深くインスピレーションを与え、ウェブデザインの大胆な新しい世界に勇敢に立ち向かうことをあなたに勧める部分です。 しかし、正直なところ、私はこの章の締めくくりの感情を要約するのに苦労しました。

少し考えてみたところ、これはプロセスへの書き込みが実際には行われないためだと思います。

これらの言葉を読んでいるうちに、Webがどのように機能するかについての自分自身の理解に投資する意欲が高まり、チームメートの理解に投資する意欲が高まったことを願っています。 新しいアプローチを試すことにワクワクしていることを願っていますが、これらのページがうまく機能しない場合は、これらのページを破棄する権限を与えられていることも願っています。 あなた、あなたのチーム、そしてあなたの顧客だけが、プロジェクトに取り組むための最良の方法を見つけることができます。 これが私たちの仕事の本質です。

今がその時です—だから、それを手に入れよう！