ウェブサイトのデザイン: ウェブフローチャートの描き方ガイド

編集者注: この記事の著者はデザイナーの Felix Ding、Ding Yu です。著者がフローチャートと初めて出会ったのは、設計キャリアの早い段階でした。優れたフローチャートは、要件を理解し、複雑なビジネス プロセスを分析し、インタラクションの設計にも役立ちます。

フローチャートの価値を最大限に高めるために、この論文では、開始タグと終了タグ、インターフェース、ダイアログ ボックス、決定ポイント、条件分岐、サブプロセス、ジャンプ ポイント、説明、システム動作などの視覚的語彙の分析に焦点を当てています。

序文

私はデザインキャリアのかなり早い段階でフローチャートを描き始めました。当初、私が描いたフローチャートは、ノードが少なくロジックが簡単なものが多かったです。そのため、中国最大のオンライン決済プラットフォームである Alipay に入社して初めて、複雑なフローチャートがいかに便利であるかを実感しました。 Alipay では、ビジネス要件とプロセスの複雑さ、およびそれらの急速な変化により、それらを理解すること自体が非常に困難な作業になります。この頃から、私はフローチャートを利用して要件を理解し、この方法を使ってインタラクション デザインを行うようになりました。徐々に、フローチャートは魅力を発揮し始めました。製品マネージャーはそれを気に入り、エンジニアも開発のガイドとしてフローチャートを使用するようになりました。

2008 年の秋に、私は自分の経験を「Web フローチャートの描画に関するヒント」というタイトルの記事にまとめ、ブログで公開しました。この記事はすぐに幅広い注目を集めた。さまざまな推奨事項、再版、議論、フォローアップ記事がオンラインとオフラインで頻繁に登場しました。記事で言及された方法に従ってフローチャート テンプレートのセットを作成した人もいました。 4年前に公開されたこの記事は、今でも私の個人ホームページに多くのアクセスをもたらしています。

