デザイナーのためのモバイルアプリデザイン基礎知識 2017年07月11日

| トラックバック(0)

2017年07月11日 デザイナーのためのモバイルアプリデザイン基礎知識


ちゃちゃきさんとフジタさんがやっている
「情報設計視覚化研究会」にてモバイルアプリのデザインに関するセミナーがあったので、一応UIに触れるものとして参加してきました。


デザイナーのためのモバイルアプリデザイン基礎知識
<山本麻美さん>


P7110171

▼自己紹介
 →一番有名なのはトレタのアプリ
 
▼視覚表現
 →AIや PSでデザインしてきた。

▼操作性
 →SketchやAdobe XD

▼これまでに相談を受けた失敗例
 ・見た目とても綺麗なんだけど、アプリとしては使いづらい。
 ・AndroidのアプリなのにiPhoneアプリだ・・・
 ・標準のUI部品をことごとく無視している。
 ・視覚的に凝りすぎてて実装困難。
 ・無理矢理マテリアルデザイン(もどき)

 →そうか!
  「見るもの」のデザインテクニックを磨いてきたけれど、
  「使うもの」のデザインにしないといけないのか!

 

▼使うデザイン

 例 使う#01
   LINE

 例:使う#02
   写真

 例:使う#03
   翻訳

 例:使う#04
   Adobe カンプ

 例:使う#05
   Googleマップ

▼iOS

 事例:Snapchat
   →使い方がわからない

 事例:Instagram
  →代替機能を用意している。

▼データや投稿がない場合は?
 →からっぽだよーと伝えるとともにそのあとの行動もUIとして提供する

▼iOSの基礎知識
 →まずはiOS Human Interface Guidelinesをちゃんと読む

 ・リソースもダウンロードできる
  https://developer.apple.com/design/resources/

▼iOSの基本的な画面構成
 バー
 ビュー
 コントロール
 一時ビュー

▼レイアウト
 縦だけに対応するだけでなく横向きにしたときにも使えるようにしたほうがいい。
  →欧米だと横向きでキータッチしている場合もある。

▼iOSハンバーガーメニュー
 そういったコンポーネントはありません
 タブバーを使いましょう。(ただし5個くらいしか入りません)

▼Android
 まずはMaterial Designを読む

 Z軸といった考え方がある。
  →階層が決まっている

 実際のデザインだとタブが一番上。

 マテリアルアイコン
  →WebやiOSアプリで使ってもいい。
   (ただし山本さんは使わない)

 ナビゲーションドロワー
  →メニューアイコンは無理やりつけなくていいんです。
   Youtubeはボトムナビゲーションを使っている。
   
 ボトムナビゲーション
  →5つ以上はドロワーを使う。
   2つの時はタブを使う。
  
 タブ
  →ナビゲーションではない。カテゴリを絞り込んでいくように使い

 FABの誤用例
  →否定的なことには使わない。
   その画面の主要なアクションに使う

 iOSには標準部品がある
  →Gmailはオリジナルで実装している

▼エンジニアにデザインツールを触らせない
 
 UIエンジニアが知りたいこと
  ・各要素の位置関係
  ・サイズ
  ・画像名
  ・カラーコード
  ・スクロールする箇所と固定箇所
  ・アニメーションのタイミング
  ・etc.

 デザイナーの言い分
  ・Spec票を作るのすごく大変
  ・大変なのにその予算がない
  ・デザイン通りに実装されない
  ・そもそも何をどう伝えれば?
  ・etc.

▼Zeplinを使う

▼動きを伝える
 Framerを使う(Origamiもあるよ)


iOSアプリ開発者のホンネ
<関根元和さん>


▼自己紹介
 エムロジック株式会社 取締役
 トレタ

▼開発者のホンネ
 ほんとはね
  ・デザインに忠実に実装したい
  ・1ptも異なることなく!
  ・デザイナの思い描いたアプリを!
  ・でもね・・・

 いいたいことがあるんだよ
  ・ほんとにその指示あってます?
  ・ボタン小さすぎません?
  ・画面ごとに微妙にレイアウト違いません?
  ・同じような灰色何鬼微妙にRGB値違いません?

▼10の倍数
 コンピューターの世界は8の倍数がよく使われる

▼8pt, 16pt
 デザイン上絶対に10ptでなくてはいけない!というわけでないなら、
 8pt、16ptでマージン指定してもらえると嬉しいです。

▼スタイルを決める
 marginS = 4pt,
 marginM = 8pt
 marginLK = 16pt

 フォントサイズについても同様

▼"666666と666665のカラーコード
 

▼パレットを作ろう
 ・色に名前をつけてパレットを作りましょう
 ・UIの色はRGB値ではなくパレットの色名で指定
 ・パレットはコードでも実装

▼HIGは必読

