プロセス

A collection of 63 posts

プロセス

Q&A 成果物に合わせた説明の仕方が知りたい

インハウスで3人ほどの少人数のデザイン部門にいますが、周りの知識レベルがバラバラで、デザイン批評をするのが難しいです。 また、途中成果物(ワイヤーフレーム、デザインカンプなど)がそもそもどういう目的で作られるものかも理解されていない状態です。 伝えやすくするためのコツや手段があれば知りたいです。 匿名 プロセスを進めるために手段がある 「デザインカンプを作らないと分かってもらえない」というのは昔からある制作者の悩み。デザインカンプは漠然としたビジュアルの印象を共有するためであれば良い途中成果物ですが、コンテンツの検討やインタラクションなど不得意分野もあります。 デザインカンプを作ったデザイナーは、それを通して何を共有して決めたいか頭の中でイメージしていますが、見ている側は下図のような様々な課題を一気に見せられているようなものです。 デザインといっても解決している課題は様々です。 いきなりデザインカンプを作ることの危険性は単に制作コストがかかるだけはありません。高いファシリーテション能力がないと、話が様々な方向へ広がってしまいます。ビジュアルの刺激が強いことから、本当は実装コストについて議論すべきなのにロゴの大きさに話題が集中する … ということもあり得ます。 ワイヤーフレームなどの途中成果物は、完成に近づいたタイミングで大きな方向転換することを極力防ぐために作られます。本来、目的を達成するための手段ですが、プロセスの中に組み込まれているからやる、といった手段が目的化している場合があります。先へ進めるために同意をとらなければならないことがある。そのそのために最も効果的な手段は何かを考えなければいけません。 デザインカンプ以外の成果物への理解が難しい理由は何のために作られ、これによってどう進展するのかというプロセスと成果物の関係性が見えにくいところだと思います。デザインカンプは見た目の刺激が強いことから分かった気にさせているだけで、その成果物ですら途中段階であることは理解していない可能性もあります。 個人的に、どのプロジェクトでも必ず作らなければならないデザイン成果物は存在しないと思っています。ただ、ステークホルダーに同意を取らなければならないことは多々あるので、共有・同意するために必要な成果物は何か考えるようにしています。例えば以下のように成果物と目的を表にしてプロットしてみるのも良いでしょう。

デザインシステム

デザインシステムに関わるいろいろなプロセスを図にしてみた

今までも何度か デザインシステム に関する記事を書いてきましたが、手段や考え方が中心でした。今回はプロセスに注目して、代表的な課題を図にしてみました。すべてのケースに当てはまるわけではないですが、参考にしてください。 大まかな進め方 「デザインシステムを作りました!」とドカンと発表したほうがインパクトがあるように見えますが、苦労したわりには誰も使わないものになる可能性が高いです。実際はデザインシステムの中にあるものを小さく切り出して少しずつ変えていくことになります。 正攻法であればデザイン原則から始めたほうが良いと思っていますが、組織としてどうあるべきかといった根本的なところが明文化されていないのであれば、そこからスタートしたほうが良いでしょう。デザイン原則があったほうがデザインの議論がしやすくなるので早期にもっておきたいですが、1 日でも早く成果を出したいのであれば、まず色からはじめてみるのも手段です。順番が重要ではなく、どういうステップを踏んで進むのが組織にとってベストなのかをロードマップを作って考えてみてはいかがでしょうか。 運用・開発に関わる課題 デザインシステムの設計と構築で大きな壁になるのがデザインシステムそのものの運用です。以下のような課題は、新しいプロダクトを作ることとほとんど変わらないことが分かります。言い換えるとデザインシステムにあるヒトの課題をどう解決するかに結びつきます。 ドキュメンテーションの執筆 レビュープロセス リリースタイミング Issue(課題)の整理と処理 デザインシステムのバージョン管理 実装ツールの開発 デザインシステムのサポート 今できることの決め方 デザインシステム本が出るなど、日本でもようやくデザインシステムが認知され始めました。やってみようと思って参考にできるものを探しても Lightning Design System

コンテンツ

ラベルデザインから読み解くコンテンツ設計の課題