しかし、上記の記事には、その内容を誤解を招く重大な問題があります。それは、「情報アーキテクチャとインタラクション デザインを説明する」ために Visual Vocabulary を使用していないことです。正直に言うと、執筆当時はこれほど広く知られている語彙の存在を知らず、自分なりの語彙を作り、世間に紹介したのです。そのため、記事の一部は規則に従っておらず、DRY (Don't Repeat Yourself) の観点からはあまり適切ではありません。記事が公開されてから1年後、私は別の記事でこの問題を指摘しましたが、残念ながら前回ほどの注目を集めませんでした。

また、記事が公開されてから数年が経ち、多くの新しい経験やアイデアが蓄積されてきましたので、皆さん、特に英語の読者の皆さんと共有したいと思っています。

ご覧のとおり、最新の内容で「Web フローチャートを描くためのヒント」の英語版が完成し、ダウンロード用に自作の対応するテンプレートも提供されました。

コンテンツ

この記事では、Web フローチャートについて知っておくべき最も重要なガイドラインについて説明します。

基本的な考え方

視覚的語彙

例

ヒントと提案

ツールとテンプレート

1. 基本的な考え方

フローチャートとは何ですか?

名前が示すように、フローチャートは、さまざまな状況でシステムがユーザーの状態、決定、動作にどのように反応するかを説明するために使用される図です。

フローチャートはどのように役立ちますか?

一般的に、フローチャートは、目的に関係なく、プロセスを作成したい人にとって役立ちます。たとえば、工場ではフローチャートを使用して、誰かが負傷したときに適切な応急処置の手順を​​従業員に知らせることができます。もちろん、これに加えて、この記事では、Web デザインのフローチャートの例のみを示します。

フローチャートは、インタラクション デザイナーや製品マネージャーにとって中核的なツールです。それはあなたを助けることができます:

製品のインタラクションフローを設計する

製品が常にユーザーフレンドリーであることを確認してください（想定していなかった障害が発生した場合でも）

散在するワイヤーフレームを統合するのに役立ちます

異なるバックグラウンドを持つ同僚とのコミュニケーションを支援します。たとえば、エンジニアが開発を進めるよう指導します。

2. 視覚的語彙

次の数ページでは、サイトワードとその使い方を紹介します。

出発地と到着地

インタフェース

ダイアログボックス

決定ポイント

条件分岐

サブプロセス

ジャンプポイント

説明する

システムの動作

出発地と到着地

開始点と終了点は、インタラクションの開始と終了を示すために使用されます。フローチャートには、開始点が 1 つだけと、終了点が少なくとも 1 つ必要です。

インタフェース

インターフェース要素は、フォームや Web ページなどのさまざまなユーザー インターフェースを表すために使用されます。インターフェース番号は識別子として使用でき、コラボレーション プロセス中に非常に役立ちます。たとえば、電話会議中は、「ノード N」を使用して、指定する特定のインターフェース要素を表現できます。

それだけでなく、デザイナーはこのルールを使用してワイヤーフレームに名前を付けることもできます。たとえば、「23.png」ワイヤーフレームはインターフェース番号 23 に対応します。これにより、エンジニアなどのドキュメントの読者が対応するワイヤーフレームを探す時間が大幅に節約されます。

ダイアログボックス

Web アプリケーションの登場により、Web のインタラクションも線形モデルから状態ベース モデルに移行しました。部分的なページ更新や単一ページ内でのインタラクションは、ますます一般的になっています。最も一般的な形式の 1 つは、フォーム検証エラー後に表示されるエラー プロンプトなどのフローティング メッセージです。しかし、ほぼ同じワイヤーフレームを 2 つ作成するのは不必要なだけでなく、扱いにくいものでもあります。そこで、Javascript によってレンダリングされるこの種のモーダルまたは非モーダル ダイアログ ボックス用に、「ダイアログ ボックス」と呼ばれる新しい要素を特別に作成しました。

注 1: 私の友人で、上級技術者であり起業家でもある Cao Xiaogang (@caoxg) は、UML (Unified Modeling Language) ステート マシンを使用して、Web アプリケーションの状態と状態間の遷移を記述しています。このステートマシンをよりシンプルでデザイナーに優しいダイアグラムに変える方法を探しています。

注 2: Web アプリケーション (具体的には、デスクトップ アプリケーションのように見えるがブラウザーで実行されるアプリケーションではないもの) を設計していない場合は、Javascript に依存したり、使用したりしないことをお勧めします。具体的な理由は当然本題から外れるので、ここでは詳しく述べません。答えを知り、私の「JapMag」デザイン言語について知りたい場合は、http://dingyu.me/portfolios/dingyu-me をご覧ください。

決定ポイント

決定ポイントは、ユーザーが決定を下す必要がある場所です。通常、プロセスがこのポイントに達すると、インターフェースはユーザーが次にどこに行くかを選択するのを待機します。

図に示すように、私は通常、肯定的な選択肢 (「はい」) を下向きに流し、否定的な選択肢 (「いいえ」) を右向きに流します。

このルールは、ルール自体が明確で自然であるため、より良い読みやすさを実現します (英語の文章でも同様です)。

このルールは、設計者がフローチャートを計画するのにも役立ちます。フローチャートの主線は左側にあり、上から下に流れ、分岐は右側にあるため、フローチャートの構造全体が自然に左から右、上から下に流れます。

注: 実際、私はジョージ・W・ブッシュ元米国大統領の自伝「Decision Points」を読みました。だから、このページを書いているといつもこの本を思い​​出します。

条件分岐

条件分岐は決定ポイントに似ていますが、まったく異なる機能を実行します。決定ポイントでは、決定はユーザーによって明示的に行われますが、条件分岐では、システムがバックグラウンドで適切なパスを自動的に選択します。

サブプロセス

サブプロセスは、システム全体で再利用できる比較的独立したプロセスです。たとえば、ユーザー認証やネットワーク アクセスなど、同じ (頻繁に使用される) タスクの一部をサブプロセスにパッケージ化し、それらをより大きなフローチャートまたは特定のフローチャートに統合することができます。

フローチャートの中にサブプロセスが含まれている場合は、誰かに求められる前に、関連するサブプロセス図をすべて提出しておくことをお勧めします。

ジャンプポイント

非常に複雑な状況では、ユーザーが別のパスに直接ジャンプする必要がある場合、ジャンプ ポイントが必要になります。

前述したように、円内の数字はノードを指しており、そのノードがジャンプ ポイントの宛先となるノードです。

明らかに、ジャンプ ポイントはパスの終点です。

説明する

説明はコミュニケーションの時間を節約するのに便利な方法です。しかし、誤解しないでください。フローチャートを読む人とはさまざまな形でコミュニケーションを取る必要がありますが、説明はリマインダーやプロンプトとして役立ちます。私の経験では、これによって多くの時間が節約されます。

システムの動作

システム動作とは、システムによって実行される一連のバックグラウンド操作を指します。たとえば、ユーザーがログインに失敗したときにデータを記録したいという場合、フローチャートでは「エラーログを収集する」というシステムの動作として表現できます。

デザイナーやプロダクトマネージャーとして、バックグラウンドで行われるすべての操作を図に書き込む必要はありませんが、ユーザーエクスペリエンスに関連する操作や、自分たちにとって重要な操作はフローチャートに書き込む必要があります。さらに、それらを仕様書やドキュメントに書き込んで、誰もがその意味を理解できるように再度明確に記述する必要があります。

要素の概要

3. 例

ログイン

次の図は、ユーザーがログインしたときにシステムがどのように反応するかを説明するために使用される、単純なログイン フロー チャートです。

セキュリティチェック

次のフローチャートは、システム動作やサブプロセスなどの要素の使用方法を示しています。これは実際のプロジェクトからのものですが、著作権の問題により私が若干変更しました。

その他の実例

ご覧のとおり、ビジネス ロジックがいかに複雑であっても、フローチャートを使用してシステムの動作を説明できます。

4. 提案とヒント

調査結果に基づいて、ガイドワイヤーフレーム

ユーザーとその特性は、フローチャートの描画を導く主な要素です。ユーザー調査により、次のことが明らかになります。ユーザーの過去の経験はどのようなものだったか? ユーザーの期待は何か? 使用シナリオと環境はどのようなものか? これらの質問は、フローチャートの設計において重要な役割を果たします。

同様に、フローチャートはワイヤーフレームを作成するためのガイドとしても機能します。ほとんどの場合、フローチャートが完成すると、ワイヤーフレームの内容やレイアウトも基本的に決まります。もちろん、フローチャートはまさにワイヤーフレームを接続するためのものです。

注: フローチャートの前に、ユースケースなどの他の成果物があります。このページの焦点では​​ないため、上記の画像ではこれらの内容については触れていません。

フローチャートを完成させる

フローチャートを作成する上で最も難しいのは、考えられるすべての状況をカバーしなければならないことです。私の意見では、複雑なロジックを伴うビジネス ニーズに対処する場合、これは非常に困難です。多くの「もしも」の問題に遭遇し、エンジニアに教えてもらうまで、自分が考慮していなかったことに気づかないこともあります。したがって、完全なフローチャートを作成するには、ユーザーを理解するだけでなく、ビジネス ロジックを理解し、舞台裏のシステム操作メカニズムに精通していることも必要です。

最善のアプローチは、製品マネージャー、エンジニア、およびビジネスニーズに関与するその他の同僚と緊密に連携することです。多くのインタラクション デザイナーが一人で作業し、その後製品会議で厳しい挑戦を受けるのを見てきました。そんなことはしないでください。代わりに、プロジェクトに関係する全員と協力し、プロセス マップ (およびその他の成果物) を一緒に作成して、さまざまな角度から不確実性を排除し、より完全で包括的なものにします (全員が制作にも関与しているため、誰もあなたに異議を唱えなくなります)。

メタデータを忘れずに

コラボレーションとドキュメント管理の観点から、少なくともフローチャートには名前を付け、作成者、バージョン、時間を書き留めておく必要があります。

さらに、フローチャートに視覚的な語彙が使用されている場合でも、同僚やクライアントが複雑な要素を理解できない可能性があるため、凡例を追加することを忘れないでください。

5. ツールとテンプレート

数あるツールの中で、私は OmniGaffle と Microsoft Visio をお勧めします。

オムニガッフル

Mac ユーザーにとって、OmniGraffle はこれまでも、そして今も、最適なツールです。機能が豊富であるだけでなく、最も重要なのは、そのユーザー エクスペリエンスが他に類を見ないということです。私の知っているデザイナーの多くは Mac に切り替えて OmniGraffle を使用しています。

マイクロソフトVisio

Windows ユーザーは、作業を大幅に簡素化できる組み込みテンプレートがいくつかある Visio の使用を検討できます。

ステンシル

Allen Le 氏は、私の前回の記事に基づいて一連の美しい Visio テンプレートをリリースしてくれました。大変感謝しています。こちらでご覧いただけます: http://www.allenle.com/archives/1530.html.

OmniGraffle ファンは、私が作成したステンシルを http://graffl etopia.com/stencils/905 からダウンロードできます。

エンディング

この記事を書くのに約 2 週間かかりましたが、母国語ではない英語で書いたため、さらに困難になりました。母国語以外の言語でチュートリアルを書くのは初めてですが、とても楽しく書けています。私にとって、書くことは過去を総括し、創造を続けるための素晴らしい方法であり、誰かがそこから恩恵を受けることができればとても嬉しいです。ご質問やご提案がありましたら、こちらにメッセージを残してください:

http://dingyu.me/blog/the-definitive-guideto-web-flowcharts

出典: Web フローチャートの決定版ガイド

PPTはSlideshareで不可解にブロックされました

出典: Leiphone.com http://www.leiphone.com/flowcharts-web-design.html

元のタイトル: ウェブサイトのデザイン: ウェブフローチャートの描画ガイド

キーワード: ウェブサイト、ウェブ、プロセス、描画ガイド、編集者、この記事、著者、デザイナー、Feli、ウェブマスター、ウェブサイトのプロモーション、収益化