読者です 読者をやめる 読者になる 読者になる

らこらこブログ

唐揚げとアニメとプログラミングが大好きです

Design-JP 第1回 勉強会に行ってきたメモ

先日、 "Design-JP"という名前のデザイン勉強会に参加してきた。

design-jp.connpass.com

その名のとおりデザイナーやデザイン寄りのエンジニア向けの勉強会で、 専らGoogle App EngineやらAngularやらやってる人間からすると未知の領域だった。 今の仕事でデザインやプロトタイピングをやることはまず無いので、 "知識"を得るというよりは、"異文化交流"しようと思って、新しい考え方を求めて参加した。

以下はイベント中のメモや参考リンクの備忘録である。 発表中に"これは秘密で"と言われた部分はもちろん書いていない。


プロトタイピングツールの使い所の話

  • プロトタイピングツール
    • Prott
      • 聞いたことはあった
    • Adobe XD
      • 聞いたこともなかった
    • その他もいろいろ
  • 結論
    • 適切なタイミングで適切なツールを使うべし
    • 適切なタイミング
      • デザインが決まった後でアニメーション試すためにあとから突っ込むみたいなのは成功しない
    • 適切なツール
      • プロトタイピングにかかわる人間に合わせる
      • クライアントと共同作業があるならそれに合わせる
      • ひとつのツールにこだわって効率を落とさない
        • パーツ作りをXDでやって、Prottで組み合わせてプロトタイプを作る合わせ技
        • 若い人ほどひとつのツールを使いこなして完結させようとしがち

プロトタイピングによる効率化

  • なぜ多彩なデザインツールが出てきているのか

www.yasuhisa.com

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

www.yasuhisa.com

  • プロトタイピングによくある失敗

    • プロトタイプを成果物と思ってしまう
      • 学びを得るためのツールだと思っていない
    • プロトタイプを共有する相手を見ていない
      • 自己満足な作りこみ
    • ひとつのツールに固執する
  • プロトタイプの目的

    • イデアやデザインを忠実に伝えるために本物に限りなく近いものを作ること ではない
    • 時間をかけずに目的に合わせて内容を可視化すること
  • ツールの充実
    • 動くもの(それは本当にプロトタイプなのか?)を作ることが前提っぽい風潮
    • 無駄なことをやってしまう
  • 本末転倒なプロトタイプ
    • 相手に伝わらない
    • 画面数が多くて修正に時間がかかる
    • 見せたかった部分じゃないところにツッコミ
    • 実装が無理だった
  • 本来の目的を思い出す
    • 内容の確認
      • 何を?誰と?
    • 共有
      • 誰と?
    • 実装機能の検証
      • 何を?どのレベルで?
    • フィードバックの収集
      • 誰から?何を?
    • 実際の環境に向けての最終調整
      • どんな環境?
  • Keynoteは最強のプロトタイピングツール
    • 静止画で画面のストーリーを作る
    • 実装がないので修正も早いしわかりやすい
    • お客さんが理解できるツールのほうがいい場合も多い
      • クライアントの担当者の、さらに上からOKを貰えるプロトタイプが必要

プロトタイピングのコツ

  • 忠実度を考える(作り込み過ぎない)
    • 誰に見せるか、適材適所と作業時間でどれを作るかを考える
    • 自分だけ(素早さ) < チーム(話し合い・共有) < テスト用(見た目・印象) < クライアント(見た目・完成度)
  • ツールの使い分け
    • 目的別のツール選定表 Prototyping Tools | Cooper
    • どこでも素早く仕事したいならネイティブアプリのツール
    • Keynote最強 誰もが持っている・使える・編集できる
  • 早く作り過ぎない/打ち合わせの場で作る
    • ちょっと早く出すくらいがちょうどいい
  • みんなではじめるデザイン批評
    • プロトタイプを批評してもらう、批評するタイミングが重要
    • イデアを自分の言葉で説明できるくらいに固まってから批評をもらう
  • A shorthand for designing UI flows
    • デザイン抜きで、各画面で見えているものとできることだけを書き出してつなげておくと、デザインするときに頭が整理されている
  • アニメーションは作ってしまうのもひとつの手
    • アニメーションはカーブを使って表現する
      • 直線?指数関数的?
      • とりあえずエンジニアに頼んで作ってもらうが、そのコードは 捨てる前提 で書いてもらう
  • ダミーではなくちゃんと本物の画像や文言を使うことで、コンテンツの意味を考えて幅や文字の大きさなどデザインを評価できる
  • (iOSとかAndroidとかそれぞれのプラットフォームの標準パーツを組み合わせて作ったものが、基本的にいいものになる
    • 独自のパーツはよっぽど斬新なアイデアのときだけ
  • プロトタイプのときはまずひとりで使えるもの、ソーシャルはその後
    • はじめて使う時だけの画面は忘れがち
    • インストール/登録→初回→友達がだれもいない状態のデザインが重要
  • 狩野モデル
    • 作りこんでも当たり前だと思われる部分、作りこんだら魅力になる部分
    • "当たり前品質要素"をまず大事にする

以上、ざっくりメモ。噛みくだいていけばプログラミングにも応用できる話がいくつもあったように思う。 話の内容こそ実感のないものだったが、特に難しい用語があるわけではないのでイベントは十分楽しめてよかった。 次回もぜひ参加したい。