たぶん、ねむたくなる

忘備録的におもったことだけ

20160104 : デザイナーの未来

2016年 デザインに関する5つのトレンド blog.btrax.com

これスゴくいい記事だなーと思ったので引用しながら考えてみる。

デザイナーがエンジニアリングもするの?

昨年こういうのがあがった。

この記事内にある以下は「市場にいないからもう作るわ!」ってことですね。

既存の社員の育成と併せ、17年3月卒の新卒で約10人の採用を目指す

これはリーン・スタートアップや時代特性を加味して考えればそうなのかなと。 今の時代は“まだ”大きな資本がなくても市場に大きな影響を与えることが(たぶん)出来る。 でも、CAみたく大きな会社でも何が市場的にあたるかは検証しないとわからないから、少人数且つ高速でプロダクトを作れるチームで開発し当たればスケールさせよう!ということです。

その意味では記事の

デザイナーとエンジニアの境界線がどんどん無くなる

は市場価値の高さに比例した見方をして良いと思う。

※ 僕個人が考える市場価値は次な感じ
デザイナーとしての職能 x 他の職能 = 市場価値(レア度)

ex.
100人に1人のデザイナースキル
50人に1人のエンジニアスキル
10人に1人のディレクタースキル
▶ (1/100)x(1/50)x(1/10) = 5万人に1人の市場価値の人

エンジニアリングによって市場価値をあげようとするなら、学習コスト的にエンジニアリングでどういうことが出来るかとか、どうやればコストをかけずに出来るかみたいな視点からはいると良いはず。
それだけでチームのコミュニケーションなりがぜんぜん違うと思う。 というかその発展先にディレクター(プロジェクト・マネージメント)があるw


そもそもデザイナーって?

デザインは問題を解決する手段なので別にエンジニアリングが― とかどうでもよいのでは?って思ってます。

極端な話、この先GUIが在り続けるともわからない。
世界がNo GUIになった時(例えばSiriやOK Googleといった音声によるUI)になった時どうデザイナーとして立ち振舞が出来るか?を考えたら良さそう。

www.creativevillage.ne.jp

  • デザイナーとしての道を極める
  • 企画者として上流から携わる
  • コーディングスキルを身につけ、実装全てを担う

とあったりするわけですが、どれか1つでなくても良いのかなーと。全部中途半端でもそれが全部80点であればいろんな役割出来るわけでそれは結構求められてると思いますし。
デザイナーって自分のやりたいように生きる人が(自分含めて)多いですし結局何したいの?基準で考えてみるのが良いと思う。

参考までにエンジニアリングでなく、企画側だと最上流(事業責任者)はこういうことらしいです

developers.eure.jp




デザイナーと一緒に仕事をする人へ

デザイナーってとっつきにくいとか言われる方もいると思う。そういう方は最初に挙げた記事のデザイン思考を分解して欲しい。 分解すると以下2点なのですがご存じない方は定番「誰のためのデザイン? 増補・改訂版 」を読むのがいいと思う。とりあえずざっくり説明。

  • ダブルダイヤモンド
  • 人間中心デザインの反復モデル

▼ ダブルダイヤモンド

  • 問題の本質を見つける
    • 発散 (選択肢を広げる)
    • 収束 (選択肢を取捨選択する)
  • 問題の解決策を見つける
    • 発散 (選択肢を広げる)
    • 収束 (選択肢を取捨選択する)

▼ 人間中心デザインの反復モデル


デザイナーの仕事の1/3は相手を理解する事、1/3は解決策を伝える事、そして最後の1/3がデザイン作業である。すなわち、デザイナーの仕事の2/3はコミニュケーションに充てらてれる。

と記事にありますが、実際にデザイナーは仕事すると各項目の内訳付けてこんな感じ。

  • 相手(ユーザー)を理解する
    • 1.なんか問題がある (数字悪い)
    • 2.そもそもなんで問題なの?ほんとに悪いの?
    • 3.それで困ってる人ってどういう人なの?
    • 4.どうなったら問題が解決したって言えるの?
  • 解決策を伝える
    • 1.問題が解決しうる案を出しまくる
    • 2.案の現実性を考える (ユーザーの特性や背景, 技術, 工数, 予算)
    • 3.堅そうなものを発展(ブラッシュアップ)させてみる
    • 4.発展させたものを比較してデザインするものを定義する
  • デザイン作業
    • 1.問題と解決策を元に何パターンか作成
    • 2.パターンを検証 (影響範囲の大きい物はユーザーテスト)
    • 3.検証を元にブラッシュアップ
    • (4.出来たものを実装)
    • 5.ローンチ / アップデート

上記ができてないから咎めるとかでなく、一緒に何をやればよく出来るか これをベースにデザイン思考とかチームの練度上げとかのきっかけになったらいいなぁ。


[ 関連オススメ本 ]