コミュニティ支援のデザインプロジェクトが公開されるまでのデザインプロセス | アドビUX道場 #UXDojo

連載

エクスペリエンスデザインの基礎知識

あらゆる場所でデザイナーは腕をまくり、持ち前のスキルで社会に貢献する手段を探っています。大切にしている信念、または明確に強く関心を引かれた最近の出来事が理由で、コミュニティのためのデザインに興味があるすべての人に向けて、この記事では事例を元にした簡単なデザインプロセスのチュートリアルを紹介します。

まさかと思われるかもしれませんが、デザインには力があり、人生を変え、影響を与え、インパクトをつくりだします。社会にどのように貢献するかは、あなた次第です。

アイデアを実現するには…

アイデアがたくさん浮かんだとして、重要なのはその実行です。コミュニティに貢献したいと思ったら、どのように進めればよいのでしょうか？次の質問に率直に答えると、コミュニティプロジェクトを成功させる準備ができます。（注: 読者がデジタルツールや製品をつくりたがっているという前提で書いていますが、この内容はデジタル分野に限定されるものではありません）

• なぜそれをつくりたいのか?
• どのような影響を与えることを期待しているか?
• 対象にしているのは誰か?
• いつ頃公開したいのか?
• どこで利用されるのか?
• それがどのようにコミュニティを改善するか?
• 情熱を抱いている対象か?（つまり、今後数年間にわたってプロジェクトやリソースを管理する強い意思があるか?)

個人的な話: 私が『The Guide to Allyship』の制作に至ったのは、協力者がその約束を全うしなかったという個人的な経験があったためです。協力者として手を上げることと、その役割を果たすことは別であると気づかされました。おそらく、より良い協力者になるための、リソースやガイダンスが無い人もいるのでしょう。そこで、私自身の葛藤をポジティブに捉えて、コミュニティに関わる人々の助けとなるツールへとつなげる選択をしたのです。

デザインは一直線に進まない

新米のデザイナーに対しては、払拭しておきたい2つの通説があります。

1. なぜか「正しい」と言われるデザイン手法が存在する
2. 「正しい」手法を手にしたら、その「完璧な」デザインプロセスから絶対に外れてはいけない

この2つは、次のように言い換えられます。

1. それぞれの会社やチームは独自のデザイン手法を持っている
2. 最終的に、デザインとそれに関わる人々に役立つ結果へとつながるならば、従来のデザインプロセスから外れて良い

利用できる手法は数多く存在して、何をいつ使えばよいのか迷うこともあります。はじめに調査を行うべきか？少しスケッチをするべきなのか？まず、構築してみるべきか？自分がどこから着手したいのかを、積極的に探り当てることが必要です。

デザインプロセスは、「おおまか」に次のように定義することができるでしょう。

• 目標を立てる
• 調査する
• 要件を定義する
• 大枠を決定する
• 詳細化する
• サポートする

(「おおまかに」という表現について、会社やチームはそれぞれに異なるものの、デザインについて語る場合、共通する一般的な流れがあることを示しています)

既に体制が整っているの環境においてはガイドラインは非常に有効です。今までに調査が十分に実施されており、問題解決の糸口となる体系的な知識が蓄積されている場合です。では、それが無い場合はどうすればよいでしょう？

本質的に、デザインは一直線に進みません。しばしばこれと反対のことを耳にしているかもしれません。しかし、デザインプロセスは、最良の結果を生み出すために乱雑になることがあり、必ずしも完璧に規則に従うものではありません。

デザイナーが利用できるすべてのツールを使用する必要はありません。プロジェクトに必要なものだけを使用すればよいのです。時には、さっと作り上げて公開し、それから情報を集めて変更を適用するべき場合もあるのです。

個人的な話: 私の友人であるキャット・スモールとジャッキー・アルシネと『Good for PoC』を共同制作したときは、ラフなデザインプロセスを選びました。まず、会社勤めの人たちについての情報と、彼らの職場でのポジティブな体験に関する情報を集めるアンケートを作成しました。始めるのに必要なだけ情報を集めたら、サイト構築に取り掛かりました。忠実度の高いデザインを手早く大まかに作り、構築して公開しました。まずは世に出すことを目指していました。ワイヤフレーム、ブランディングといったより詳細なプロセスの採用は、デザインの見直しに着手したときでした。私たちは、ツールに状況を合わせるのではなく、状況に合わせてツールを選択しました。

制作のプロセス

さて、アイデアが見つかり、準備作業を終えたら、待ちわびた時間、制作の始まりです。これから、私が『Guide to Allyship』プロジェクトのデザイン見直しの際に行ったプロセスを、順に説明することにします。

既存のプロジェクトの見直しでも、コミュニティプロジェクトに着手した当初の質問をもう一度確認するのは理に適っていますし、推奨されるべき行為です。以下は、この記事の冒頭で提示した質問に対して、私が回答した内容です。

• なぜそれをつくりたいのか?
  • 既存の『Guide to Allyship』に置き換わるツールとして作りたい。「協力者」という言葉は、実践的にではなく、理論的に誰かを支援したいと望む人を指して使われることが多いようだ。この言葉は曖昧さを持ち、責任が共有されていない面がある
• どのような影響を与えることを期待しているか?
  • 以下の単純な2つの行動に、人々に専念して欲しい
    • いまよりも善良であること
    • 教育や社会における積極的な協力者になること
