プロセス機械の死!

厳格なスクリプトではなく、いくつかの単純な原則に固執することにより、理想的な設計プロセスを見つけてください。

アプリやウェブサイトの設計に関する正しい方法と間違った方法について、さまざまなアドバイスを聞いています。

「スケッチを使用する必要があります。」
「設計システムまたはGTFO。」
「本物のデザイナーはコードを100%設計します。」
「ワイヤフレームは時間の無駄です。」
「プロトタイプを作成していない場合は、正しく実行していません。」
「紙から始める必要があります。」

設計の正しい方法についてはまったく合意がないと思うかもしれませんが、議論の余地がない点が1つあります。それは、プロセスが線形であるべきだということです。

古典的な線形アプローチは次のようになります。
研究→スケッチ→ワイヤフレーム→静的コンプ→プロトタイプ→コード

ドリト​​スやディンドンを作るために使用するルーベ・ゴールドバーグ風の製造機械のようなものです。アイデアをプロセスマシンにドロップし、マッシュで粉砕して成形品を成形した後、完成品が反対側に飛び出します!予測可能な!効率的!

やや。

プロセスマシンは動作しますが、動作する場合のみです。彼らは適応しません、そしてそれは彼らをもろくします。必要なのは、1台の小さなSabotでプロセスマシンを停止するだけです。

ハンク、別名「サボット」

最近、子供と一緒にFinding Doryを見ていて、「メイキング」映像の一部が飛び出し続けています。

映画には、ハンクという名前のこのタコがいます。

ディズニー/ピクサー

技術的にはセプトパス。彼のキャラクターモデルはとても面倒で、触手を落とし、彼をアニメートできるようにしました。それでも、4,000個の個別のコントロールがあるため、彼は作業するのが非常に困難でした。

プロセスのこの時点では、スケッチやレンダリング、アニマティックスをはるかに超えています。これらの低忠実度のステージは、多くのアイデアを迅速かつ安価に吟味するのに役立ちます。彼らもすでに本物だ。キャラクターリグが構築され、技術的な詳細が作成され、基本的な質問に答えられました。

最終的なアニメーションの段階、つまり3D環境の3Dモデルです。彼らは、生産スケジュールと予算を犠牲にして、兵士として戦うことができたでしょう。代わりに、彼らは本当に面白いことをしました-彼らはスケッチに戻りました。

ディズニー/ピクサー

ハンクの触手の複雑な動きを紙にスケッチすることで、彼らは探していた完璧で滑らかなアニメーションをほんの少しの時間で見つけることができました。シーケンスに満足したら、3Dでアニメーション化して一致させます。彼らはプロセス処方箋ではなくプロセス原則を重視することを選んだため、より短い時間でより良い製品を得ました。

規範的プロセスの治療法

Finding Doryチームは、ロートなプロセスにこだわるのではなく、速度と品質を優先する決定を下すことにより、より良い製品をより速く作りました。

価値のある他のものを選択することもできますが、商業環境で作業している場合は、速度と品質の間のスイートスポットに焦点を当てることがリストの一番上にあるはずです。優れた作品を素早く回すことは、結局のところ、プロのデザイナーやアーティストにとっては大きな問題です。

プロセスを推進する原則を定義することは、ほんの始まりに過ぎません。これらを実践する方法は次のとおりです。

大きな質問から始めます

速度を重視する場合は、最大かつ最も基本的な質問を把握してプロジェクトを開始してください。 Get Realでは、これは「エピセンター設計」と呼ばれます。