色やタイポグラフィだけでなく、言葉でプロダクトの雰囲気が決まることがあります。早期からダミー文字を避けてコンテンツをデザインするべきですが、簡単に作れるものではありません。 良い事例を探そうとすると必ず辿り着くのが Mailchimp の Voice and Tone 。「Mailchimp らしさ」が明文化されているだけでなく、ライティングの基礎も書かれている優良コンテンツです。しかし、英語の壁がありますし、文化の違いもあるのでそのまま真似するのは困難です。 そこで今回はラベルのライティングというミクロの視点と、出来上がるまでのプロセスを把握するマクロの視点からコンテンツの課題と対策を紹介します。 ラベルデザインにある3つの特徴 UI のラベルをどのようにデザインすれば良いのかを考える上で、 Airbnb アプリは好例です。ローカライズの視点も加えるとさらに面白いので今回は日本語のインターフェイスで紹介します(デザインの良し悪しや使い勝手ではなく、コンテンツのみ注目しました)。 シンプルな UI の所々に『Airbnb 色』を伺うことができます。ブランドで使われている言葉を大事にしつつ、アプリの使い勝手を失わないためのバランスが考慮されています。デジタルで紙媒体の装いがないにも関わらずあえて「ガイドブック」と呼んでいますが、旅を体験するための情報が手に入るかもしれないというユーザーの想像を駆り立てるラベルです。 UI デザインを増幅させるラベルは大きく分けて 3 つあります。 ビジネスに直結する表記

ビジネス

ビジネスを考慮したデザイン提案をする前に決めておきたいこと

改善の意味を合わせる Web サイトやアプリの運用・改善は欠かすことができないプロセス。一発で正解を出すのが難しいのはもちろん、市場やユーザーの動きも常に変わるので、それに合わせた対応が必要になります。改善をすることに異論を唱える人はいないと思いますが、何に対して改善したいと言っているのか異なる場合があります。 例えば web サイトやアプリの制作者(デザイナーや開発者)であれば、UI や使い勝手を改善したいと考えるはずです。しかしマーケターであれば流入チャンネルを改善したいと考えるかもしれないですし、経営幹部であれば収益を上げるための施策を改善と呼ぶかもしれません。 それぞれが考える改善をしていても最大の効果は得られませんし、ひとつに集中しなければ効果が見えてこない場合があります。 また、ビジネスインパクト(利益になるかどうか)を考えたとき、私たちがやりたい UI 改善による効果が極めて小さい場合があります。押しやすいボタンにデザインを変えたとしても、ユーザー数が少ない中では望める効果を得るのは難しいです。それより、ユーザー数を増やすための施策にデザイナーが参加するほうがビジネスへ貢献できるかもしれません。 役職や背景によって「改善したい」と思うところが異なります。そこでチームで改善するフォーカスを決めることが重要になります。Web サイトやアプリにおける改善は以下の 6 つに分類することができます。 ※ カタカナ用語で分かりにくいかもしれませんが、ビジネスサイドで使われている言葉なのであえて使っています。 アウェアネス 気付き・認知:

プロセス

デザインをスケールさせるためのツール選び

なぜスケールすべきなのか よく多くの改善、より早い提案・対応が求められている今日。エンジニアは昔から大規模化して動くための施策と実践を続けていますが、デザイナーは大規模化の歴史がないといっても過言ではありません。エンジニアのように確固したワークフローの構築が難しいというのもありますが、デザインは『個人プレー』で作るものというニュアンスが強かったという背景もあると思います。 しかし、いつまでも個人に依存したデザインをしていると、新しい施策や改善がひとりのデザイナーの動き次第になります。もちろん、それでも運用可能な環境はありますが、増え続けるビジネスサイドの要望に対応するために、ひとりでデザインを続けるのは困難です。ひとつひとつ対応してるときは、「分かりやすい一貫性のあるデザインを作ろう」と思って取り組んでいたとしても、全体を振り返ると実はそうではないということはあります。 ではどうやってデザインをスケールさせていくのかというと、国内外問わず手探りの状態です。人事からマネージメントまで様々な課題がありますし、最適なチーム構成も組織によって異なります。Spotify は Squad Framework(スクワッドフレームワーク) という独自の構成と言葉を用いてチームを動かしています。プロダクトや特定の機能でチームを分けるというやり方がある一方、Shopify のようにUXデザインに特化したチームを作る組織もあります。 事業会社にある代表的な体制図。いずれもメリット・デメリットがあります。 デザインのスケールとデザインシステムは同じ課題に取り組んでいると捉えることができます。デザインをスケールさせるにはデザインシステムのような手段は欠かせないですし、デザインシステムを作るのであればデザインのスケールという目標が達成できなければ大きな荷物を抱えるだけになります。少人数で頑張るという状況から抜け出すためにも「大きくしていく、スケールさせていく」という目標を掲げた上でプランを練ったほうが良いでしょう。

