オウチーノ開発者ブログ

「株式会社オウチーノ」の社員によるブログです。

DTPデザイナーからwebデザイナーにジョブチェンジした話

オウチーノ デザインチームの奈良です。

私は現在webデザイナー・UI/UXデザイナーとしてオウチーノの不動産サービスに携わっているのですが、元々は弊社が発行する不動産フリーペーパーの制作を行うDTP(グラフィック・エディトリアル)デザイナーでした。

冊子型フリーペーパーの他にもペラのチラシやダイレクトメールに加え、不動産店舗のディスプレイ用ののぼりやステッカーなどもデザインしていました。

花火大会で無料配布するうちわ型広告なんてものもありましたね。

紙媒体を主戦場としていた私ですが、使い慣れたミリメートルの物差しをピクセル定規に持ち変えてwebデザイナーへジョブチェンジするには多くのハードルがありました。そんな悪戦苦闘の一部を綴りたいと思います。

DTPとの基本的な違い

f:id:kenichi_nara:20181227184332j:plain
投函ツールはポスト内で目立つかが重要。紙質とクリエイティブの相性も気にしていました。

さあwebデザインをするぞといってもできることは限られます。

幸いオウチーノには優秀なフロントエンドエンジニアがおり、デザイナーはディレクターの作成したワイヤーフレームにしたがってまずは見た目のデザインをすればよかったため、愚かな私は軽い気持ちで何の知識も入れずにDTPデザインのやり方で制作に取りかかりました。

DTPデザインで使用するアプリケーションといえばQuarkXPress(今や懐かしの)やIllustratorやPhotoshop、InDesignといったレイアウトソフトが有名どころかと思います。

私は普段Illustratorでレイアウト、Photoshopでフォトレタッチを行っていたため、迷いなくIllustratorでwebページのデザイン作業を進めました。作業が一通り完了しフロントエンドエンジニアへデザインデータをお渡しする段になったとき、事件は起きました。

フロントエンドエンジニア「これはコンテンツ幅は何ピクセルなんでしょう」

私「ん??」

フロントエンドエンジニア「え???」

ディスプレイで表現されることから考えれば当たり前にわかることなのですが、そもそもwebページの描画がピクセル単位でされていることを認識していませんでした。

そしてその当時Illustratorではピクセルへのスナップが不完全で、プロパティで数値を指定してもオブジェクトのエッジがわずかに滲んでしまう現象がまま見られるなど、web制作に適しているとはいえなかった(現在では機能向上に伴いIllustratorでwebデザインをされている方もそれほど珍しくないようです)のもよろしくありませんでした。

とはいえPhotoshopでのレイアウト経験もなく相当の時間を食ってしまうため、Illustratorでデザインしたものをpsdデータに変換してPhotoshopで整形する…というようなことを行いその場は凌ぎましたが、それ以外にもカラーモードや画像の解像度、画像とテキストの扱いの別など基本的な部分での勝手の違いに大きな戸惑いを感じ、そもそもDTPとは別モノであることを思い知らされたのでした。

webデザインの壁

f:id:kenichi_nara:20181226112640j:plain

苦い経験を胸に恐る恐るwebデザインの扉を開けてみると、そこには得体の知れない暗号の海が広がっていました。

html、css、JavaScriptです。

これがなんなのか、どんな役割を持ったものたちなのかを理解し、使いこなせなければ話になりません。

その辺のスキル習得の方法はいろいろあろうかと思いますが、私は何冊かの入門書を読んだくらいでほとんどOJTに近い方法で身につけていきました。 html・css・JavaScriptはDTPデザイナーからの転向の際にぶつかる大きな壁だと思うのですが、最近ではフロントエンドエンジニアと分業であることも珍しくないためゴリッゴリに極めなくともなんとかなったりします。

ちなみにオウチーノではエンジニアがコーディングを担当してくれるケースが多く、デザイナーはよりデザインに特化して動ける環境が整っています。 私の拙いコーディングスキルでどうにかなっているのは、まさしくこのチーム制作環境のおかげといえるでしょう。ありがたや。

そしてDTP歴が長ければ長いほど感じるのが、デザインそのものの壁です。

