手元のAndroid端末で実装されたデザインを確認する
概要
手元にPixel5があるとき、つよつよAndroidエンジニアに「Figma通り実装したからデザイン確認してね！」って言われたら、UIデザイナーの皆さんはどうしますか？ とりあえずスクリーンショットは撮ったとして、そのPixel5のスクリーンショットをwidth=360dpのアートボードで確認すると、エンジニアが意図したサイズでデザインの確認ができないよっていうことを伝える記事です。
dpの基礎は
Androidはdpとspっていうのをつかってデザインするんだよ、というのを何となく聞いたことがある方は多いかもしれません。 下記の記事を読んで全て理解できた方は、正直これ以降を読む必要はありません....
下記の記事はとても良い記事なので、とてもおすすめです。
計算してみよう
実はMaterial Design内の以下の記事に、今回のケースの計算方法が書いてあります
下記の計算を解くと、適切なpxがわかるという計算式みたいです。
px = dp × (dpi / 160)
160って何だろうと思った方はとても勘が良くて、Androidの標準のピクセル密度（mdpi=160dpi）です。 もしFigmaでAndroidのデザインを作っているときに、360x640のアートボードを使っていれば、それはdpを元にデザインを進めていることになるので、上記の式をまずdpについて解くように変形します。
dp = (160 x px) / dpi
あとは、Pixel5のスクリーンについて必要な情報を調べます。
スクリーンのwidth = 1080px、height = 2340px、ppi（dpiと意味は同じです）は432ppiということが分かりました。
先程変形した計算式に、調べた値を入れて早速widthとheightについて計算してみましょう。
width [dp] = (160 x 1080) / 432 = 400dp
height [dp] = (160 x 2340) / 432 = 866.66666.....dp
heightの方は端数が出てしまいましたが、およそ 400x867dp のアートボードで、つよつよエンジニアが実装したものを確認すれば良いということがわかりました。
Pixel5でデザインを確認するときのありがちなミス
Pixel5のスクリーンサイズ（1080px x 2340px)が、xxhdpi（=480dpi）と勘違いすると、（360dp x 780dp)というキリの良い数字になるのでなんとなくいい感じな気がして、間違いが起きやすいかなぁという気がしています。
Pixel5の本当のdpiは432dpiなので、xxhdpi（=480dpi）（360dp x 780dp）でデザインを確認してはいけません。
デザイナー「なんか意図していたよりフォントが小さかったり、ボタンのサイズが小さかったりするのですが...」
エンジニア「あれ？Figma見て1dpたりともずれないようにキッチリ実装したんだけどなぁ...」
というデザイナーのミスが起きてしまうので気をつけたいところです。
ちなみに...デザインをつくるときは？
デザインをつくるときはwidth=360dpでつくって構いません。width=360dpのデバイスは世の中に多いので良いのと、400dpで作るよりも360dpで作った方が画面幅が狭いときのイメージがつきやすくて良いかなと思います。
Material DesignのApp barのシャドウ濃すぎない？問題
Pixel5を買って、数年ぶりにメイン端末をAndroidにしてみました
Material Designのシャドウ濃すぎない？問題とは
Material DesignはUIデザイナーが聖典とあがめる良ガイドラインです。オブジェクト同士の距離感・シャドウの描画まで丁寧に定義されています。
UIデザイナーにとってはタメになることしか書いていないので、私もことあるごとに読んでいます。
しかし頻繁に使用するApp barsのシャドウの定義に関しては「さすがにこれは濃すぎないか....？？逆にAndroidっぽくなくないか...？」と思いつつ、「俺みたいな末端デザイナーがMaterial Designの厳格な定義を破っていいものだろうか...」などと悩んでなんとなく放置してしまうものの筆頭でした（逆にシャドウかけないデザインを採用しちゃったりする）。
今回、自社のデザインシステムにシャドウもあるApp barも定義したかったので、この際Googleのアプリってどうシャドウを使っているんだろう？というのを調査してみました。
調査結果
実際スクリーンショットをとって横にならべてみました
Material Design の Figma Baseline Design Kitによると、App barにかけるべき4dpのシャドウは下記です。
box-shadow: 0px 4px 5px rgba(0, 0, 0, 0.14), 0px 1px 10px rgba(0, 0, 0, 0.12), 0px 2px 4px rgba(0, 0, 0, 0.2);
目コピーしてみる
プロダクトのデザインシステムを定義するとしても、色やタイポグラフィよりもシャドウは後に定義されることが多い気がするので、ちょっと困ってしまう気がしました。 とりあえずのスタートラインとしてGoogleのアプリのApp barsと同じシャドウを使うというのはアリな気がします。それぞれのApp barのシャドウを目でコピーしてみました（精度80%くらいです）。
Gmail目コピー
box-shadow: 0px 0px 5px rgba(18, 39, 64, 0.2);
Material Designの定義では、2重3重にシャドウが重なっていて、それが実世界と似ていて格好良いのですが、シャドウが薄かったので1重でだいたい似たような感じにできました。 あと黒から少し外れた色相を使っています。
Googleカレンダー目コピー
box-shadow: 0px 4px 4px rgba(0, 0, 0, 0.1), 0px 1px 2px rgba(0, 0, 0, 0.15);
これが今回紹介するシャドウだと一番濃そうです。 あと色相を外していない黒のシャドウっぽいです。
Googleドキュメント目コピー
box-shadow: 0px 1px 8px rgba(38, 53, 71, 0.2), 0px 1px 3px rgba(38, 53, 71, 0.12);
これも黒からは色相を外しています。
まとめ
上の目コピーのシャドウは、精度80%くらいなので一言一句同じにする必要はありませんが、下記の傾向がわかりました。 とりあえずスタートラインとしてコピーして、Androidのデザインをはじめてみるのも良いと思います。
- 実際のGoogleのアプリのApp barに適用されているシャドウは、Material Designの定義より薄め
- シャドウを定義するとき、少し濃い目（今回でいうとGoogleカレンダー、Googleドキュメントくらい）のときは2重にかけると実際のモノのような影のテイストが出る
- 青よりに、影の色相をはずしたりする
- 青寄りのグレースケールを採用しているアプリも多いので、どストレートな黒シャドウだと逆に赤っぽく見えちゃうこともあるからかも。
【UIデザインTips】iOS/Androidのダイアログ の（日本語の）デザイン
経緯
ANDPAD社の超優秀PMに「iOS/Androidのダイアログ、たまにタイトルが無いやつがあったりするので、文章は基本タイトルに書く、に統一しちゃいたいんですが良いですかね？」と聞かれたので（こういう問題提起してもらえるの助かる）ベストプラクティスを言語化してみることにしてみました。
AppleとGoogleのガイドラインを見てみる
iOS Human Interface Guideline内の、ダイアログに関する記載はこちら
Alerts - Views - iOS - Human Interface Guidelines - Apple Developer
Material Design内の、ダイアログに関する記載はこちら
どちらもとっても良いことが書いてあるのですが、決定的なルールというと下記2点が使えそうだなと思いました
私の過去の経験から言っても「アラートに必ずタイトルをつける」ルールにしてしまうと、下記のようなダイアログが出来てしまうことが、稀によくあるので、必ずタイトルを付けるというルールは良くないかなぁと思いました。
架空の機能ですが、下記のように文言を整えるとグッと良く感じられるのではないでしょうか。
文書化して情報を共有しよう
デザイナーが全部のアラートをレビューできればよいのかもしれませんが、開発スピードによってはなかなかそうもいかないこともあるかと思います。自分の場合は、Figmaのテンプレートとなるファイルに下記のような情報共有コンポーネントを作成して、社内に情報共有していこうと考えています。
【UIデザインTips】 iOSで和文フォントだけ小さくなる罠
前置き
iOSの和文フォントが英文より小さくなる罠について、意外とデザイナー側からそれについて触れた記事が見当たらなかったので、ANDPAD社内で勉強会ネタにするとともにブログ記事にしました🤞
何が問題か
iOSのフォントは英文=San Francisco、和文=ヒラギノ角ゴです。
全く同じフォントサイズで英文フォントと和文フォントをレイアウトすると、和文フォントの方が大きく見えてしまうので、和文フォントを少し小さくするのはデザイン界では常識（と言い切ってしまうぞ!!）なのですが、iOSは「そういう組み方をした混植フォントをデザイナーに提供する」わけではなく「OS側でヒラギノ角ゴを縮小して」しまうことがデザイナー側からすると問題です。
↓
具体的には、和文のみでレイアウトされたデザインでは「ただただ文字が1ptくらい小さくなって」しまいます。
（実際には大きいフォントサイズを指定すると和文フォントサイズと英文フォントサイズの差が大きくなっていく。14pt-18pt程度のよくレイアウトする文字サイズだとだいたい1ptくらい和文フォントが小さくなると覚えておくとよいです。ほんまかいな！と思った方は参考記事をご参考に。。）
これが弊社プロダクトANDPADのように和文のみでレイアウトされているプロダクトで行うと、「全部想定していたより1pt小さくなってしまう！！！」「なんかこの文字小さくて読みにくいんですけど！！！」となって（しかも気づくのがだいたい実装終盤）、とっても困ってしまいます。
Figmaでの暫定措置
最近ANDPADにジョインしたスーパーiOSエンジニアから、こういうふうに対応しておくと良いよーとアドバイスいただきました
- デザインシステム上で定義されたフォントサイズがiOS上で実際は何ptで表示されるか調べる
- Figma上では、1つの定義に対して「そのまま（英語用）」と「iOS上の日本語フォントサイズ（日本語用）」の2つを用意して使い分ける（例：Headline1(en)=24pt, Headline1(ja)=23pt みたいな感じになる）
- エンジニアはどちらも同じものとして実装する（例：(en)でも(ja)でも24ptとして実装）
天才かよ！と思いました。和文フォントのみでレイアウトする際は上記の運用で実装とデザインが一致しますね。
英文も混ざるデザインの場合は上記の運用だと英字がヒラギノになる且つ実装されるものより小さくなってしまいます。Figmaで今のところ混植が簡単にはできないので。。
参考記事
- 【iOS】System Fontの和文（日本語）について - Qiita : https://qiita.com/moccow/items/4d0870e81db909a7aabd
- San Francisco フォントを探る - Qiita : https://qiita.com/usagimaru/items/da88c0a8793f23633c28
組織の文章を良くするために、デザイナーが日本語のガイドラインを作った話
インハウスのUXデザイナーとして、日々社外に発信される日本語のクオリティは非常に気を使っています。
UXデザイナーとして日本語に気を使う箇所は、アプリやWebの中だけでなく、ヘルプページやメールでのお知らせなど本当に多岐にわたります。
日本語も英語も校正しているとそれはそれはとにかく時間がかかるので、ある程度組織の人数が多ければ選任のライターがいるべきだと思っているのですが、まだ弊社はそこまで成熟した企業ではないので「ライティングがちょっと上手な人」の善意によってなんとかしているという状況です。
私はUIデザイナーでもありますし、ビジュアルデザインにも注力したい。。日本語ばっか見てられんのじゃー！という気持ちで、社内に日本語の簡単なチェックリストのようなものを作りました。結構社内の評判も良く、公開してからライティングの品質も向上してきたように感じます。公開して同じようなことで悩んでる人に使ってほしいなーと思ってます。
何か日本語の参考書籍を読んで練習するのが一番近道だとはわかっているのですが、社員全員にそれは強制できないので、以下のようなリストを共有するだけでも結構マシになるかな〜と感じているところです。
文章を書くときに気をつけること
ユーザーに向けて対外的に発せられる文章の品質が向上すると良いなと思って書きました。私は文章の専門家ではないので、もっと日本語の上手な方が加筆/修正して頂けると助かります。
ちゃんとした本を読んで練習するのが一番良いと思いますが、そういった時間が取れない方が、顧客に向けた文章を書くときに最低限チェックした方がよいTipsをまとめます。
（何か見つけたら随時追記します）
だいじなこと
- 文章を書くときは、常に文章を届ける相手のことを考える
- 自分が伝えたいことではなく、相手が知りたい情報は何かをよく考える
- 不特定多数の人に情報を伝えるとき、日本語が適切であればあるほど、正しい情報を届けられる人数が100%に近づく
- 適切な日本語が使えない企業は、信頼されない
- 簡潔な日本語を書くのはとても難しいことを意識する。
- ふだん日本語を使っている人は、複雑な表現に慣れているから。
基本（すべての日本語に適用できるルール）
文章は可能な限り短くする
キャンペーンを実施する運びとなりました。
↓
キャンペーンを実施します。
ユビレジのテーブルのうちテーブルエリア設定が行われていないものは、
↓
エリア設定されていないユビレジのテーブルは、
当たり前のことは書かない
本キャンペーン以外でお申し込みをされたお客様は、本キャンペーンの対象外です。
↓
（削除する）
指示/意図が欠落した文章を書かない
※プレミアム以上
↓
※プレミアムプランのユーザーが対象です
「こちらビールになります」はバイト敬語で、間違っています
受付時間は平日10:00〜18:00となります。
↓
受付時間は平日10:00〜18:00です。
ひとつの文でひとつの事柄を説明する
2つの単語をつなげて新しい単語を作らない
特に操作説明の場合、ヘルプページとの整合性がとれなくなるので避ける。
テーブルエリア
↓
テーブルのエリア
正式名称を使う
↓
他社の事柄を記載するときは、できるだけその会社がしている表現を流用する
◯◯（他社名）は予約管理アプリです。
↓
◯◯（他社名）は、予約台帳/顧客台帳サービスです。
ネガティブな事柄は、ポジティブに言い換えられないか検討する
文体は統一する
本日はお知らせが二点ございます。
このたび〜を開始しました。
↓
本日はお知らせが二点あります。
このたび〜を開始しました。
ら抜き言葉は使わない
見れない
↓
見られない
URLのリンクは、リンク先が何か分かった方が良い
「こちら（URLが設定されている）にご連絡ください。」のような表記は「こちら」が何か分かりにくいですし、リンク先のページが消えた場合どうして良いか分からなくなってしまうので、どこに飛ばそうとしているのか明示した方が良いです。
【良い例】
◯◯に関するご不明点については、提供・開発元の株式会社◯◯へお問い合わせください。
・株式会社◯◯（URL: https://△△△/）
取説（ヘルプページ）
取説など技術文書で適用できるルールです。
ひとつの文でひとつの指示をする
あまりにも簡単な操作などは、接続詞でつなげたほうが自然なこともありますが、稀です。
「ユーザーが行う操作」→「アプリケーションが返す結果」を意識すると文章が組み立てやすい
「使いはじめる」をクリックします。
ログインが表示されるので、ログインします。
↓
「使いはじめる」をクリックします。
ログイン画面が表示されます。
ログインすると〜。
画面に表記されていない言葉を使わない
連携設定画面で紐付ける店舗を選択します。
↓
（画面内に紐付けるという単語は登場しない）
↓
連携設定画面で連携する店舗を選択します。
ユーザーがやりたいことを、狭めた表現をしない
予約一覧の中から、ご来店された方のお名前をタップします。
↓
（もしかしたら、今来店した人じゃない予約のステータスを変更したいかもしれない）
↓
予約一覧の中から、トレタの予約ステータスを変更したいお客様をタップします。
取説では敬語は不要
操作の流れを説明させて頂きます。
↓
操作の流れを説明します。
ステータスページ
ステータスページなどで障害情報を記述するときは、完璧に正しい日本語を記述するよりも、1秒でも早く情報を届ける方がユーザーにとって価値があるかもしれません。
日本語を使った条件分岐や、二重否定が間違った意味に捉えられないか、全く違う意味に捉えられると障害情報を出す意味が無いので、気をつけると良いと思います。
iOS Human Interface Guidelines
アラートの文言
アラートのタイトルが一文の場合、句点は使用しない。
本文は一文でも句点を使うっぽい。明記されていないので、情報募集中。
なぜApple TV/Android TVのアプリはメニューを開いた状態で起動するかのデザイン的な考察
tvOS アドベントカレンダーの14日目の記事です。qiita.com
経緯
ちょうど昨年在籍していた会社でめちゃ忙しかったのにアドベントカレンダーの担当にされ、当時やっていたtvOS/Android TVのデザインについての記事を書いたのですが、マニアックな内容だったため全く反響がなかったのですごい無駄無駄に終わった記憶があります。 超勿体無いので、新しく始めた自分のブログに転記して、2017年のアドベントカレンダーに再掲します。
Apple TV/Android TVのアプリは、なぜメニューを開いた状態で起動する？
Apple TV/Android TVともに、標準的なUIでは、メニューを開いた状態で起動します。 これはスマートフォンでは普通ないUIなので、クライアントもしくはプロダクトオーナーに「なんで最初メニュー開いてるの？閉じてよ」と言われがちです。でも結論から言うと『絶対に開いた状態で起動するべきです！！！！１』 （デザインガイドラインに従わない、特殊なUIを除く）
結論: メニューを開いた状態で起動するから、リモコンがスマート
この「メニューを開いた状態で起動するUI」について、色々考えた結果「リモコンのボタン数を減らすためにこうなっているんだな」という結論に至りました。
どうしてもメニューを開かない状態から起動したい！
例えばApple TVのリモコンは基本 - Touch Surface（グリグリできるところ）で選択して、クリックして決定 - MENUボタンを押して戻る というUIで構成されています。 メニューを開かない状態から起動し、メニューが必要なアプリケーションのとき、どんなUIが考えられるでしょうか。
案1: 画面内に[メニュー]ボタンを設置する
セットトップボックス（Apple TVとかAndroid TVみたいなやつのこと、以下STB）の場合、画面をタッチして操作するのではなく、リモコンで操作します。画面内に設置したボタンにフォーカスをあわせるのは、スマートフォンに比べ非常に面倒です。
また、Android TV の Browse View（メニューのことです） や Apple TV の Tab Bars（メニューのことです） は非常に控えめなデザインになっていて、一度見なければどこにあるか分からないようになっています。ここに初見で分かるような「メニュー」をデカデカと載せるのは Android TV/Apple TV のデザイン原理にそぐわないと考えることもできます。
案2: MENUボタンを追加する
今「決定ボタン」と「BACKボタン」しかないリモコンに「MENUボタン」を追加することを検討します。
今までは「決定」「BACK」しか無かったユーザーの選択に、新たな選択肢が1つ増えて、判断に時間がかかります。ユーザー・エクスペリエンスを損ないます。
ほら、最初にメニュー開いとくとめっちゃ便利！
ここでもう一度、純正アプリの遷移をおさらいしてみましょう。 アプリはメニューを開いた状態で起動し、1クリックでメニューを閉じます。 その後は動画コンテンツを選んで、1クリックで再生します。 もう一度 OS ホームに戻るのにも、バック・ボタン/メニュー・ボタンを3クリックするだけでフォーカスを操作する必要はありません。
デザインガイドラインを確認
途中さらっと書きましたが、デザインガイドラインを確認しましょう。
tvOS Human Interface Guidelines （抜粋+意訳）
- デザイン原理（Design principles）
- クリア （Clear）
- 没入感 （Immersive）
- メニュー・ボタン
- メニューボタンを押したら、前のビューに戻ること。
Android TV のデザインガイドライン (抜粋+意訳)
- デザイン原理（Design principles）
- カジュアルに消費（Casual consumption）
- 映画（館？）のような体験 （Cinematic experience）
- インタラクションは軽く（Lightweight interaction）
- バック・ボタン
- バックボタンを押したら、前のビューに戻ること。
どちらのデザインガイドラインも、主張しないUI、インタラクションを求めているので、バックボタンとは別の「メニューボタン」は求められていなさそうですね。
結論
Apple TVもAndroid TVも、デザインシステムは非常によく考えられている。
（が、情報があまりにも少ない）
Adobe MAX 2017 行ってきた
11月28日にAdobe MAX 2018に行ってきました。 行ってきたセッションは以下の通り。
- KEYNOTE
- スマホにおけるリッチ表現最前線。Yahoo!JAPANの最新の広告事例など。（Lunch Time Session）
- ベテランほど知らずに損してるPhotoshop [MAX Special]
- 宇多田ヒカルの言葉 〜ファンとの新しいコミュニケーションのとり方〜
- デザインに役立つ！世界的コンセプトアーティストのマル秘Photoshopテクニック
- 未来のUIを探る 〜SF映画モニターグラフィックスの作り方〜
普段テック系？のデザイナーの情報を入れていると、やれ「ビジネスドメインのうんたらかんたら〜」とか「情報設計が〜」「ユーザー体験の導線が〜」みたいな小難しいことを考えがち、というかそれが仕事なんですが、広告的なグラフィックデザインや写真もターゲットにしたイベントということもあり「グダグダ言ってないで格好良けりゃいいんだよ！」みたいな勢いを感じて非常に刺激になりました。 実際社内に1〜2人程度しかデザイナーが居ない場合「俺はUIデザイナーだ」「UXデザイナーだ」とか宣言しても、CIから広告からなんでもできた方が良いので、ビジュアル重視のイベントにもガンガン参加したいと意識が変わりました。昨年は行けなかったけど来年からも毎年行きたい。
協賛企業のデザイナー向けのマニアックな広告を、25mのスクリーンで見るだけで良かったですね。Webでも見れるAdobeのやつだとこの辺。
[連載] Illustrator 30_30 | Adobe Blog
🏆MAX Challengeグランプリ発表🏆
— アドビ クリエイティブ クラウド #AdobeMAX (@creativecloudjp) 2017年11月28日
グラフィック部門：「MAX SUSHI(マックス スシ）」
アニメーション部門：「Spectrum（スペクトラム）」
Adobe Stock部門：「Gacha Sweets（ガチャ・スウィーツ）」
たくさんのご応募ありがとうございました！https://t.co/O0h5NXAabK #maxjapan pic.twitter.com/EfnqHtGg9x
セッションの中では、「デザインに役立つ！世界的コンセプトアーティストのマル秘Photoshopテクニック」というINEI 富安さんのセッションが抜群に素晴らしかったです。これだけ見るだけでも良かった。
30分勝負で、INEIさんがやっているコンセプトアートっぽい絵をPhotoshopでライブドローイングするという一大エンターテイメントショーだったのですが、普段UIデザインばかりで絵を描かない私にとっては、それはそれは魔法のようでした。しかもツールとしてのPhotoshopはある程度知っているだけに、余計に不思議なんですよね。。同じツールでもスキルの差だけでこんなすげーことができるのかという。。 INEI 富安さんも、デザイナーが多くていつもと違って良かった...という旨のツイートをされていたので、その辺タイトルはデザイナーを釣るためだったのかも笑
いつものINEI公開セミナーはCG関係の方やConcept Artに興味がある方がほとんどですが「Adobe Max Japan 2017」のセッションはデザインのお仕事をされてる方が多かったので、いつも以上に新鮮な気持ちでプレゼンできました。ご覧いただいた方々、どうもありがとうございます。INEI富安 #maxjapan #INEI
— INEI Inc（陰翳） (@INEIInc) 2017年12月1日
先日行われました「Adobe Max Japan 2017」がYouTubeで配信中！ https://t.co/dFUEs27deA なんと9:57:18の長丁場です。
— INEI Inc（陰翳） (@INEIInc) 2017年11月29日
なお、INEI富安によるセッション「デザインに役立つ！世界的コンセプトアーティストのマル秘Photoshopテクニック」は 5:46:30 からです。どうぞお楽しみ下さい。
他にもSonyミュージックのマーケティングの方の、手法がUXデザイナーと全く同じだ！と思ってみたり。
UIデザインに必要なツールは、業務でキャッチアップしているのであまりセッション見る必要ないなぁというのと、タイトルだけでは内容がさっぱり分からないので登壇者をググってセッションを決めておくのは必須だなと思いました。
来年も行こう！
