コードとUIの裏側にあるもの @たこやきUX Vol.2
10分程度らしい
発表の目的
最近のプロジェクトで得た知見を纏めておきたい
最近書いた散らばったノートをいったん一箇所に纏める、という感じの内容
理想的にはフィードバックが得られると嬉しい
自己紹介
mrsekut.icon
mrsekut (まる)
tryangle株式会社
型が好きです
コメント、感想、指摘、補足があれば、(いつでも)このスライドに直接書き込んでくださいmrsekut.icon
-------------------------↑0:30
最近やったプロジェクトの概要
業務委託で、店舗スタッフが使う業務システムを作った
業務に詳しい相手方へのヒアリングも密に行った
業務フローの策定、システムの設計、UIの設計、実装まで幅広く行った
プロジェクトマネージャとして携わった
今日は、サービス設計をする中で得た気付きを話しますmrsekut.icon
「良いコード」と「良いUI」の共通項がたくさんある
コードレベルのtipsの共通項
「凝集度」というのがある
ざっくりいうと、違い概念は近い場所に書くと良いよ、というもの
良いモジュールといった文脈で出てきがち
https://gyazo.com/73b3896fbf202bf386d6ee37f8a2c1d1
「Package by Feature」というディレクトリの設計手法がある
ざっくりいうと、機能ごとにディレクトリを纏めるというもの
❌ Components/, UI/, models/
「技術駆動パッケージング」と呼ばれたりする
⭕ Posts/, Comments/
https://gyazo.com/88e01bd4db0689cf74fd1a67584a6219
上記の話は、スコープが違うだけで近い話をしている
「デザインの基本4原則」にも近いものがある
近接, 整列, 対比, 反復とかいうやつ
近接
関係性の近い要素を近づけて配置する
プログラムでもUI/UXでも同じことを言っている
というパターンは他にも無数にある
対象は両方とも人間
ユーザか開発者かの違いしか無い
応用すれば、
UI/UXの知見を得た時に、それをプログラムに転用できるということ
逆もまた然り
-------------------------↑~2:45
共通するんだね、というのはわかった
次からが本題
目標
良いUIを作りたい
良いコードを読み書きしたい
UIもコードも、表層に過ぎないのでは
と最近感じたmrsekut.icon
作る対象を形にする前の、抽象的な状態での
見方、構造、解釈がまず大事で、
あとはそれを最も上手く表現できるように具現化する
サービスやコードが、パッ見でよくわからん、になる問題
表層自体が悪い、というのは少ない気がしている
-------------------------↑~4:30
どうすれば、わかりづらいインターフェースを作らずに済むか
以下のステップが必要なのでは
①「良い抽象を発見すれば、わかりづらさを解消できる」と信じること
---
②分かりづらくなっていることを感知すること
③良い抽象を考えて発見すること
④それを正しく表現すること
実際、全部難しいmrsekut.icon
①「良い抽象を発見すれば、わかりづらさを解消できる」と信じること
心から信じるだけmrsekut.icon
気づけ無い課題は改善のしようがない
パッとコードを読んですぐに意味がわかるか
記憶を消した後に再読してみる
プロトタイプをチームメンバーに見せて即座に理解されるか
これが伝わらなければそこそこやばい
背景を知っているのにも関わらず伝わらない
etc.
③良い抽象を考えて発見すること
ここはまだまだ言語化ができてない、もっと細分化できそうmrsekut.icon
論理的な分析も飛躍した発想も必要そう
既存の概念と調和するかどうかも考慮が必要
ただ付け足すだけの、短期的に楽な修正をしない
④それを正しく表現すること
②が上手くいくまで改善し続けるということ
適切なインターフェースで表現する
良いUIや良いコードの知見の見せ場となる
実際難しい
タスクを寝かして長く考える
新たな要望に対して爆速で対応しない
誰でもできる
現実は、どこかで妥協することになる🤔
-------------------------↑~7:30
上記の話を拡げる
前提から変えていくために、役割の横断が必要そう
こういう切り口の分断を横断していく
フロントエンドエンジニア/バックエンドエンジニア
エンジニア/デザイナ
今日の話はここだったmrsekut.icon
開発チーム/経営チーム
どんどん首を突っ込んでいく
上流のふわふわからから考える
開発側に落ちてきた時点で、構造が歪になっている可能性がある
UI上にごちゃごちゃ詳細を書かないとユーザに伝わらない、という状況がおかしい
その裏にあるビジネス上のルールが複雑だから仕方ない、としない
上流が決めたルールを、開発者がただ表現する、のではない
要件策定に首を突っ込んでいく必要がある
ルール自体のUXを我々が構造化する
-------------------------↑~9:00
更に拡げる
抽象の伝達は、たぶんあらゆるコミュニケーションで役に立つ
サービス開発
サービス開発者→ユーザ
コード
コードの書き手→コードの読み手
新しいことの学習
学習対象→自分
育成とか育児とかもたぶんそう
知らんけどmrsekut.icon
その辺の知見を深めたい
この考えに至ってから半年も経ってないので手探り状態mrsekut.icon
知ってたら教えてほしい
ヒントがありそうと思っている分野
Haskell
形式手法, Alloy, 様相論理
状態の抽象化なので
圏論
抽象の学問なので
UX周り
認知ナンチャラ学
まとめ
コードやUIの裏側にある概念が重要そう
役割を横断するという気概が必要そう
メンタルモデル関連で面白い人物や書籍があれば知りたい