デザイン

デザインプロセスにあるイケア効果

イケア効果という認知バイアス 自分で作ったものだからこそ、特別な感情を抱いてしまいます。だからこそ成果物が否定されると、自分自身が否定されたかのように聞こえてしまうことがあります。自分は自分。成果物は成果物と切り分けて聞き入れるべきですし、話し手も成果物の課題に対してきちんとフィードバックをしたほうが良いでしょう。しかし、実際はそう簡単にはいきませんし、たとえ話し手が上手なフィードバックをしていたとしても、上手に受け入れられない場合があります。 人は自分で作ったものに対して特別は感情を抱いてしまうのは、デザイナーだけではありません。自分で作ったものに本来以上の価値を与えてしまう認知バイアスで、誰でも持っているものです。こうした状態を「IKEA effect(イケア効果)」と呼ぶことがあります。 IKEA の家具は組み立て前の状態で販売されており、組み立てるのは購入者です。コスト削減のための施策ですが、購入者が自分の家具を自分で組み立てるという工程があることで、特別な感情を抱くことがあるそうです。The IKEA Effect: When Labor Leads to Love で紹介されている調査によると、プロによって組み立てられた家具より、自分で作った家具に高い価値を置く傾向があるそうです。家具そのもののが評価の対象ではなく、それがどのような工程で作られたのか身をもって体験したことが評価に繋がることがあるわけです。 一緒に作っている感を演出 以前からデザインのブラックボックス化は避けるべきと話していますが、単なる直感や好みで作られているわけではないことを周りに知ってもらう行為だと思っています。しかし、

プロセス

デザインの過程を見せるのはスキルアップの近道になる理由

結果だけでなく過程も 途中経過を見せることはデザインへの誤解が生じると考える人はいるかもしれません。また、途中経過は『企業秘密』だから見せるべきではないと考える人もいるでしょう。そもそも恥ずかしいから見せたくない人も少なくありません。自分も最初は恥ずかしかったですし、そもそも途中経過は見せる必要ないと思っていたほうでした。 しかし、今は途中経過を見せなければ良いデザインが生まれないと考えるようになりました。手描きのものから、インタラクションがあるものまで様々な形状を作っては見せています。仕事現場だけでなく、Twitter や Instagram のような場でも見せることもありますし、このブログにしてもデザインにおける途中経過を文章として表していることが多いです。 完成されたモノをどう作るかというノウハウも重要ですが、デザインという『よく分からないもの』が生まれるまでのプロセスを見せるほうに興味があります。 Anyone who influences what the design becomes is the designer. This includes developers, PMs, even corporate legal. All are the designers.

デザインシステム

デザインシステムが作り出す明文化への道

明文化をテーマにしていた2016年 今年の初めデザイン SDK のようなものが欲しいという記事を書きました。開発者から提案されているフロントエンド寄りのスタイルガイドはコードの品質管理と、見た目の再現性を高める上で有効な手段です。しかし、これだとコードを理解していることがスタイルガイドの利用・関与の大前提になります。すべてのデザインがコードから始まるとは限らないですし、デザイナーであれば Sketch や Photoshop といった日々使うツールを活用して最低限の品質を保つ手段が必要になります。 共通言語を作っていく。 これは文字通り言葉だけでなく、UI を始めた視覚的な部分など、今まで好みや感覚で済ませていたこともきちんと言葉にすることも指しています。デザイン批評も共通言語を作り上げるために必要なプロセスです。 建築家クリストファー・アレグザンダーの著書「Pattern Language」で、単語が集まって文章ができるように、様々なパターンを自由に組み合わせることで大きなものが生まれることを学びました。つまり、パズルのピースのような硬いものを作るというより、柔軟性のある言葉を揃えていくことを意味しています。数十年前からある考え方ですが、成長・運用が必要な今のデザインにおいて参考になります(IA に興味があれば、チェックしておきたい書籍です)。 仕事現場で模索しながら、得た知見を活用してセミナーやワークショップを続けていましたが、最近は Salesforce の Lightning Design

