UIデザイナー｜プロダクト開発 ボタンを直しても なぜか迷われるUI。 それを 「デザインの問題」で終わらせず、 思考・前提・組織のズレとして言語化します。 PdM / デザイナー / エンジニア向け。
東京
Joined September 2009
- Tweets4.6K
- Following2K
- Followers2.5K
- Likes15.2K
Pinned Tweet
UIレビューで
「分かりにくいですね」
↓
「じゃあ説明を足しましょう」
この改善、
だいたい逆効果です。
「分かりにくいUI」は、だいたいUIデザインのせいじゃない｜アオキタカユキ / iCARE UI Designer @dorisukeone note.com/dorisukeone/n/n017f…
外部の3Dモデルを読み込まず、数式だけで頂点をリアルタイムに変形させ、質感と反発を作る。
three.jsは重いアセットに頼らなくても、パラメータのチューニング次第で驚くほど生々しい「手ざわり」を表現できます。
note.com/dorisukeone/n/n33d9…
スクイーズって、汚れるのイヤじゃないですか。でも触りたい。
なので、ブラウザでさわれるスクイーズを作りました。
押して、つまんで、伸ばせる。形は9種類、トッピングや袋も選べます。
PCならカメラに手をかざして、手でもさわれます🖐
squeeze-three.vercel.app/
#スクイーズ #threejs
下流ほど直すコストは膨らむ。だから上流で食い止めよう。よく聞く話です。
でも要件の穴は、画面にしてはじめて見えることが多い。
UIデザインは、要件の穴にいちばん早く気づく場所なのだと思います。
note.com/dorisukeone/n/n6489…
日本の入力フォームが長いのは、デザインが遅れているからではないかもしれない。
「型を守れば責められない」という江戸時代からの証文文化が、いまの画面にも残っている気がします。
note.com/dorisukeone/n/n8300…
漏えい事故は、6割強が不正アクセス。
でも個人情報保護委員会への報告まで広げると、件数で多いのは誤送付や誤交付といった人の取り違えでした。
ニュースになるのは大きな攻撃。日々起きているのは人の間違い。
だから、UIデザインでできるセキュリティを考えてみました。
note.com/dorisukeone/n/n2268…
これまで、説明を作るのは送り手の仕事でした。
でも受け手がそれぞれAIを持っているなら、
同じ情報から、自分向けの説明を各自で作れます。
説明は、送り手が作るものから、受け手が作るものになっていく。
note.com/dorisukeone/n/n866c…
機能Aもよくできている。機能Bも単体なら使いやすい。
なのに、AからBに移るところで、ユーザーが止まる。
これはUIの細部の問題というより、
プロダクトが「タテに強くて、ヨコに弱い」状態なんだと思います。
note.com/dorisukeone/n/nd6c2…
アオキタカユキ｜UIで思考のズレを言語化 retweeted
「なんかここ、気持ち悪い」。直せるのに、次の画面でまた止まる。
強い根拠とは、その画面を離れても持っていける根拠でした。エンジニアと組んで違和感を掘り下げた記録です。
「なんとなく気持ち悪いUIデザイン」を、説明できる練習をはじめます @dorisukeone
note.com/dorisukeone/n/n0b09…
AIのために警鐘を鳴らしたいとおもいます
ClaudeCodeを「優秀な新人」と呼ぶのをやめて、ポケモンと呼ぶことにしました｜アオキタカユキ｜UIで思考のズレを言語化 @dorisukeone note.com/dorisukeone/n/nb070…
これは納得、腑に落ちる。
少人数で大きな価値を生む「超増幅型組織」のつくり方｜こぎそ @kgsi note.com/kgsi/n/ne91b9fc46cc…
アオキタカユキ｜UIで思考のズレを言語化 retweeted
デザインシステムのレビュー59項目を、AIと人間でどう配分するか試した記録。
見えてきたのは「一度決めれば終わる仕事」と「決めても残る仕事」の線引き。自動化率100%を目指さない理由が分かります。
UIデザインは、Claude Codeに任せるほど仕事が減らない @dorisukeone
note.com/dorisukeone/n/n8f5e…
昔の叩き台は、粗かったです。
粗いから、見た人が「ここ、どうなってるの」と口を挟めました。
粗さが、疑いの入口になっていた気がしています。
いまの初稿は、最初から整っています。
整っているものに「なんか引っかかる」と言うには、言う側に体力が要ります。
note.com/dorisukeone/n/n4344…
見た目の指摘を掘っていくと、根拠には段があると気づきました。
・好み
・原則
・優先順位
・一貫性
・UXへの影響
好みはその場で消えます。行動まで言えていると、別の機能にも持っていけます。
note.com/dorisukeone/n/n0b09…
たしかになー、Xではあたかも民意かのようにD案があふれてるのは違和感。やっぱAIの責任のないデザインって魅力感じないかなーとおもう。推しがあったので投票しました、発表楽しみ！
作れるけど、作るべきではない｜サタケシュンスケ（イラストレーター） @satakeshunsuke note.com/shunsukesatake/n/nc…
「ケバブじゃなくて、ハンバーガーにしようか。」が、noteの「今日の注目記事」に選ばれてた🍔
UIの「あの右上の点々」「下から出てくるやつ」には、ちゃんと名前があります。
名前を知ると、AIにも人にも説明しやすくなる。そんな話です。
note.com/dorisukeone/n/n70bd…
アオキタカユキ｜UIで思考のズレを言語化 retweeted
へー！
知らない世界の話ってやっぱり最高におもしろい！
看護師界では、トンボって言葉は採血に使う針の話なのと似てる。
「ケバブじゃなくて、ハンバーガーにしようか。」UIデザインの話しです。｜アオキタカユキ｜UIで思考のズレを言語化 @dorisukeone note.com/dorisukeone/n/n70bd…
UIの名前を調べるとお腹がすきますよね。
「ケバブじゃなくて、ハンバーガーにしようか。」UIデザインの話しです。｜アオキタカユキ｜UIで思考のズレを言語化 @dorisukeone note.com/dorisukeone/n/n70bd…
デザインレビューをAIと人でどう分けるか悩みます。「機械か人か」の二択にすると真ん中が全部「人」に寄る。実際は「決めれば終わる9項目」と「ずっと残る15項目」に割れていて、AIを強くしても後者は減らない。
@dorisukeone note.com/dorisukeone/n/n8f5e…
正直、整えてから出そうとして遅くなることがあります。
開発チームのnoteに、まず動くコードを書く話が出てきます。
動かないとレビューができないから、そこへ素早く到達する。
出す速さより、判断できる状態に早く持っていく、という順番かなと。
note.com/devteamicare/n/nb16…
「基本はまず、動くコードです」
動くものがないと、機能や価値のレビューができない。
だからそこへ素早く到達して、マージするまでに良いコードへ直していく。
14年で6社を経験して、今年iCAREに入ったエンジニアさんのインタビューです。
note.com/devteamicare/n/nb16…