Nice XXXer eXperience

プロダクト開発でデザイナー、エンジニア、マーケター、セーラーがお互い仕事がやりやすくするために、自分が意識していることをざっくり紹介します。

Transcript

1. Nice XXXer eXperience @ksmxxxxxx 2022/04/17
2. 自己紹介 フリーランスのWebおばはん。 人生のスローガンは「後ろを向きながら全力で 匍匐前進」。 UX/UI/Design/Keyboard/JavaScript/Ruby https://github.com/ksmxxxxxx https://twitter.com/ksmxxxxxx https://docs.ksmxxxxxx.page/
3. Agenda B 相手に通じる言語で話# B 「どうしたらもっと良くなるか」でコメン1 B 参考書籍の紹介
4. 相手に通じる言語で話す
5. 全体のトンマナを 揃えるように…… DBのテーブル設計が…… F1層に対してリーチ させるように……
6. トンマナってなに？ F1層ってなに？ テーブルって？
7. 職種ごとの専門用語を出されると、相手は となってしまう 「何の説明をされているのかよくわからない」
8. 相手は素人である ” 事業会社でプロダクト開発をしていると、他職種の同僚と一緒に活動することが当たり€ ” 他職種の人は、自分が日常的に使っている単語の意味を知らないのは当たり前
 デザイナーは1チームにひとりという現場はザラなので圧倒的マイノリティ) ” 自分がエンジニアリングを学習していたときのことを思い出して、「ああいう説明をしても らえたらわかりやすかったな」というポイントを真似したりして、
 説明することを意識すh ” これはエンジニアだけでなく
 デザイナーやマーケター、セールスにも言える
9. レビュー
10. 言われて、シンドい…って思う事例 y 思ってたのと違うんですよね→どういうのをイメージしてたのQ y パッとしないですね→同E y ここの部分、この色にしてほしいです→なぜその色じゃないとだめなの？理由はあるの？ （機能としての精度より、個人の好みでレビューされているみたいでなんのために作ってる のかわからなくなる y コードレビューでもこれに似たようなことを言われると、ツラいなぁって思っちゃう
11. レビューするときに気をつけているポイント u レビューをいらする時：レビューしてほしいポイントをまとめ‚ u レビューする時：相手に実装の意図を確認す‚ u 意図を理解した上で、もっとよくなる改善案などがあれば、
 「こうするともっと良くなると思うんですがどうですか？」とコメントす‚ u あくまで提案する体裁でコメントする。
 採用するかどうかはレビュイーに判断してもらs u 「これは絶対問題あり」っていうものに対しては、
 はっきり理由を提示して「修正してください」と伝える
12. 参考図書のご紹介
13. みんなではじめるデザイン批 評 デザインレビューについて、海外の事例を紹介 しながらアプローチを紹介している本。名著。 題材がデザインレビューだけど、コードレ ビューや、プロダクトの機能検討などいろんな 場面で応用できるのでオススメ。 前職ではチームの推薦図書として、新入社員に は必ず読んでくださいと言っていた。
14. Team Geek
 ―Googleのギークたちはい かにしてチームを作るのか エンジニアの間では名著って聞いた。 前職の推薦図書だった。
 HRTの原則の出典元になった本。
 大抵のことはHRTの原則で解決できると思って る。
15. プロダクトのUXはチーム（組織）のUXから
16. Have a nice working, THX!