プロセス

プロセスなんて下手でも我流でも気にしない

デザインプロセスの儀式化 随分昔の話になりますが、茶道(表千家)をしばらく学んでいた頃があります。日本伝統をひとつでも知っておきたかったというのもありますし、茶道にある特有の礼儀に興味があったのが理由です。茶道は、使う道具はもちろん、たてかた、飲み方にも決まったルール・プロセスがあります。できあがった茶の味だけでなく、茶がたてられる過程も楽しむのが茶道の魅力であり奥深さです。 完成品だけでなく、過程を重んじるのは茶道だけの話ではありません。日本に昔からある芸道だけでなく、「寿司を食べる」といった食の世界にもあります。美味しく寿司をいただくには、決まった順序がありますし、正しいとされる礼儀もあります。プロセスというより、一種の『儀式』と呼ぶことができるでしょう。 過程(プロセス)を重んじ、儀式のように進めるという行為は日本文化だけでなく、他国でもあります。プロセスには言葉として表現するのが難しい魅力があるものの、無心で信じるのは良くありません。今日のデザインにおいて、どの環境、どのプロジェクトでも適応できる完全無欠のプロセスは存在しません。しかし、それでも私たちは確実性や安心を求めて『正しいやり方』を探してしまいがちです。ただ、デザインプロセスそのものを過剰に意識することで、デザインが本来しなければならい役割が果たせなくなることがあります。 儀式化してしまっているデザインプロセスを例えてみると

デザイン

ありがちなプロトタイプ失敗パターン

次へ進むための『何か』 プロトタイプは今日の設計プロセスにおいて必須の役割を果たしている … といった論調を見かけることがあります。特にアプリの場合、Web サイト制作以上に開発者とデザイナーの密接なコミュニケーションが必要になるので、単なる静止画データの受け渡しでは不十分です。そこで「プロトタイプを作りましょう」となるわけですが、他のツールと同様、手法を取り入れただけで制作における課題が解決されることはごくまれです。 プロトタイプは、紙で作るものから、Principle のようなアプリケーションを使ってインタラクションを加えるものまであります。プロトタイプの完成度も制作スピードもツールによってまちまちなので、どのように扱えば良いのか迷う方も少なくありません。また、新しいツールを採用してプロトタイプ(のようなもの)を作ってみたけど、以前と状況が変わらないどころか、大変になってしまうこともあります。 私の中でプロトタイプは、工程を進めるために必要十分な『何か』と定義しています。この定義だと、従来からあるワイヤーフレームもプロトタイプの一種として含めることができます。何か新しいツールを使っていなければならない。画面遷移をはじめとしたアニメーションが付いていなければいけないという先入観が付きまとうプロトタイプですが、そんなことはありません。むしろ、その先入観で作られたプロトタイプが、プロセスの失敗を導く場合があります。 プロトタイプにある落とし穴 様々な完成度のプロトタイプを今も作り続けていますが、完成度が高いのに効果がないものを作ってしまったり、余計な時間を費やしてしまったこともあります。プロトタイプの利用に失敗するパターンは 5

デザイン

デザインドキュメンテーションにある制作と共有の課題

