帰国後最初の勉強会ということで(本当は9月のpotatotipsが最初だったはずだけど…)、ブログまとめ枠で参加してきました。
どうまとめたものか考えた結果、ザッとメモを取ったのをそのまま垂れ流そうかと思います。
1. kanamorit - デザイナとの協働を通じてわかったこと
- デザイナさんに対し強く意識していること
- 呼び方
- デザインと言う言葉の意味の広さ
- デザイナさんの言葉遣いを真似する
- 色彩
- ブランド、認知可能な色数
- 任せる!
- 領分
- デザイナ -> どう伝えるか
- 開発 -> どう作るか
- 信頼すること
- 交わる点にはきちんと関心を持つ
- 呼び方
- 意識が変わったこと
- 文字+絵で伝える
- 画面・レイアウト構成・遷移、行動など図示
- 注意深く観察する
- 配置、重なり、動き、マージンなど
- なぜそうするのか
- 実現可能性を最大限
- 文字+絵で伝える
- 開発でうまく行ったパターン
- チーム構成
- 企画・デザイナ・開発
- 方法論
- モック・プロトタイプ
- 必要なものの洗い出し、競合調査
- 提案は無条件で受け入れる
- やってみて検証
- 提案の受け入れ、検証、改善サイクル
- 互いの気の大きさを合わせる、動きを合わせるなど
- チーム構成
- 残念だったこと
- 途中でリソースが尽きて自転車操業に
- 提案や考え方を受け入れるところから始める
2. yucovin - デザイナーさん向け・プログラミングのすごいところ
- デザインとプログラミングの垣根を取り払いたい
- How to
- お互いのことを知る
- 相手の立場に立ってみる
- 実践
- 初めてプログラミングを体験して感動したこと
- 一歩一歩進んでいるのが目に見えてわかる
- コードと動きが直結している
- 絵の世界は、全パラメータがある程度上がって一段登るイメージ(進捗が分かりづらい)
- ベテランでも初学者でも同じコードをかけば同じように動く
- 絵は線一本マネできない
- 一歩一歩進んでいるのが目に見えてわかる
- 小さいパズルを組み合わせていく感覚
- 易しいところから始めるのがよい
3. masaki_ohsumi - デザインエンジニアという考え方
- デザイナーとエンジニアのギャップとは
- 価値観のちがい
- デザインを認めていない?
- 実現可能性を考慮してない?
- 技術の複雑化、多様化に伴って…
- デザインエンジニアの必要性(間を埋める人)
- 両方あるいはそれ以上の視点をもってプロダクト開発を行う人
- dyson
- yamanaka shunji
- tagawa kinya
- 価値観のちがい
- デザイン的視点・技術的視点
- 2つの視点を交互に行き来することで、問題を多面的に観察し課題解決をする
- 求められる者の違い
- デザイナ:インパクト
- エンジニア:実現可能性
- 直行するベクトルの中間がベストポイント
- デザインエンジニアがいればシームレスにベストポイントを見いだせる
4. よこてっく - PhotoShop でプログラムを使い効率化を図ろう!
- スクリプトを動かして効率化する事例
- アクション機能
- バッチ処理
- 登録した作業の履歴を他のファイルに適用するときに使う
- スクリプト機能
- JavaScript
- 条件をつけて処理を書きたいときに使う
- 事例
- 協働のためのスクリプトを組み込もう
5. d_date - デザイナーと Storyboard
- マルチデバイス対応
- 作成したデザインの再現性
- 修正のスピード
- 理解度によってはエンジニアに負荷がかかる
- UI パーツの理解
- プロパティ
- マルチデバイス対応方法
- AutoLayout
- 変更差分の内容理解
- git の差分がわかる?
- コードを書かない範疇でStoryboardの使い方をマスターする
- パーツの理解
- UIView:レイヤ
- UIButton:ボタン
- UILabel:ラベル
- UITextField:入力欄
- これ以外はエンジニアと相談
- どこまでいじるかはちゃんとルールを決める
- マルチデバイス対応方法
- AutoLayout を知る
- 変更差分の内容理解
- git
- 見覚えがないものは聞く
- コンフリクトに気をつける
- 同じ画面を同時に編集しないなどの運用でカバー
- ユニバーサルアプリ開発
- エンジニアと方針を確認する
- Sketch + Zeplin
- Sketch + Sympli
6. MutsumiOkano - パッションがとても大切だった話
- デザイナーとエンジニアの垣根
- ツールや技術論はとりあえず捨ててから
- UI + Android
- 精神的な垣根を取り払わないと良いプロダクトが作れない
- 事例
- MaterialDesign で整合性だ!
- 整合性って何
- 誰のためのデザイン
- 運用は?
- 作りやすいけどそれでいいのか
- 良いプロダクトのイメージの共有・意思疎通を最初にする
- デザインの統一・情報の優先順位をつける -> ユーザの目的を達成しやすくしたい、運用改善に耐えうるデザインにしたい
- リファクタリングしたい -> 品質・運用改善に耐えうるコードにしたい
- お互いのやりたいことの上位概念を共有する
7. tomomasa.masuzawa - 見えないデザイン
- エンジニア・デザイナともに見落としがち、忘れがちなこと
- アクセシビリティ
- 広義に、誰にとっても使いやすいこと
- 狭義に、ハンディを持つ人にとって使いやすいこと
- ボイスオーバー
- スワイプやフリック、引張操作、長押しは操作しづらくなる
- iOS のボイスオーバー
- テキスト部品は勝手に読み上げられる
- 画像等は画像ファイル名を読み上げるので、別途読んでほしいことを設定する
- まとめ
- 操作が一つ増える
- 素早い操作は不可能という前提
- 画面に表示されない操作を割り当てると操作しづらい
- スワイプ、引張、長押し
- テキスト情報のない部品はアクセシビリティ用の情報をつける
8. fumiyasac - デザイナーだった記憶を忘れないために自分なりに気をつけていること
- 自分のアプリ開発での経験
- コード書くだけじゃなくデザインもする
- お互いの言い分や楽しみやつらみを体験できる
- ジョブチェンジした時の体験
- 昔に培ったことを忘れてしまう -> もったいない
- デザイナとエンジニアの交差点
- とりくみ
- 気になるアプリの UI を見習う
- コンテ書きとノートから始める
- 言葉とサンプルによる説明を残す
9. JPMartha - Collaboration
- 個人的には垣根を意識していない
- あんまり深く考えてない
- UserStory
- ZenHub の GitHub Project Management
- ユーザーストーリー
- ZenHub の GitHub Project Management
- GitHub Project Management, ZenHub
- ユーザーストーリー:ユーザーの利益をシンプルに表現する
- Good design solves problems
- Designers make things delightful and easy to use
- At its best, design can positively change the world
- シンプルに
- ユーザーストーリーを考えて共有する
- 何をデザインし、何を解決するのか
- デザイナもエンジニアも手法は異なるが目的は同じ
10. akio - iPad で Swift プログラミング[Playground]
- スキマ時間でプログラミングが勉強できる
- 左にコードペイン、右に実行結果がわかる
- 補完もきく
- UIKit とか AVFoundation とかたいていのフレームワークが使える
- 色の値も補完できる
- 画像もその場で取って UI に配置できる
- 子供向けにプログラミングを学ぶ教材も入っている
グラレコ
まとめ
いつも行くエンジニア向けのイベントにはないグラレコがあって、即興でこの素晴らしい図が出来上がっていくのを見るのはすごいなって思いました。 そして発表も、方法論から概念的なものまで様々でしたが、誰もが「いいものを作りたい」というエモさをもって発表していて、一体感のようなものを感じました。