特にフォント・カーニング・トラッキングなどテキストまわりの不自由さは、DTPデザイナーからするとやりたい表現が実現できず不満が募ります。さらにhtml+cssでの表現の仕方やユーザーエージェントによる見え方の違いなどを考慮する上で制約が多く、非常に窮屈に感じることでしょう。

けれどwebデザインの魅力はなんといってもギミック。マウスの動きに応じてボタンが光ったり画面がスクロールしたり、Googleのマテリアルデザインをはじめぬるぬる動くサイトもよく見ますよね。

これまで2次元のデザインをしていた私は、自分でつくった画面が実際に操作できることに興奮を覚えました。 そしてそれはまた新しいデザインの扉だったのです。

マインドを切り替える

f:id:kenichi_nara:20181226112653j:plain

チラシなどの場合、伝えたい要素に優先順位をつけて要素の大小や色のコントラストの強弱、紙面における割合などを勘案しアウトプット(レイアウト)をしていきます。このあたりの定石はwebデザインにも応用ができると思いますが問題はこの先。

紙媒体が一方的に伝えたいことを投げかけるのに対し、webではユーザーがなんらかのレスポンスをすることが重要なのでレスポンスしやすいデザインが求められるわけですが、そのプロセスで私は今まで使ったことのない頭の使い方をすることになりました。

  • ユーザーがwebサイトを利用するタイミングはいつか
  • ユーザーはどういう目的を持って訪れているのか
  • その目的を達成するために、どのような情報や仕組みが必要か

などなど。

どのように目を留めさせるか、どのように購買意欲を刺激するか、という言わば「攻める」とか「仕掛ける」といったスタンスでデザインをしてきた私ですが、「受け止める」「寄り添う」という真逆の気持ちに切り替える必要がありました。

「体験をデザインする」ということ

では「受け止める」「寄り添う」デザインとはなんなのか?

「UX」という言葉が普及して久しいかと思います。

ざっくり言うと「ユーザーがサービスに触れて得られる体験のこと(検索すればもっと詳しいサイトが山ほど出てきます)」ということですが、ではそれをデザインする、つまり

ユーザーがサービスに触れて得られる体験をデザインする

というと、ものすごくフワッとしませんか?
少なくとも私の脳内では音もなく舞いました。

ともすればどこかの企業のキャッチフレーズにも聞こえてくる「体験をデザインする」という概念。私はこれをオウチーノの物件検索サービスの設計を通して学ぶことができました。

例えば新しいwebサービスをつくるブレストをしたときに、

  • 「お気に入り機能が欲しい」
  • 「地図は必須」

のような具体的な機能って出てきがちですよね。 しかし「体験」はそういった様々な機能を使った後の話なので、

  • 「気になった物件を後から見返したい」(→ だからお気に入り機能が欲しい)
  • 「物件の位置関係を把握したい」(→だから地図は必須)

のように機能の前に「欲求」が先にあるわけです。

ここからはあくまで私が理解しやすい形での解釈なのですが、

UXデザインというのはユーザーの、コレほしい、アレしたい、という「欲求」の動きを予見したうえで、しかるべきタイミングで解消する方法を提供する言わば...

我儘お嬢様に対しての執事的なアプローチ...!

陳腐な例えですが、体験をデザインする「体験」がない私にとってはざっくりと飲み込みやすいものでした。

これが腹落ちすると

  • ユーザーってどんな人を指すの?
  • ユーザーの欲求を集めよう
  • ユーザーの欲求を繋げて動きを見てみよう

といったペルソナだとかユーザーインタビューだとかカスタマージャーニーマップなどの必要性も必然的に理解でき、実践していくことでUXデザインの概要を知ることができたのでした。

f:id:kenichi_nara:20181228103655j:plain
開発当初の画面。一番左は実装に至らなかったボツ案です(デザイン供養)。

まとめ

同じデザイナーなので重なる部分も多いと思われがちですし、実際お互いがお互いの仕事をまったくできないかと言われるとそうでもなかったりもするんですが、私の体感だとDTPデザイナーとweb(UI/UX)デザイナーはまったく別の職業だと感じています。

個人的には苦労の多かったジェブチェンジ体験ではありましたが、不動産ポータルサービスを展開する上で新たな視座が得られたことは財産になりました。

これからwebデザインを始めようとしているDTPデザイナーの方や、現在webデザイナーだけどDTPもやってみたいよという方の何かの参考になれば幸いです。