ドキュメンテーションのための3つの課題 Web サイトデザインはもちろん、アプリデザインでも画面ではなく部品から始めるほうが有効です。画面ごとで制作していくと、いつの間にか一貫性を失うことがありますし、様々なスクリーンサイズに対応するためのルールを後付けにすると、結局またやり直しになってしまうこともあります。 では、インターフェイスを一度見直してスタイルガイド(パターンライブラリ)を作り始めれば良いのかというと、それほど単純は話ではありません。私の中で以下の 3 つの課題があると考えています。 人とコトの課題 – これはワークショップを通して指摘しましたが、ステークホルダーによって優先順位が違えば、指している要素の呼び名が違うことがあります。制作側視点だけで作ると思わぬ誤解が発生する可能性があります。 共有の課題 – 様々な企業が自社フレームワークを Web で公開しているのを見ても分かる通り、最近は多くの人が見れる場に公開する傾向にあります。GitHub などのサービスを介して公開するのも手段ですが、運用しやすく、参加者が最新情報へアクセスできるようになっているかが選定の基準になります。 デザインとコードの課題 – 特に Web サイトデザインに言えることですが、スタイルガイドと言うとフロントエンド寄りのソリューションになりがちです。見た目とコードに一貫性を持たせるという意味では必須ですが、ビジュアルデザイナーもスタイルガイド制作に参加しやすい仕組みも必要です。 一長一短なアプローチの数々 案件によって関わり方やアウトプットの要件が異なることから、上記の課題をそれぞれ模索しながら進めている状態ですが、

プロセス

なぜ自信をもってデザインを説明するべきなのか

コラボレーションは難しい コラボレーションは今日のデザインプロセスにおいて必須です。様々な分野の専門家たちが集まるからこそ、より良い製品へと進化していきます。専門家だからこそ出せるインプットによって、最適な解決策が見つかる … はずなのですが、実際そうはいかないことがあります。立場が違えば、物事の捉え方も違います。それぞれが置かれている状況によって、意見が分かれることがあります。意見が一致すればコラボレーションとしての相乗効果が生まれますが、そうでないときは、不平や妥協する人が出てくるでしょうし、最悪の場合は製品の利用体験を損なうものを実装してしまうこともあります。 コラボレーションは響きの良い言葉ですが、一筋縄にはいきません。意見が合わないとき、私たちはよく自己防衛の姿勢になりがちです。「これは違う」と言われると、反射的に「そんなことはない」と言うことがありますが、こうしたやりとりがコラボレーションの歯車を狂わしていきます。自分を守ること、相手の意見を変えることが先決になり、肝心の課題解決の話し合いではなくなっていきます。こうなると以下の 3 パターンで話に決着が付いていきます。 多数決 – 皆が欲しいものを平等に受け入れたり、投票をした結果で進めてしまう場合。らくだをデザインしていることがあるかもしれません。 声が大きい人 – 「これはどうしても必要だ!」と声を大にしている人が押し通してしまう場合。 上司の言葉 –

プロセス

デザイン調査にあるバイアスとの向き合い方

シミュレーションとリアリティ デザイン調査は利用者の理解、そしてプロジェクトの方向性を共有するために欠かすことができません。調査がないデザインプロセスは UX デザインとは呼べないといっても過言ではないほど重要ですが、調査だけで利用者の『現実』を捉えるのは難しい場合があります。 ユーザーインタビューを通して様々な意見を聞き出すことができますし、その場で使い方を見せてもらうこともできるでしょう。しかし多くの場合、利用者の声と意図にはギャップがありますし、会議室という日常とは異なる場で、現場で起こっていることを再現するのは難しいです。ユーザーインタビューだけでなく、ユーザビリティテスト、カードソーティングなど様々な手法はありますが、調査する側によってつくられた状況の中(シミュレーション)で行われることが多いです。調査の多くはシミュレーションであり、現実(リアリティ)とは異なることを理解していないと、調査の仕方や集めるデータにバイアスがかかることがあります。 バイアスと向き合った調査 バイアス(偏り)はデザイン調査をする際、課題として挙がるトピックのひとつです。デザイン調査において、以下のバイアスが多大な影響を及ぼします。 確証バイアス 自分が立てた仮説を過信するあまり、それを立証するためのデータばかり集め、反証するデータを無視してしまう傾向。 アンカリング 最初に引き出したデータなど、ひとつの情報に引きずられてしまう状態。重要視したデータに合わせるように調整してしまうことも。  自信過剰バイアス 自分が正しいと思い込んでしまって、それが判断に大きな影響を及ぼす状態。

UI

プロトタイプに発生する溝と対処法