▼20ptのボタン押せますか?
 →HIGだと44pt×44ptにしましょう。とかいてある。

▼ボタンについての考え方
 ・絵としてのボタンと、UIとしてのボタンは別に考える
 ・20×20の画像があったとして、
  そこに上下左右12の余白をつけてボタンとしての画像を作成
 
▼同じレイアウトなのに微妙に違う
 ・左にアイコンがあって、右に名前があって、その下に発言があって、
  というレイアウトがあちこちの画面にある。よくありますよね。
 ・なのに、なぜか画面ごとに微妙にサイズやマージンが違う

▼モジュール化しましょう。
 ・UIデザインを共通化してモジュール化する
 ・モジュールを組み合わせて画面を作る
 ・デザインするのも楽だし、実装も楽
 ・みんなが得する
 
▼他のアプリではできてますよ?
 
▼よく見るページめくりUI
 でも、標準じゃないんです。

▼あのアプリと同じで

▼ふんわり仕様では実装できない。
 HTMLとは違う
 
▼行数問題
 ・表示するテキストは1行なのか、それとも複数行なのか
 ・行数によってレイアウトは変化するのか
 ・そのあたりの指示が曖昧だと困ってしまう
 
▼画面サイズの違い
 iPhoneの機種によって画面サイズが違います。

▼文字の省略問題
 ・文字が入りきらない場合
 ・語尾を省略するのか・・・
 ・途中で省略するのか
 ・入る大きさまでフォントサイズを小さくするのか
 
▼良きにはからってくれない

▼まとめ
 開発に関する知識
 ・コードが書けるようになれ!とは言いません
 ・UI部品の正確な名前
 ・どのようにUIが出来上がるのかの大まかな知識
 ・HIG読んだらかなりフォローできるはず!

 こだわりポイントは明確に
 ・そのポイント数、フォントサイズ、色
  それは絶対のこだわりですか?
  それとも、なんとなく決めたものですか?
  こだわらなくて良いポイントであればその旨伝えて欲しい

 コミュニケーション重要
 ・「簡単にできるだろう」は危険
 ・簡単そうに見えて実装が大変ということも
 ・デザイン決定時に開発者も交えてミーティングを
 ・もちろん開発者もデザイナーのワークフローは理解しておきたい

▼質問
 デザインのバージョンアップで問題になる時ある?
  →モジュール化しておくといい。

 OSのバージョンがあがったときどうしている
  →未来のものはしょうがない。

 iPhone5でデザインしているが、iOSのバージョンのいつまでサポートすればいいのか、
 →基本はひとつ前のバージョンまで。
  しばらくiPhone5は残る


なぜ様々なUIデザインツールが出てきているのか
<長谷川恭久さん>


▼最近のデザインツールの傾向
 →デザイナーの表現力を高める
       ↓

  周りと連携を強める

▼デザイナーとエンジニアの思考の違い
 デザイナーは大きなところから細かいところを作る
 エンジニアは小さいとこから大きなものにしていく。

▼どうしているのか
 画面から部品を切り出す
  →デザイナー的に楽なやりかた
   再利用が考慮されていない
   UIをどう組み合わせて良いのか分かり難い
   下手したら結局全部やり直しという場合も

▼考え方を合わせるアプローチは?
 
▼部品から画面を組み立てる
 ひとりのデザイナーに依存しない
 拡張性と柔軟性が考慮されたUI
 迅速な対応がしやすくなる
 デザイナーの発想転換が必要
  →デザインツールでできるようになっている。

▼Material design
 読もう

▼使いやすい!
 - 体験から学習する
 - 過去の経験を活かす

 カスタムインターフェース
 ブランド
 プラットフォーム
 
▼ブランド
 例:netfrix

▼部品から画面を組み立てる
 タイポグラフィ
 色
 形状
 影
 間隔・リズム
 アニメーション
 
 →Craftでカラーライブラリを共有するようにしている。

▼アイコンデザイン

▼部品をデザインする
 再利用できるUIデザイン
 スクリーンサイズの変化に対応できる
 UIの構造化

▼ボタン
 背景、枠線、余白、書体

▼部品をデザインする
 要素を切り分けながらルールを考える
 リサイズをしながらデザインする
 超柔軟にするのが最適解ではない

▼部品?の行き来を繰り返す
 基本的なUIは部品から始める
 画面でのバランスを見ながら部品を増やす
 部品を改善するスキルとワークフロー

▼今後のデザインツールの条件
 デザインの仕組みが作れる
 開発者との連携がしやすい
 部品を使って素早く画面設計ができる
 チームで部品の共有ができる

  →Sketchを勧めている理由

P7110176

あー、ガイドライン読まないとなー
 



トラックバック(0)

トラックバックURL: http://www.hokorin.com/mt/mt-tb.cgi/946

月別 アーカイブ