ページのコアから始めて、外側にビルドします
エピセンターの設計は、ページの真の本質であるエピセンターに焦点を合わせてから、外側に構築します。つまり、最初は、ナビゲーション/タブ、フッター、色、サイドバー、ロゴなどの四肢を無視します。代わりに、震源地から始めて、最も重要なコンテンツを最初に設計します。
ページがなければ絶対に生きていけないものは何でも、それが伝記者です。たとえば、ブログ投稿を表示するページを設計している場合、ブログ投稿自体が震源地になります。サイドバーのカテゴリ、上部のヘッダー、下部のコメントフォームではなく、実際のブログ投稿ユニットではありません。ブログ投稿ユニットがないと、ページはブログ投稿ではありません。
そのユニットが完成した場合にのみ、ページの2番目に重要な要素について考え始めるでしょう。次に、2番目に重要な要素の後、3番目に進みます。それが震源地設計です。
Epicenterの設計では、従来の「フレームを構築してからコンテンツをドロップ」モデルを使用しません。そのプロセスでは、ページシェイプが構築され、ナビゲーションが含まれ、次にマーケティングの「もの」が含まれます。
 が挿入され、最後に、コア機能、つまりページの実際の目的が、残っているスペースに注がれます。これは、最優先事項を取り、最後まで保存する後方プロセスです。

これが重要な理由の例を次に示します。私は、ユニークでおそらく機能しないオーディオインターフェースを使用した、小さなサイドプロジェクトのiOSアプリに取り組んでいました。スピードを重視しなければ、この奇妙なアイデアの基礎にある無数の詳細を設計するのに無数の時間を費やすことができたでしょう。結局のところ、設計は古典的な線形プロセスのコードよりも前になります。

代わりに、このアイデアが実行可能かどうかを判断するためにコードを開始しました。そうではなかった!そのため、計画を調整し、膨大な時間とエネルギーを節約しました。

WMGMTCATMQITLAOTと聞いてください。

最初に回答が必要な質問を理解したら、次のことを自問してください。
「どのメディアが最短時間で質問に対する最も明確な答えを提供してくれますか?」

私のサイドプロジェクトの場合、答えはコードでした。 Basecamp.comのページの場合、多くの場合、答えはテキストまたはスケッチです。あなたにとっては、まったく別の何かかもしれません。

ギアを変更するタイミングを知る

それはあなたに始める場所を与えてくれますが、別のメディアに切り替えるときをどのように知っていますか?抵抗するとき。

車を運転することを考えてください。高速道路を走り抜けます。満足のいく子猫のようにエンジンがゴロゴロと鳴ります。しかし、その後、丘を登り始めます。使用しているギアは巡航には適していますが、山登りには適していません。速度を維持するために、新しいギアにシフトします。

ここも同じです。しかし、車とは異なり、選択したメディアであまりにも多くの抵抗を経験したという確固たる指標はありません。幸いなことに、ほとんどのデザイナーとアーティストは、より忠実なメディアに切り替える必要がある場合にしっかりと対応しています。これは、結局、従来の低忠実度→高忠実度の線形プロセスと並ぶ部分です。スケッチが有用な洞察を与えなくなると、スケッチから先に進む準備ができたことを知っています。

このポイントに到達したら、次に重要な一連の質問を見つけて、もう一度質問してください。「どのメディアが私の質問に対する最も明確な答えを最短時間で提供しますか?」

2番目のケース-より低い忠実度へのシフト-はより困難です。どちらも、人々がそれをあまり練習していないからであり、また、それがトリッキーだからです。コードで作業してください。 100%忠実に作業しているため、メディアが質問に答える能力に制限はありません。しかし、質問に素早く答える能力には限界があります。

あまりにも多くの仕事をしているように感じて、自分が道を追求していないと感じるとき、それはあなたが撤回する必要がある本当に良い兆候です。思ったほどクリックしていないように感じたら、再評価します。気をつけてください、そうすればあなたはその感覚を身につけ始めるでしょう。

有利な媒体を使用する

メディアへの切り替え(またはメディアへのこだわり)の3つ目のケースがあります。これは抵抗を気にせず、基本的な真理にのみ気を配ります。プロセスは結果に影響します。鉛筆で何かを描くことは、マーカーで描くこととは異なって見えるように、ブラウザで設計することは、スケッチで設計することとは異なる結果を生むことになります。