完成品になれない溝をどう埋める あたかも完成品に見えてしまうデザインカンプには、様々な暗黙の了解が存在します。グラフィックツールで Web ブラウザ上での見た目を再現しようとしても、実際 HTML / CSS で組まれたデザインの見た目と同じになることはありません。どこまで静止画を作り込んでも、実際の完成品には成り得ない大きな溝が存在します。この溝が大きな誤解に繋がることがあります。 例えばレスポンシブ Web デザインの場合、幾つかの大きさで静止画のデザインを用意したとしても、その間(可変状態)でどうなるか想像するのが難しい場合があります。また、レスポンシブ Web サイトにおける表現は多彩になってきています。要素の順番を Flexbox で変えることもできますし、画像の配置の仕方もより柔軟で表現豊かになってきています。知識や経験がある方であれば静止画では表現されていない「実はこうなる」という部分を踏まえてデザインを見ることができますが、誰でもできることではありません。 見た目は完成品のように見えるデザインカンプも、実は完成品から離れた存在であることは少なくありません。完成品に見えてしまうことによる誤解やリスクのほうが高まる場合があります。 これは Web サイトだけでなくアプリデザインにも同様のことがいえます。スクリーンに直接触れて操作することから、静止画で判断がつかないところがたくさんあります。スマートデバイスの関わり方はパソコン時代に比べて多種多様なので、誰でも分かる操作方法は多くありません。そこで、静止画ではなく操作ができるプロトタイプを作ることが必須になってきたわけですが、

プロセス

評価と効果で見えなくなりがちなデザインの価値

先週末、大人向けワークショップ deCAFE に参加してきました。昨年にも一度参加したことがあって、今回で 2 回目。今回はワークショップではなく過去を振り返りながらお喋りをする会でしたが、運営メンバーにイベントの意図や裏話を聞くことができて大変楽しかったです。 運営チームの方々は Web や IT 業界働くデザイナーがメインですが、ワークショップの内容はそこからかけ離れたテーマを扱っています。テーマの抽象度が高いことから、具体的に「◯◯を学んだ」とは言い表せないものの、他のイベントでは得ることができない何かを掴むことができます。 最近は数十分話すセミナーよりワークショップが多くなってきていますが、自分のワークショップにも何か取り入れるものがあるかもしれないという好奇心が参加のキッカケでした。前回と今回の参加を通して、漠然としていた deCAFE で得れた「何か」を鮮明にすることができました。それは、今 Web やアプリという枠組みで働くデザイナーに少なくなってきている要素ではないかと思いました。 評価がデザインを殺すとき 近年、クリエイティブと呼ばれる場でも「評価」「効果」という言葉がついてまわります。様々な制作物が売り上げ、滞在時間、コンバージョンなどといった数字によって評価されます。課題解決のためにデザインがあるのであれば、本当に効果があったのか測るべきでしょうし、

デザイン

コミュニケーションとしてのプロトタイプの真価

カンプ2.0になっていないか プロトタイプを作ることが今日のデザインプロセスにおいて、不可欠になりつつあります。3年前ではなかなか響かなかった話題でしたが、ますます複雑になるアプリ / Web サイトデザインにおいて、いきなり完成品に近いものを作り込むという手法が通用し難くなりつつあります。また、高機能ツールも手軽に使えるようになったことで、とりあえず作って見せるという行為がしやすくなりました。 実機で画面遷移を確認するだけでなく、アニメーションもコードの知識なしで作れるようになった現在。ツールはますますパワフルになっていきますが、プロトタイプツールの目的は実装のための青写真を作るためにあるわけではありません。 ビジュアルデザイン(インタラクションデザインも含)と実装には以前から大きな溝が存在します。デザインカンプと呼ばれる、あたかも完成図のように見える成果物をもとにコーディング(実装)した場合、そこで何かしらの問題が発生します。デザインの際に考慮されていなかったパターンや状態は、どんなに作り込まれていても見つかります。また、運用やパフォーマンスといった制作時には見え難いこともデザインに影響することがあります。 本当のデザインの仕事は実装フェイズで始まる。 — Yasuhisa Hasegawa (@yhassy) February 16, 2016 デザインの次に実装があると思われがちですが、実際のところ実装が始まったところで本格的なデザインの仕事が始まるといっても過言ではありません。グラフィックツールでデザインしているときに見えなかった課題をひとつひとつ解決していく必要があります。システムを導入したとき、又は実機で操作したときといった、完成に近い状態にならないと見えてこない課題が少なくないからです。 プロトタイプは、こうした実装とデザインをどのように実現していくかを考える際につかえる強力なツールです。

