Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エンジニア的アプリデザイン思考法
Search
HiroYUKI Seto
April 20, 2018
Programming
0
1.1k
エンジニア的アプリデザイン思考法
2018/4/20
Kyoto.LT 第20回 「エンジニアによるデザイン」
HiroYUKI Seto
April 20, 2018
Tweet
Share
More Decks by HiroYUKI Seto
See All by HiroYUKI Seto
Androidアプリの 安全なリファクタリングを行うパターン集
seto_hi
2
4.9k
UI TestやVisual Regression Testを コスパ良くやる
seto_hi
3
1.8k
事業支援というお仕事
seto_hi
0
400
MDCの内部実装から学ぶ 表現力の高いViewの作り方
seto_hi
5
1.7k
CoordinatorLayoutのBehaviorを使い倒す
seto_hi
1
360
Jetpack Compose
seto_hi
2
730
UI改善に繋がるエンジニアの立ち回り
seto_hi
2
4.6k
MDCのButtonのCorner Family
seto_hi
1
160
MDCのBottomAppBarのShadowの実現方法
seto_hi
0
930
Other Decks in Programming
See All in Programming
盆栽転じて家具となる / Bonsai and Furnitures
aereal
0
1.9k
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
6
1.4k
Jaspr Dart Web Framework 박제창 @Devfest 2024
itsmedreamwalker
0
150
最近のVS Codeで気になるニュース 2025/01
74th
1
100
AWSのLambdaで PHPを動かす選択肢
rinchoku
2
390
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
1k
rails newと同時に型を書く
aki19035vc
5
710
PHPとAPI Platformで作る本格的なWeb APIアプリケーション(入門編) / phpcon 2024 Intro to API Platform
ttskch
0
390
HTML/CSS超絶浅い説明
yuki0329
0
190
ドメインイベント増えすぎ問題
h0r15h0
2
570
watsonx.ai Dojo #6 継続的なAIアプリ開発と展開
oniak3ibm
PRO
0
170
Swiftコンパイラ超入門+async関数の仕組み
shiz
0
180
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
327
24k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Thoughts on Productivity
jonyablonski
68
4.4k
The Language of Interfaces
destraynor
155
24k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
98
18k
jQuery: Nuts, Bolts and Bling
dougneiner
62
7.6k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
173
51k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Statistics for Hackers
jakevdp
797
220k
Scaling GitHub
holman
459
140k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
3
240
Transcript
エンジニア的 アプリデザイン 思考法 Kyoto.LT 第20回 株式会社ノハナ 瀬戸優之 @seto_hi
自己紹介 • 瀬戸優之 Seto HiroYUKI @seto_hi • Androidエンジニア & アプリデザイン
• 株式会社ノハナ ◦ 一組でも多くの家族に笑顔を届ける ◦ 絶賛採用中(東京勤務) • Material Design大好き • 好きなAPIはCanvas#saveとViewGroup#layout
エンジニア的 アプリデザイン 思考法
最低限の、 外れでない アプリデザインの 思考法
前準備 アプリの構成を考える
アプリの構成 • (ここはあまりエンジニア的でない) • アプリでやりたいことを書き出す • やりたいこと毎に画面を作る ◦ 各画面でやりたいことは1つだけ ◦
次以降のステップでそれを実現する画面を作る • 破綻するようなら使いやすい方に振っていく
レベル 1 パターンマッチング
パターンマッチング • 初手 • 初心者もやりやすい • 「やりたいこと」が近いデザインを参考にする • 間違っていることもあるが、初手としては十分 ◦
後で変えていけばいい
参考データ • 素のAndroidの設定画面 ◦ 新しいOSが正 • Googleのアプリ ◦ たまに奇抜 •
Material Designのガイドライン ◦ シンプルなので色づけしやすい • 各社のアプリはほどほどに ◦ 各社なりの思考や事情があるため
レベル 2 ガイドラインから コンポーネントを持ってくる
ガイドライン • 「やりたいこと」に合いそうな Viewコンポーネントを探す ◦ ガイドライン総当たり探索 • ガイドラインの説明を読み、 本当に合っているを確認する
レベル 2.5 自分でコンポーネントを作る
レベル 3 ルール化
ルール化 • ガイドラインの情報整理ができている段階 • 自分なりのルールを作る ◦ ex: 一番重要なものはFAB ◦ ex:
メニューがN個以上なら隠す • ルールに従ってUIを作っていく
レベル 4 フローチャート化
フローチャート化 • ルールを発展させ、フローチャートを作る ◦ 秘伝のタレ • 超高速にUIが作れるようになる • 同じ操作感の画面が増えるとユーザー負荷も減る
もう一歩 使いやすくする
1. 要素を絞る
要素を絞る • やりたいことを詰め込むと機能が増えがち • 要素が多いとユーザーが迷子になる • 必要なものだけ表示する • そこまで必要でないものの扱い ◦
デフォルトを変えることで不要になる? ◦ 隠す ▪ ActionMenu, BottomSheet ▪ ×操作手順が増える ◦ 要素を消す際はデータを見て慎重に!
2. 強弱をつける
強弱をつける • 色 • 重要なものはAccentColorにする ◦ Primary : Base :
Accent = 2 : 7 : 1 ◦ AccentColorは各画面で1つくらいで十分 • コントラストをしっかりと取る ◦ ガイドラインに従う
強弱をつける • 大きさ • 重要なものは大きく 重要でないものは小さく ◦ ジャンプ率を意識 • ガイドラインに従う
「重要なこと」
重要なこと • 開発側が重要だと思うこと • ユーザーがやりたいこと • ユーザーの行動はねじ曲げられない ◦ 不評を買うだけ ◦
ユーザーの思考までねじ曲げてはいけない • ユーザーのやりたいことで メインの動線を作る
やらない方がいいこと
やらない方がいいこと • 説明やチュートリアルを大量につける ◦ 要素が多すぎて逆にユーザーが迷子になる ◦ すべてに説明がアプリは僅か ◦ 画面の流れや構成が間違っている? •
過度な自動化 ◦ 自己帰属感がない自動化はしない ◦ 勝手に進むと理解ができない ▪ 「何もしてないのにバグる」 ◦ ユーザーが何も学べない
更によくするために
更によくするために • 良いUIに触れる ◦ 何が良いUIかを知る ◦ 知らない知識は出てこない • エモいUIを目指す ◦
芸術方面に手を出してみる ◦ 気持ちの動かし方を知る ▪ GooglePlay→多彩な色でわくわく感 ▪ Gmail→シンプルな色でタスクに集中
更によくするために • アプリ全体を俯瞰してバランス調節 ◦ 色合い、UI、アニメーション ◦ 1画面で最適化しないほうがよいこともある • 触る、触る、触る、触る、触る、触る、触る、触る... ◦
開発者が気になるところはユーザーも気になる ◦ 微調整してすぐ試せるのはエンジニアの特権 ◦ 理論よりも使い勝手 ▪ 使い勝手の裏にある理論を学ぶ
以上