Vol.499
Troy Hunt: Passkeys for Normal People Jump to heading
普通の人のためのパスキー入門 Jump to heading
Troy氏は、Mailchimpのフィッシング被害をきっかけに、従来のOTPによる2FAの限界を指摘し、より安全な「パスキー(passkeys)」を紹介。パスキーはデバイスに保存される公開鍵ベースの認証方式で、フィッシングに強く、操作も簡単。iCloudやGoogleなどと同期でき、UXも良好。まだ普及途中だが、Microsoftなど大手も採用を進めており、将来の標準になる可能性が高いと締めくくっている。
Factors of a good interface designer Jump to heading
優れたインターフェースデザイナーの要素 Jump to heading
Anthony氏は、良いインターフェースデザイナーに求められる資質を体系的に整理。以下の7つのカテゴリを挙げている。
- 知識(パターン・トレンド理解、学習意欲)
- 経験(良い判断、スタイル柔軟性)
- 創造性(独創性と反復探求)
- 品質志向(細部へのこだわりとテスト重視)
- 技術スキル(タイポグラフィ・レイアウト・ツール熟練)
- 広い視野(プロダクト・システム理解、アクセシビリティ意識)
- コミュニケーション力(設計意図の明示、協働推進)
Taste is a dead end; what you should have is a point of view Jump to heading
必要なのは視点 Jump to heading
Pavel氏は、デザインで「自分のセンスだ」と主張するだけではUXや製品において価値を創出できないと警鐘を鳴らしている。現在、多くのプロダクトが「スピード重視」で機能を乱発し、本質的な問題解決には届いていない。UXやPMチームが機能追加の流れに流されず、本来あるべき「目的(Purpose)」を軸とした意思決定を行い、そこに基づく「視点(Point of View)」を持つことが重要だと主張する。単なる見た目の美学ではなく、ユーザー調査と明確な目的から価値ある設計を導くべきというメッセージを伝えている。
There and back again a system thinkers tale Jump to heading
Beau氏は、自身のデザイナーとしてのキャリアを、プロダクトデザインとデザインシステム構築の間を何度も行き来した経験を語る。最初はIBMでのノウハウ不足から「エクスペリエンスガイド」を作り始め、システム化の苦労と恩恵、両方を体験。その過程で得た「製品チームとシステムチームは目指すべきゴールが同じ」「相互理解と共感が成功の鍵」「変化に対応できる柔軟な構造が重要」といった教訓を共有している。システム設計とプロダクト設計は別物ではなく、互いに補完し合う関係だと締め括っている。
If you dont know where to start research start with PACT | by Pavel Samsonov | Bootcamp | Medium Jump to heading
ユーザー調査の初手として「PACT」モデルを推奨している。PACT とは People(誰が使うのか)、Activities(どんな活動をしているのか)、Contexts(どのような環境・状況か)、Techniques(どの手法を使うか)の4要素を示すフレームワーク。これにより、調査の対象や手段が明確になり、設計の初期段階で何をすべきか迅速に把握可能。特に、新しいドメインで何から手を付ければいいかわからない場合に、PACT は強力な指針を提供する。
In Brief Jump to heading
Makers Knowledge: 深い理解には実際に「つくる」体験が不可欠であり、理論だけでは得られない知識が得られる
So Long Figma. Thanks for Everything. | by Jon Daiello | May 2025 | Medium: Figmaを手放した未来では、AI活用とコーディングプロトタイプにより、ピクセル重視から問題解決重視の本質的なデザインに移行すると
Minimal CSS-only blurry image placeholders: JavaScript不要、CSSだけで軽量で実用的なモダンLQIPが可能
Done with components: 各チームが独自コンポーネントを孤立的に作る状況は設計システムとの整合性を失い、相互コミュニケーションが必要
Documentation done right: A developers guide - The GitHub Blog: 開発者向け文書は「まず結論、その後詳細」の逆ピラミッド構造で書くべきと推奨する