こんにちは、株式会社Pentagon CDO/Designerの水谷です。
これまでUI/UXデザイナーとして、システム開発会社で1年半、Pentagonで4年ほど経験してきました。
これまでのデザイン業務を振り返って、「もっとこうすればよかった」と後悔したポイントが多々あります。今回は、デザイン業務の中で後悔した事例をもとに「今だったらこうする」という改善策をご紹介します。デザイン初学者もベテランデザイナーさんにとっても参考になれば幸いです。
【こんな人に読んで欲しい】
これからデザイナーを目指す方
デザイン業務で後悔したことがある方
【この記事を読むメリット】
後悔しないためのデザインを実践できる
【結論】
デザインに「正解」も「不正解」もありません。
・いつ
・どこで
・だれが、だれに
・なにを
・なんのために
・どのようにして
上記のような5W1Hをもとに最適解なデザインを行っても、時代・文化・用途などの変化によって5W1Hの中身が変われば「解」も変化します。
定期的に過去のデザインを振り返り、デザインへの今後の取り組み方を柔軟に変化させていくことが大切だと考えています。
【後悔：その1】デザインする前にもっとやるべきことがあった
Pentagonでは、デザイナーがプロジェクトの上流工程に入り、お客様とコミュニケーションをとりながら、サービス・プロダクトの骨格となる仕様決め等を行っていきます。
あらかじめ相談があった時点でお客様が考えた企画・仕様などがあるわけですが、
その精度はまちまちです。
後悔した例
デザインに着手する前から、お客様の中でしっかりとしたプロダクトのイメージがあり、練り込まれた資料も作成されていました。
お客様側で用意した仕様をもとにデザインを進めましたが、出来上がったのは機能が詰め込まれただけの目的のわからないデザイン。
結果、開発コストや工数も増え、ユーザーに刺さるかどうかわからないプロダクトになってしまいました。
解決策
お客様が考えた企画・仕様をただ愚直に再現すれば良いプロダクトができるとは限りません。どれだけよく出来た企画・仕様書であっても、それらを一度デザイナー側で再検討し、積極的に提案をしながらデザインの解像度をあげていくべきです。（デザイナーは提案していく姿勢がめちゃくちゃ大切です。）
そのための施策として、デザインする前に以下の作業を行うべきであったと考えております。
・お客様に対し丁寧にヒアリングをする（特に「WHY」「HOW」「WHAT」を明確にすること）
・プロダクト内で想定するステークホルダーに対しても可能であればヒアリングをする
・ヒアリングをもとにステークホルダーの相関図を作成する（どういった登場人物がいて、どういった行動をし、どのような課題をそれぞれもっているのか。そのうえで、このプロダクトはどういう課題解決を担うのか、図式化する）
・上記3つを行った上で、お客様に企画や仕様に関して提案をする
【後悔：その2】画面設計とデザインのフェーズは明確に分けるべきだった
画面設計では、仕様を決めながらワイヤーフレームと呼ばれるデザインの下書きのようなものを作成していきます。
画面設計をする時とデザインをする時の目的はそれぞれ異なるので注意が必要です。
後悔した例
スマホアプリのデザイン依頼を受けた際、画面設計を行わず、いきなりデザインから着手しました。(ここでいうデザインは、全体の画面遷移、トンマナやグラフィック等の見た目、あらゆる状態のデザインなど、最終的な成果物を指します)
ひとつひとつの画面を丁寧にデザインを進めていましたが、いざ全体像が見えてくると、「この仕様が整合性つかない」と後から気付くことが多々ありました。
結果的に出戻りが多く、工数のかかる工程に。
解決策
画面設計とデザインは取り組む際の目的をわけましょう。
画面設計フェーズでは情報設計をメインに作業して、デザインフェーズではビジュアル設計をメインに作業を行います。
これらを別々のフェーズで行うことで、デザインの出戻りやお客様との認識違いなどが少なくなります。
画面設計フェーズとは
画面設計の目的は、見た目をデザインすることではありません。下記の項目を、念頭に置きながら画面設計を行うことが目的になります。
・目的を達成するためにはどのような画面が必要なのか
・ユーザーが目的とする画面に、スムーズに辿り着けるか
・迷うことなくアクションを行える画面レイアウトになっているか
この作業では、細かいディテールは気にせず、色もモノクロのみで制作し、情報設計だけに集中して行いましょう。
デザインフェーズとは
デザインをする目的は、画面設計をもとにビジュアルの設計をしていくことです。
下記の項目を念頭に置きながら、デザインを行うことが目的になります。
・どのようなカラーやトーンでデザインするか（トンマナの設計）
・アイコンやグラフィックなど、直感的にユーザーに伝えられるか（グラフィック制作）
・あらゆる状態のデザインができているか（フォームを押したときにどんな挙動になるのか等）
この作業では、使いやすさや見やすさを向上したり、プロダクトの世界観を伝えたり、ビジュアルでコミュニケーションするということを意識して取り組みましょう。
【後悔：その3】不確定要素を早めに洗い出せばよかった
デザイン作業を進めてみないと、不確定要素が何なのかわからないことも多々あります。ただ、不確定要素を早めに洗い出すことができれば、それだけ対応策をたくさん考えることができ、早めに対処ができます。
後悔した例
プロジェクトスタート時から、スマホアプリに支払い機能をつけることは決まっていましたが、その機能の仕様は詰めないまま、他の機能のデザインを進めていました。デザインも終盤に差し掛かったタイミングで、支払い機能のデザイン着手。
しかし、支払い機能のデザインを詰めていくなかで、他の機能のデザインにも変更が必要な場面が発生。終盤に差し掛かったタイミングでのデザイン変更に、たくさんの人に迷惑をかける結果に。
解決策
画面設計をする前に、まずは仕様が詰められていない箇所（不確定要素）をリストアップしていきます。そして、他の機能にも影響が出そうな箇所から順に仕様を詰めていく、或いは議論をしていくことをオススメします。
【後悔：その4】定期的にお客様と打ち合わせするべきだった
現在、Pentagonでは基本的に週に1度、お客様との打ち合わせを設定しています。
後悔した例
お客様側が忙しく、打ち合わせを不定期で行っていた。
やりとりは基本的にSlack等で行っていたが、デザインの進捗報告やお客様側からのデザインレビューなどの遅延が発生し、プロジェクトがズルズルと伸びてしまった。
解決策
Slackだけのやりとりでは中々伝わらないことが多いので、定期的に打ち合わせを行うことが大切だと考えています。
打ち合わせの際に気をつけていることは以下になります。
・進捗報告をしっかり行う
・Fimgaを画面共有しながらお客様と一緒にデザインを確認する
・デザインの意図をしっかり説明する
・お客様との認識の違いが生まれないようにする
・お互いのタスクを確認する
・スケジュール（進み具合）を確認する
【後悔：その5】様々な人からデザインレビューをしてもらうべきだった
プロダクトをローンチするまでは、限られた人しか制作途中のデザインを見ることができません。小規模のプロジェクトの場合、デザイナー・PM・エンジニア・お客様、合わせて5名程度しかデザインを見ていないことが大半です。
デザインは多角的な視点で捉えることで、改善点が見えてくることが多いです。ローンチする前になるべく多くの人から意見をもらうことで、デザインをブラッシュアップすることができるかもしれません。
後悔した例
プロジェクトを進めていく中で、デザインに対して客観的な視点を失っていきやすくなります。この機能はこういう風に使ってもらえるだろうと思い込んでしまったり、自分がわかるんだからユーザーもわかるだろうと思ってデザインをしている所がありました。
実際にユーザーに使ってもらうと、どこを押していいかわからないなど、ユーザーを迷わせてしまうデザインになってしまいました。
解決策
秘密保持の関係で、ローンチ前のデザインを誰でも見せてよいという訳ではありません。
しかし、例えば同じプロジェクトには関わっていない社内メンバーから意見をもらうなど、ユーザー視点でデザインをレビューしてもらう機会を設けることはできるはずです。
あるいは、お客様側に了承を得てユーザーテストを実施するなど、ローンチ前にもそういう機会を積極的に設けるようにしましょう。
【後悔：その6】独自性のあるデザインに固執してしまった
Pentagonでは、ありがたいことにお客様やユーザーからデザインに対してお褒めの言葉をいただく機会が多いです。特に「世界観をつくるデザイン」を得意としていることから、世の中にとって独自性のあるものを目指してデザインすることが多いです。
後悔した例
スケジュールがタイトなプロジェクトの場合、コストやリソースの関係で、スピード重視でデザインを行わなければならない場面があります。
ただ、独自性を求めてデザインを行うと、どうしても時間がかかってしまうことが多いです。お客様の求める「スピード重視で、とりあえずデザインされてればよい」とPentagonで目指す「世界観をつくるデザインでありたい」の折り合いがつかない場面が多々ありました。
解決策
「世界観をつくるデザインでありたい」というのは、Pentagonのデザイン理念であり、どのプロジェクトにも当てはまるものではないのかもしれません。
・短期的に目的を達成するためのデザイン
・長く使ってもらうためのデザイン
「世界観をつくるデザインでありたい」というのは、言い換えると「長く使ってもらうためのデザイン」を目指しているところがあります。
IT業界は、時代の流れが早いので、スピードを重視していくこともとても大切です。
独自性のあるデザインに固執せず、ケースバイケースでプロジェクトごとに、デザインに対しての取り組み方を柔軟にしていきましょう。
【後悔：その7】Figmaの運用ルールをしっかり決めるべきだった
PentagonではFigmaというデザインツールを使用しています。
Figmaは大変便利なデザインツールですが、自由度が高いため、チームで一緒に作業を行う際に認識の違いが生まれやすいです。
後悔した例
Figmaをチームで使っている際、特に運用ルールをつくらず作業を行っていました。
完成したデザインを開発チームに共有し、実装をしていただいてました。
ただ途中でデザインが変更になることはよくあります。都度、デザインを更新して開発チームに依頼していましたが、開発チームからどのデザインが最新なのか、どの画面をみればいいかわからないなど、混乱を招いてしまいました。
解決策
Figmaをチームで使う際は、運用ルールをしっかりと決めるべきです。
Figmaは、ひとつのデザインファイルの中に複数のページを作成することができます。
Pentagonでは、現在Githubのようなデータの管理方法を採用しています。
・「Master」というページを1つ作成し、そのMasterページは最新のデザインのみ置く
・開発チームは「Master」にあるデザインをみて実装する
・完成していないデザインや、作業途中のデザインが「Branch/〇〇」というページを作成し作業を行う（例：Branch / 検索機能）
・完成したデザインは、「Master」ページにマージ（結合）する
・変更があったデザインには、日付付きのコメントをいれて、変更箇所を記載する
まとめ
デザインはあくまで手段
デザインを行う中で、課題に対してのアプローチは多種多様ですし、デザイナーによってそれぞれアプローチの方法論をもっているかと思います。
ただ、デザインするということはあくまで目的を達成するための手段にすぎません。
「デザインは課題解決」という言葉がよく聞かれますが、注意しなけらばならないのは、その「課題」は変化していくということです。手段を目的にしてしまって自分なりのデザインアプローチに固執してしまうと、その課題の変化に対応できなくなってしまいます。
今回ご紹介した7個の「後悔」に対しての「解決策」も、来年には変わっているかもしれません。
定期的に過去のデザイン・やり方を見返しながら、「次はこうしてみよう」とより良いデザインを目指していきましょう。
