#dxel エンジニアとデザイナーが仲良くなる「DXEL.1 エンジニアとデザイナーが「いい関係」を築くために」に参加してきたまとめ
DXEL.1 エンジニアとデザイナーが「いい関係」を築くためにという、デザイナーと仲良くなりたい（あわよくばデザインになりたい）私には、とても興味深い勉強会が実施されていたので、ブログ枠として参加してきました！
本記事はそのまとめになります。
1. 「そのUI、実は簡単じゃないんです」
実装するにあたってすげー手間と思ったことを3つ紹介
戻るボタンをタップ時にアラートを表示したい
- 例えば戻るボタンを押したときに「編集中だけど戻っていいっすか」というアラートを出したい！！
- カスタマイズすることも出来るし、タップ時にアクションを付け加えるのも出来る
- 戻るボタンの色を変えるのは1行で出来る
- 戻るの文字を消すのも簡単
- テキストオンリーで表示することも出来る
- 標準の戻るUIとアクションの組み合わせは難しい
- ボタンの中にイメージとテキストを入れてそれっぽい実装にする必要が出てきてしまう
- 1箇所だけ変更しても、全体の画面でも変えるとなった時、メンテナンス性が悪くなる
- 解決案としては、戻るボタンを標準のものを使わなくしたり、自動保存にしてアラートを出さないようにする
ハイパーリンクつけたい
- webでよくみるハイパーリンクはとてもめんどくさい！
- UILabelで対応するのであれば、色やサイズを同じ設定にするのは楽だが、文字の一部にハイパーリンクを設定するのは大変
- タップに反応するようにしたり、リンク部分を青文字にしたり、タップされたなかでリンクをタップしたという判定したという処理をつけないといけない
- 解決策はリンクはボタンとておくようにする
アコーディオンメニュー
- ios標準で実装するのは大変で、UITableViewを改造して作る形にする必要がある
- アコーディオンは、カテゴリ-ジャンルのような親子関係を作るが、section headerをカテゴリとして、cellをジャンルとして考える必要がある
- sectionはタップに反応しない。
- 親子関係の構図を作るのが大変
- 開閉状態を覚えさせないといけない
- アニメーションに自由がきかないのでメンテナンス性が悪くなる
- 解決案
- カテゴリをタップしたらジャンル画面に遷移するといったものにする
- WebViewにしてしまう
まとめ
- iOS固有のUIがあり、iOSでよくみないUIにはそれなりの理由がある（実装が大変など）
- そういう話になるのであれば早めに議題に上げたほうがいい
- 実装を頑張ればできなくはないので、コストと体験を見合って話せるといい
2. 「Atomic Designはデザイナーとエンジニアの架け橋」
- atomic designとは、デザイン案を作る上でパーツができていないという時があるが、パーツごとに（プライマリーボタンはこれ、戻るボタンはこれ）定義しながら、並行して資料を作っていくデザイン方法
- 原子(Lv1)という一番小さい単位で作ったものを、組み合わせてユーザが見てわかるようなパーツになる分子(Lv2)を作り、さらに組み合わせて大きくわかるような生体(Lv3)を作り、さらにワイヤーフレームとなるテンプレート(Lv4)を作り、最終的にデザインカフとなるページ(Lv5)を作る
- 決定力のあるデザイン
- デザインデータのバージョン管理
- デザインをやる上で気をつけていることは、ユーザに使ってほしい想定のコンテンツをデザインに反映させるようにする
3. 「約2ヶ月デザイナーとペアプログラミングを行なった話と僕が伝えたいこと」
デザイナーと約2ヶ月間ペアプロをした時の話
- デザイナーはもともとエンジニアとのコミュニケーションに課題を感じていた
- デザインをする上でautolayoutの仕組みでデザインをしたい
- エンジニアが言っている「難しい」というのを理解できるようになりたい
- エンジニアはautolayoutを知ってもらうことでコミュニケーションが楽になり、知識レベルの共有を図れば、説明の仕方のも軽くなりそうとおもった
- 教え方
- 1日1時間位やっていた
- 教えるだけじゃなくてどういうふうに作りたいかと相談しながら作っていた
- swiftにはふれずにUIのみを教えていった
- iosのtableviewやcollectionview、GithubのPullRequestなどを教えたりした
- githubに関してはGUIツールを使って覚えてもらった
- 教えてたら自分でも学ぶようになっていて、いつの間にか実装が終わってた
- atomic designを取り入れて開発した
知識レベルの共有結果
- 今まではデザイン確認頼まれて、確認したらできなかったり、やりとりしたあと、うまくコミュニケーションがとれないこともあった。
- エンジニアの声に理解できるようになったり、代替案としてautolayoutで提案してくれるようになった
- iosの用語を自然に取り入れるようになったので自然と話せるようになった
- アニメーションを入れて確認した際に、PullRequestを上げて、デザイナーの方で実際の値の調整をしてくれるようになった
- 簡単な部分であれば勝手に直して対応してくれるようになった→強い、嬉しい、楽しい！
まとめ
- 仕事する上でもっと充実したい、理解したいというきっかけで今回のことがうまれた
- 楽しくチームで楽に作っていこう
- 発言したり、相談するだけでも大きな改善にもつながったりします
4. 「デザイナーとエンジニアを両方経験したわたしが思うこと」
- モットーとしているのが、触って楽しい（エンジニア目線）、見て気持ちいい（デザイナー目線）をモットーに作っている
- エンジニアとデザイナーの両方経験してわかったのは、コミュニケーションがめちゃくちゃ大事です
デザインの仕事を軽視される昔話
- 上流工程に時間がかかったせいで、デザインの作業が少なくなってしまった
- 造り手に優しい画面になってしまっていた
- エンジニアのほうが立場は強かった
- 凝ったデザインを作ったとしても実装が難しいと妥協した結果、ユーザからの問い合わせが多数発生していた
- いいデザインをつくっても一方的に拒否られたら辛く傷ついてしまう。作ったものを拒否られないために離せなくなると、ネガティブ思考になってしまった。
- 改善として、同じものづくりをする仲間として認識することにした。
- 自分が思っていることを相手に伝えるようにする。
- 造り手ではなく、使い手目線を一緒に考えるようにした
- デザイン作業を見える化した。
- 今は登録不要でデザインの共有ができるので共有しやすい
- 感謝と共有をお互いに忘れない
- エンジニア：わかりやすい！すごい！画面作ってくれて有難う！
- デザイナー：うごいた！すごい！実装してくれてありがとう！
まとめ
- 1日の多くを占める時間を楽しく過ごそう！
- なにかしてくれたら申し訳ないではなく、ありがとうを言う
- 言語コミュニケーションと非言語コミュニケーションを組み合わせよう
5. 「今日からはじめるデザインレビュー」
- デザインレビューは、デザインのことがわからないのに話していいのかわからないといった理由で難しいと言われる
- デザイナーとしては個人的な感覚（なんかきもい、この作りだと綺麗なコードが書けないから無理など）で話されると判断軸を失うので、どの意見を参考にすればいいかわからなくなる
レビューの仕方
- エンジニアがデザインをレビューするには、HIGやMaterial Designなどのガイドラインを軸としたレビューをお願いします
- ガイドラインはユーザビリティが考え抜かれていて、開発もしやすく考慮されている
- ガイドラインという共通言語が出来ることで、なぜこのボタンを意図的に崩したのかというのが意図的に説明しやすくなる
- ユーザとしてレビューをお願いします
- まずは頭を空っぽにしてください
- 見た目の話だけでなく、使い勝手のデザインを見ることでユーザは取り入れやすくなる
- サービスは使いたいか使いたくないかの意見をすることでユーザの意見を取り入れられる
- パーツのレイアウトやいらない機能を処することシンプルなサービスになるが、散々悩んで作ったデザインなので、処するときは優しく処してください
- レビューされるときの心構えと判断軸
- デザイナーはレビューをどううけるか？→最終判断はデザイナーの手にある
- HIGやMaterialDesign観点から外れるものは聞いても真に受けるのはやめましょう
まとめ
- 感覚でレビューしない
- ガイドラインに沿って話をする
- 処するときは優しくする
- 最終判断はデザイナーにある
6. 「デザインに込められたエモを知りたい」
- 画面のビジュアルデザイン、どの画面でどのように機能を提供するのかというのをデザインとよんでます。
- 開発の流れでデザインに込められたエモ（思い、願いなど。最高ーってなったらエモ）を知りたいとなった
- エモを知ることで、エモにあった技術サイドからの提案ができそう、開発のモチベがあがりそう、デザイナとわかりあえそう
- デザイナー観点では、見当違いなことを言うのを減ったりコミュニケーションがうまくとれるのでは
- どうやってエモを知るか？
- エンジニアがエモを汲み取る→難しい
- 都度デザイナさんにきく→難しい
- →デザインのエモを共有してもらう会（通称エモ会）を開いてみる
- フロントエンドに関わる人達に、サービスのデザインに込められたエモをデザイナーに語ってほしいといったら全員参加してくれた
エモ会でのデザイナーからの会話
- デザイナさんが話してくれたことは、サービスの全体で大事にしていることは〜と話した
- 空間から想像を掻き立てたいのよ！ → えもい！
- まんまるよりもまるい表現をしたい！ → えもい！
- マテリアルデザインを採用しているのは〜 → web/pc/アプリとあると、こちらのほうがいいという納得感があった
- エンジニアは足かせではなく翼であるべきだ → 翼になります！
- この画面の機能や狙いは〜 → そういう狙いなら今後起きそうなので考慮して開発しよう！
エモ会でのエンジニアからの会話
- Sketchの完全トレースってどれくらい意味ある？
- 大事なときもじゃないときもある
- それなりに似せて作って調整すればいいかと
- 完全に再現したりずれをなおすとぐっと引き締まることもある
脱線トーク
- プロダクトチームはどうやったら良くなっていくのか
- ビジネスチームとどうやったら仲良く慣れるか
振り返り
- コミュニケーションがとても活発に取れてわかり会えた
- 人数がおおすぎずちょうどよかった
- エモを聞けてモチベが上がった。
- エモ会おすすめ
- 30分/週2でHIGを一緒によんでいるがおすすめです
7. 「Android, iOS 両方を考慮したアプリデザイン管理」
- targetは、エンジニア→デザイナーになるひと、webデザインやったことあるけどアプリわからんという人
アートボードの管理
- もともと、1アートボードにすべての機能をつこんでいた。1-枚以上画面があると読み込み時間が長いときもあった
- いろんな画面が一つのアートボードにあって、ひとつずらすと、コメントがずれたりすることもあった
- zepinで、conponentsという機能がリリースされ、そのcomponentsに画像などを登録しておくと、アートボードとヒモ付ができて、使っているアートボード一覧も見れる。
- ios/androidで共通なものを登録する
- 70-80個くらい登録すると金払ってるのに金払えといわれるらしい
- 今やっているやり方
- プロジェクトは1プラットフォームに付き1個
- アートボードは1画面に付き1枚だが、ボタンの活性非活性状態のデザインなど、関連するものは同じところに含める
- 共通コンポーネントはcomponents経由に。
- フォントやスタイルはtext stylesで管理する
画像の管理
- SketchでスライスしたところはZeplinで画像として書き出せる
- AndroidでもiosでもSVG表示は可能だが、実装側はiosはちょっと面倒
- エンジニアがやりやすい方を選んで上がればいい
- GoogleもVector使うかどうかは考えてと言っている
- 物によっては200×200以上の画像は初回読み込みが遅かったりする
- png/jpgエクスポートも出来るので適材適所、やりやすさで選ぼう
まとめ
- zeplin/sketchはいい組み合わせ
- ある程度の仕組みを作ってしまえば、お互いの作業に集中できる
8. エンジニアだけでがんばってみた
YuriHotate様
- 弊社にはデザイナーがいないが、チームスポーツのマネジメントアプリを作った
- 新規の画面が20-30枚くらい
- すべてが真新しいので大変でした
- スタートアップなので待つわけにも行かず、募集をかけても人は来ずエンジニアだけで20、30の全て真新しい、非標準的な画面の機能を作った。
- どうやって作ったのか→INSPIRE（パクツイ）である
- 国内海外問わず、スポーツのアプリを使い倒して、どんな機能があるかを洗い出して、自分たちのアプリに使いたい機能を洗い出して画面に落とし、ワイヤーフレームを作った
- デザイナーが入ったことで、画面数が多いUIが統一された。
- 全体の世界観が抜けてしまってUIが統一されてなかったが、統一して色にも意味合いをもたせてくれた
- チームスポーツの管理なので、メンバーを管理する人、管理される選手、保護者、選手たちの活動を応援するフォロワーなどのいろんな立場のユーザがいる
- すべてのユーザのUXを作るのかが最初はできてなかった
- デザイナーがそこをなんとかしてくれた
- 結論、デザイナーすげぇ。
@mogmetの所感
いろんな会社でのデザイナーとエンジニアの関わり方、仲良くなる方法などをしれてとてもよい勉強会でした。
私としては、感謝の気持ちを忘れない、ガイドラインを読み込むなどといった基本的なところを疎かにせず実施していかないといけないなぁと感じました。
