前回初開催だった、五反田.mobile の第二回はデザインがテーマ。間違って前回の開催場所だったウェルスナビさんに行ってしまい、1セッション目は間に合わなかった。
AIコーディング時代におけるデザインとの連携をどう滑らかにするか？を考えてはいるものの、エンジニアサイドは自発的に様々な工夫をする一方で、デザイン側との接点については手探り感があった。今回そのヒントがいくつか得られて良かった。
パネルディスカッションは、プレゼンター以外の社員さんの参加もあってエピソードが豊富だったし、またプレゼンテーションという粒度外の話もてんこもりで（そういえば、みたいな思い出しもあり）素敵な試みだった。
イベントページ：https://gotanda-mobile.connpass.com/event/382518/
Figmaを使ったAI駆動モバイルアプリ開発
@naoele_dev さん
- よくある失敗例
- レイアウト設計（Auto Layout, Constraints）
- コンポーネント設計（Components, Variant）
- トークン設計（Color, Theme）
- 失敗原因：Figma の設計が曖昧だから
- Frame 名が初期値のまま→意味のある命名がされている
- 手動配置されている、色が直接指定されている；Auto Layout や Variants を使っている
- コンポーネントを使ってない
- レイアウト設計の悪い例、良い例
- 重要なのは、レイヤー構造がコード構造になる（Auto Layout, Constraints）
- 意味のある名前をつける
- → Figma のデザインデータそのままで生成される（クラス名や変数名にも反映される）
- Auto Layout = Stack, Column
- Figma の Constraints: サイズが変わった時に、中のTalkで部品がどの様に振る舞えウカを決める（寄せ方）
- コンポーネント設計の悪い異例、良い例
- 状態ごとに別コンポーネントになっているのは悪い例
- 一つのコンポーネントに Variants が指定されていて、状態管理されている
- UI部品をメインコンポーネント化し、Variants に切り出すと、その差分をAIが理解してくれる
- 絶対ルール
- 数値を直接書かない、Design Token 化する
- AIのためでも、将来の自分たちのためでもある
- Figma は絵を描く場所ではない、恒常を定義する場所
- チェックリスト
- Auto Layout を使っているか
- Frame 名に意味があるか(ListItem みたいな名前になっているだけでも違う)
- Variantsで差分を表現しているか
- Token を参照になっているか
iOSデザインシステムとデザイナーと連携した取り組み
ひなっこ さん
- デザインシステムの定義と構造
- アプリケーションの組み立てに再利用可能なコンポーネントと標準規約の集まり
- まとまりある設計いや表現を保証
- ウェルスナビのデザインシステム
- Figma のデザインシステムと iOS の Design System package が同期
TextStyle、ColorがFigmaと揃っているButton.shortButton()modifier のように定義している
- メリット
- 開発スピードの向上
- デザイナーとの共通言語の確立
- メンテの効率化（仕様変更への柔軟な対応）
- 一貫したユーザー体験を提供
- デアイナー・エンジニア間で発生した課題
- 最新のUIがどの Figma かわかりにくい：QAが古い Figma を見てテストしているケースも
- 最新のUIの更新時に気が付かない：実装漏れのリスク
- 原因：更新連絡が人為的でミス発生
- 解決：Dev Mode の Ready for dev ビュー機能 + Slack通知 によって自動化
- Ready for dev ビューは、Ready for dev となった全てのデザインが1箇所に表示される
- Slack 通知の自動送信で、人為的な連絡漏れを防げる
- デザイナーが対象セクションを Ready for dev に変更
- Slack 通知が飛び、通知のリンクから対象に直接飛べる
Intutive & Exciting UI
Nipper さん
Audience · 五反田モバイル用登壇資料 (公開用) – Figma Slides
- 直感的でワクワクするUI
- 「私たちの現代の頭蓋骨の中には、石器時代の心が住んでいる」
- 3つの意識すること
- 予測可能性
- DO: 画面を見た時に、画面や要素ごとの振る舞いを予測できる
- DONT: 予測できない、予測を裏切る e.g. 下から出てきたポップアップを下にフリックして閉じられない
- 直接操作性
- DO: オブジェクトに直接触れて操作できること
- DONT: 操作するために別のコントローラーを要する（カードのスライド形式なのに進む戻るボタンがある）
- 即応性
- DO:リアルタイムに反応があること
- DONT: 反応がなかったり遅延がある e.g. いいねボタンの表示変更が通信の成否を待つ
- 予測可能性
- 例
- 大量な情報量のオンボーディングを小刻みにタップに応じて提示して離脱を防ぐ
- グリッドUIでバナー系を振るわせるとか、マスの中身をparalaxにして奥行きを表現する
- なぜがんばるのか
- 教えるのではなく、気づくUI
- 教えられたことは結局忘れるが、自分で気づいたこと（アハ体験）は忘れにくい
- スキューモフィズム→フラットのパラダイムチェンジ
- 技術の進化と組み合わさったトレンドの変化
- デバイス性能の変化でスキューモフィズムに頼らずとも階層表現ができる様になった
- Liquid Glassも、技術進化で本質に近づいた
- 入力装置は指だけか？
- Luup＝ハード(車)xアプリx空間
- 空間や物体との位置関係による反応もありうる
- 車両のQRをユーザー操作で読み込んでもらっていた
- → 近づくだけで自動的に接続されて、アプリの中で勝手にステータスが変わるインタラクション
パネルディスカッション
- UIUXや広告デザインで重視していること（見た目・操作性・売上など）
- アルク
- 使いやすさだけでなくビジネスのKPIとのバランスも重視
- スマートバンク
- 見た目機能性よりはユーザーへの知恵強化地
- 潜在的に威欲しがっているものを作るというアプローチ
- ユーザーインタビューも行い、リリースした機能がどう使われているのかを聞いて改善に繋げることもある
- Luup
- UIの中に広告を混ぜることあるが、細長いバナーが嫌い。本当に良い（ユーザーが求めている重要なこと）なら堂々と言えというスタンス
- ドンと出すなら、順番やタイミングが大事
- アルク
- デザインシステムの整備と運用をどうしているか
- ウェルスナビ
- 資産運用のサービスに特化したデザインシステム
- ここ最近複数のプロダクトを作っている、それを見越した拡張性を踏まえたデザインシステム構築をしている
- エンジニア連携、AI活用も踏まえて
- アルク
- 軽量なデザインシステムで十分
- 歴代なデザインは個々のスキルや好みの違いによってデザインの一貫性を保つことが大変
- ルーチンはAIに任せて、デザイナーは体験の本質や美しさの構築に従事すべき
- Luup
- デザインシステムを作ってすぐに守らなくなるタイプ
- 作って運用している状態＝進化していない
- 1回作って運用も大事にしているが、システムの内容がアップデートされたか、Atoms のアップデートは大きくないが、大きい粒度で日々追求できるか、何回劇的なアップデートができているかも同時に見ている
- ウェルスナビ
- エンジニアとのコラボレーション
- アルク
- エンジニアがHIGの輪読会開催、デザインの共通認識を持つ会
- 実装を教えてくれる会の開催
- スマートバンク
- デザインとエンジニアの違いは、Figma とコードどっちを触るか
- デザイナーとエンジニアがフラットにコミュニケーションしている
- アプリ開発者という枠組みの中にデザイナーもエンジニアも存在している
- ウェルスナビ
- コミュニケーションを大事に
- 作るものに対して、目的は何か？の認識合わせ
- アルク
- LLM登場による変化
- アルク
- 素材を見つけてくる時間がAIで素材を作ることで時短
- すべての素材をAIでつくって動画にする
- Luup
- Figma Make
- FIgma デザインからコードに一発変換
- アルク
- アプリ内キャンペーンのクリエイティブの作成
- アルク
- ブランドカラーが同じだと飽きるので定期変更が必要、3月なら春＝ピンク
- Luup
- 移動するサービス、リアルな場にいる人がアプリを使っている、消費行動との相性が良い、実験中
- e.g. 行き先がファミマ→ファミマのクーポン
- タイミングもライド終了後に表示するなど
- 移動するサービス、リアルな場にいる人がアプリを使っている、消費行動との相性が良い、実験中
- アルク