媒体が作業にどのように影響を与えるかを理解すればするほど、媒体が残すマークの種類が増えるほど、媒体を有利に使用できるようになります。デザインを表現力豊かにしたいですか?おそらく、Sketch、Illustrator、または* gasp * Photoshopのようなビジュアルツールを使用する方が良いでしょう。最小限の軽量設計が必要ですか?コードでの設計に固執します。

実用的な例

規範的なプロセスの危険性について説明したので、あなたと共有したいのですが…私のプロセスです。あなたがステップバイステップに従うことはできません!原則を使用してプロセスをガイドする方法の実例を紹介します。

Basecampでクライアントと連携する新しい方法を開始します。私の仕事は、Basecamp.comで新しいページを作成してマーケティングすることでした。以下がその結果です。

大きな質問の決定、メディアの選択

これは新しいサイトでも、まったく新しいレイアウトでもありません。まず、このページの目的、何を言おうとしているのか、全体的な構造を把握する必要がありました。

「どのメディアが最短時間で質問に対する最も明確な答えを提供してくれますか?」

コンプとスケッチが公開されました。これは、既存のデザインと既存のテンプレートに組み込まれています。すぐにコードにジャンプできますが、この時点ではマークアップはノイズです。テキストはちょうどいいです。

半焼きコピーの束

忠実度の向上

ページのすべてのコピーを完了するのに十分な長さのテキストを使いませんでした。概要と、この機能についてどのように話したいかを理解したら、ギアをコードに変更しました。

どうして?

テキストドキュメントでは、行が未亡人を残すかどうか、段落が「感じた」かどうか、画像がどのように流れるかなどについては何もわかりませんでした。新しい質問のいくつかは静的なcompで回答できたかもしれませんが、compをコードに正確に一致させるために時間を無駄にしない限り、それはcopy fitに関する質問には答えませんでした。結構です。

コード内のコピー編集の作業

忠実度を選択的に低下させる

数回のコピーリビジョンの後、ページが形になり始めていました。視覚的には、機械的で圧倒的でした。もっと表現力豊かにしたかったので、いくつかのアイデアをリフするためにスケッチに切り替えました。

ほとんどの部分はコードにとどまることもできましたが、Sketchを使用すると、コードを書くよりもはるかに迅速に多くのアイデアを発動できました。また、これらのアイデアを互いに直接比較することができ、CSSネズミの巣をすべてのチャーンから離れることはありません。ウィンウィンウィン。

たくさんの中途半端なスケッチコンプ

それらのどれも完全に焼かれていないことに注意してください?関係ないからです!これらは、クライアントプレゼンテーション用または開発者のハンドオフ用ではありません。彼らは私が何かを理解するのを助けるためにそこにいます、そして彼らはゴミです。それらを磨くために時間を投資することは、労力の無駄です。

仕上げ

方向性がわかれば、残りの部分はコード化されました。コピーを磨き、スクリーンショットを打ち抜き、常に最終的な重要な質問「これは出荷する準備ができていますか?」に対して評価します。 Basecampのライブクライアントのページをご覧ください。

これは、すべてのプロジェクトがうまくいく方法ではありません。 Procreateで何かをスケッチするときもあれば、すばやく汚いビジュアルコンプから始めるときもあれば、Sketchでコピーを書くときもあれば、コードで100%働くときもあります。それはすべて手元のプロジェクトに依存します。

原則を使用して、常に車輪を再発明していると感じることなく、ケースバイケースでプロセスをガイドする方法についての洞察が得られることを願っています。

あなたのプロセスとあなたがする仕事の種類について考えてください。あなたにとって重要な原則を定義し、最初に重要なことに集中し、作業中の媒体が現時点で適切かどうか疑問を持ち続けます。あなたの仕事はそれにより良くなるでしょう。