デザイン

ひとりから始めるデザイン批評

孤独だから見えにくい デザインは孤独な作業になりがちです。ひとりでデザインファイルと向き合う時間が長いので、自分がつくったものに対し感情的な繋がりができてしまうことがあります。また、プログラムのように、ひとつのファイルを何人かが触るということも少ないので、ある程度のステージに到達するまで誰もデザインを目にしないことがあります。つまり、『完成品』しか提示されないので、その間どのような試行錯誤がなされたのかも分からないわけです。 自分の視点だけに閉じこもることを避けるために、デザイン批評を通して、何が改善できるかをクライアントや同僚と話し合いをおこないます。批評を意識した会話は、ひとりのデザイナーとしての成長にも大きな影響を及ぼしますが、誰でも会話ができる環境にいるわけではありません。フリーランスはもちろん、まだデザインの会話を始めにくい環境で働いている方もいるでしょう。 デザイン批評は複数人で実践するのが理想的ですが、ひとりで自分のデザインを批評することもできます。 セルフチェックから始める 自分で自分のデザインを批評しても、客観的な意見にならないかもしれません。しかし、自身にどのような質問を投げかけるかで得られるものがありますし、自分の試行錯誤を繰り返したデザインプロセスの振り返りとしても役立ちます。自分ひとりでデザイン批評をするための方法が4つあります。 1. 反対のことを考える 最善を尽くしたデザインでも見方を変えると新たな発見があります。ミニマムな装飾でタイポグラフィを尊重したデザインに対して、あえて「これはミニマムではないかも」と問いかけてみるとどうでしょう。自分の意図とは反対の視点からデザインを見ることで、エッセンスをさらに磨くことができるようになります。 2. 使用デバイスから見てみる 同じデザインなのに、使用デバイスから見ると印象が大きく変わることがあります。たとえ静止画でも、

コンテンツ

コンテンツタイプの理解と分類のコツ

コンテツタイプの把握が不可欠な理由 コンテンツモデルの基礎と活用メリットで、コンテンツをひとくくりにまとめるコンテンツタイプを紹介しました。コンテンツタイプには、ニュースリリース、レビュー、レシピ、チュートリアルなど様々な種類があります。これらがどのような項目で構成するのか考える前に、そもそもどのようなタイプのコンテンツが制作・管理されているのかを知る必要があります。 様々なコンテンツタイプがあるにも関わらず、CMS では「本文」という大きな枠にまとめて入力することがあります。カスタムフィールドやプラグインで解決するといった方法もありますが、五月雨式に項目を増やすよりコンテンツタイプごとに設計できたほうが維持・管理がしやすくなります。 CMS の設計のためにコンテンツタイプを把握するのも目的のひとつですが、それだけではありません。様々なコンテンツタイプがひとまとめで管理されていることのデメリットをクライアントに理解してもらう必要があります。コンテンツタイプ幾つか用意することで、構造化されたコンテンツが作りやすくなるだけでなく、利用者に関わる以下の課題の解決に繋がります。 利用者の期待 情報をただ分類すれば良いというわけではないのがコンテンツタイプの難しいところ。コンテンツがきちんと分類されていたとしても、ニーズに応えていなければ機能しないことがあります。利用者やコミュニティがもつ独自のニーズに合わせたコンテンツタイプを特別に設ける場合があります。 例えば文房具を販売にしているサイトであれば、製品情報を細かく入力できることはもちろんですが、利用者が主に法人であれば、一般消費者向けの製品情報にはない独自の項目を追加するべきでしょう。 業界の文法とのギャップ 業界として決まった言い回しや分類の仕方があるとしても、それが利用者の捉え方と同じとは限りません。赤ん坊向けの玩具の販売をしている場合、「赤ん坊」だけではキーワードとして不十分です。「赤ちゃん」「ベビー」でも見つかるべきですし、