• 対象にしているのは誰か?
  • 従来から置き去りにされてきたコミュニティに対して、より良い協力者になりたいと思っている人すべて
• いつ頃公開したいのか?
  • 2019年1月に公開したい
• どこで利用されるのか?
  • GitHubを利用しようと考えている
• それがどのようにコミュニティを改善するか?
  • 誰もが貢献できる自己啓発のためのリソースの管理場所を作成することで、コミュニティを改善する。交流の有無にかかわらず、誰もが自己改善を目的に働くことができる
• 情熱を抱いている対象か?（つまり、今後数年間にわたってプロジェクトやリソースを管理する強い意思があるか?)
  • もちろん。だが、1人ですべてを管理しなくてよいように、オープンソースに貢献できる人々を探すことになるだろう

これらの質問に答えたことで、どのようにデザインしていくか、明確な道のりが見えてきたように思います。ここからはAdobe XDに切り替えて、どのようにデザインしようと考えているのかお見せします。

ステップ1

私の場合は初めにスケッチを選択します。私にとって、作業を始めるにあたって一番作業しやすいからです。最初のステップは、自分に合った作業を選ぶとよいでしょう。ブラウザでコードを書けるタイプの人や、使い慣れたデザインツールを使うのが一番と感じる方もいるでしょう。とにかく一番良いと感じられる方法を選びましょう！

ステップ2

このプロジェクトでは、Adobe XDを使用することにしました。紙面に作成したすべてのスケッチを、忠実度を高めてAdobe XDに再現します。

すべてのスケッチを移すことを選んだのは、なにか「完璧な」デザインを見つけたと思い込みたくないからです。すべてのスケッチを比較して、目標にどのように役立つのかを確認したいと思います。

ステップ3

デザインの詳細に着手します。人によって、楽しかったり面倒だったりする作業です。

ステップ4

この時点からは、求めている結果に近づけられるよう、調整を始められます。デザインを1つ選択したのですが、サイトがどのように見えるかよりよく理解するには、いくつかページを追加する必要があることに気づきました。

また、簡単なテキストを書き入れて、このサイトがどのように機能するのかを知る必要があることにも気づきました。私はこのサイトを、各セクションに人々が記事やアドバイスを提供できる、オープンソースのリソースにしたいと考えています。それがどのように見えるかを確認するため、追加するページをスケッチしてから、XDで再現して調整しました。

スケッチ作業に戻ったわけですが、XDを使い始める前に、他のページを作りたい気持ちがあったことには気づくべきだったでしょう。ですが、最初に述べたように、デザインプロセスは一直線上にはありません。私は「間違え」てはいないのです。これはプロセスのひとつであり、個人的なプロジェクトです。私はもちろん、誰もが、このプロジェクトに命を吹き込む最善の方法を探り出していいのです。

ステップ5

複数の機能やページから構成されるアプリやWebサイトを制作する場合、それぞれの機能とページの目的を定義することが重要です。

このプロジェクトのこの時点では、「サイトについて」、「お問い合わせ」、「貢献」の3つのページを追加します。また、ある種の抑圧について語るページのひとつをデザインすることも考えています。

ここですぐに思いつく疑問は次のようなものです。

• これらはすべて別のページである必要があるのか？もしそうなら、その理由は？もしそうでないなら、その理由は？
• これらのページの目的は何か？ユーザーにどのように役立つのか？
• ページはサイトの効果を増すのか、それとも邪魔になるか

すべての疑問を書き出したリストではありませんが、これらは考えておくべき事柄です。私がデザインするページについて、上の質問に答えてみることにします。

ステップ6

実践可能なフィードバック大きな違いを生み出します。デザインに行き詰まったときは、目の前の木々から森全体を把握することができていません。私は、こういった状況になった場合、信頼できる友人にスクリーンショットを見せて、実用的なフィードバックを得るようにしています。下の図はそうしたやり取りの一部です。

ステップ7

最終的な結果に満足できたのであれば、素晴らしいことです！ここまでよく頑張りました！（まだ、コピーを見直す必要がありますが、このチュートリアルの目的からは、私が制作したもののポイントを把握できたと思います）

この後は、私自身がこれをコーディングすることになるのですが、このステップは必須ではありません。スキルの有無や業界のドグマ (すべてのデザイナーはコーディングすべき) に、決して社会奉仕の邪魔をさせないようにしましょう。デザイナーは人に分け与えるための特別なものを備えています。それが、どんなプロセスを辿ることになるものであれ、どうぞ進めてください。

公開したら、その後は？

プロジェクトが公開されたら、次は何をすればよいのでしょうか？それはプロジェクト次第です。メンテナンスが必要なプロジェクトであれば、管理を続けるための手順を、時間の確保も含めて考える必要があります。自立できるプロジェクトであれば、特にすることは残っていないことでしょう。

一番重要なのは、コミュニティに与えるプロジェクトの影響を確認することです。結局のところ、これはコミュニティのためのプロジェクトです。フィードバックに耳を傾け、調整を図り、プロジェクトがコミュニティの役に立って意図したとおりの価値を確実に提供するよう努力を継続しましょう。

この記事はHow to Design for Your Community（著者:Amélie Lamont）の抄訳です