Slide 1

Slide 1 text

Nice XXXer eXperience @ksmxxxxxx 2022/04/17

Slide 2

Slide 2 text

自己紹介 フリーランスのWebおばはん。 人生のスローガンは「後ろを向きながら全力で 匍匐前進」。 UX/UI/Design/Keyboard/JavaScript/Ruby https://github.com/ksmxxxxxx https://twitter.com/ksmxxxxxx https://docs.ksmxxxxxx.page/

Slide 3

Slide 3 text

Agenda B 相手に通じる言語で話# B 「どうしたらもっと良くなるか」でコメン1 B 参考書籍の紹介

Slide 4

Slide 4 text

相手に通じる言語で話す

Slide 5

Slide 5 text

全体のトンマナを 揃えるように…… DBのテーブル設計が…… F1層に対してリーチ させるように……

Slide 6

Slide 6 text

トンマナってなに? F1層ってなに? テーブルって?

Slide 7

Slide 7 text

職種ごとの専門用語を出されると、相手は となってしまう 「何の説明をされているのかよくわからない」

Slide 8

Slide 8 text

相手は素人である ” 事業会社でプロダクト開発をしていると、他職種の同僚と一緒に活動することが当たり€ ” 他職種の人は、自分が日常的に使っている単語の意味を知らないのは当たり前
 デザイナーは1チームにひとりという現場はザラなので圧倒的マイノリティ) ” 自分がエンジニアリングを学習していたときのことを思い出して、「ああいう説明をしても らえたらわかりやすかったな」というポイントを真似したりして、
 説明することを意識すh ” これはエンジニアだけでなく
 デザイナーやマーケター、セールスにも言える

Slide 9

Slide 9 text

レビュー

Slide 10

Slide 10 text

言われて、シンドい…って思う事例 y 思ってたのと違うんですよね→どういうのをイメージしてたのQ y パッとしないですね→同E y ここの部分、この色にしてほしいです→なぜその色じゃないとだめなの?理由はあるの? (機能としての精度より、個人の好みでレビューされているみたいでなんのために作ってる のかわからなくなる y コードレビューでもこれに似たようなことを言われると、ツラいなぁって思っちゃう

Slide 11

Slide 11 text

レビューするときに気をつけているポイント u レビューをいらする時:レビューしてほしいポイントをまとめ‚ u レビューする時:相手に実装の意図を確認す‚ u 意図を理解した上で、もっとよくなる改善案などがあれば、
 「こうするともっと良くなると思うんですがどうですか?」とコメントす‚ u あくまで提案する体裁でコメントする。
 採用するかどうかはレビュイーに判断してもらs u 「これは絶対問題あり」っていうものに対しては、
 はっきり理由を提示して「修正してください」と伝える

Slide 12

Slide 12 text

参考図書のご紹介

Slide 13

Slide 13 text

みんなではじめるデザイン批 評 デザインレビューについて、海外の事例を紹介 しながらアプローチを紹介している本。名著。 題材がデザインレビューだけど、コードレ ビューや、プロダクトの機能検討などいろんな 場面で応用できるのでオススメ。 前職ではチームの推薦図書として、新入社員に は必ず読んでくださいと言っていた。

Slide 14

Slide 14 text

Team Geek
 ―Googleのギークたちはい かにしてチームを作るのか エンジニアの間では名著って聞いた。 前職の推薦図書だった。
 HRTの原則の出典元になった本。
 大抵のことはHRTの原則で解決できると思って る。

Slide 15

Slide 15 text

プロダクトのUXはチーム(組織)のUXから

Slide 16

Slide 16 text

Have a nice working, THX!