UI

A collection of 73 posts

UI

デザインシステムの落とし所はどこにある?

寛大姿勢と厳格構造の間 デザインシステム開発における課題はいろいろありますが、いつも迷うのが『落とし所』を見つけることです。デザインシステムは下図のような軸のどこかにプロットされると考えています。コンポーネントやドキュメンテーションがほとんど用意されてない「寛大姿勢」と、様々な要素が細かいところまで決まっている「厳格構造」の 2 つです。 寛大姿勢 表現に自由があり過ぎる サポート体制がない 一貫性がない 改修コストが高い 厳格構造 トップダウン 守るべきルールと捉える人がいる 周りからの反発を受けやすい ユーザーニーズより現存コンポーネントを優先 デザインシステムはいずれかの状態に極度に寄るものではなく、軸のどこかにあります。ただし、間のどこが良いかは組織によって違うので落とし所が難しいわけです。デザイン組織の成熟度はもちろん、何を達成すると次のステップへ進めるのかを長・中・短期それぞれ考慮する必要があります。 変化し続ける落とし所 組織は常に成長・変化するものですから、最初に見つけた落とし所のままデザインシステムを維持・管理すれば良いわけではありません。 2014 年に発表された Material Design は年を重ねるごとに落とし所を変えてきている良い例です。 発表された当初は、どちらかというと厳格構造に寄っていたと思います。

UI

UIデザインのバグを減らすための施策

UIデザインにもあるバグ 今年の WWDC 2019 で印象に残っているセッションのひとつが「Introducing SwiftUI: Building Your First App 」。SwiftUI は開発がよりスマートにできるようになるだけでなく、デザインツールの新しい可能性を示しているように見えました。SwiftUI はとてもエキサイティングですが、個人的に刺さったのが上の写真。改めて意訳した図を作りました。 UI デザインは単に理想型を作れば良いのではなく、様々な状態(ステート, State)を考慮する必要があります。情報量に応じてどう見せるかだけでなく、様々な種類のエラーにどう対応するか考えなければいけません。How to fix a bad user interface で紹介されている UI Stacks のように、少なくとも 5 つのスクリーンデザインが必要になります。 理想型 エラー 情報が少ないとき 読み込み中

UI

ジェネレーティブUIデザインが作り方を変える

デザインツールのもうひとつの未来 「次世代デザインツールはどこへ向かうのか(後編)」で、デザインプロセスはよりチームスポーツのようになると書きました。デザインツールはより開発との連携がしやすくなり、より実装を考慮したデザインがしやすくなるのでは?と仮説しました。しかし、デザインと実装の溝がなくなることだけがデザインツールの未来の姿ではないと思います。 デザインツールにあるもうひとつの可能性が、ジェネレーティブデザイン(generative design)です。 ここでいう『ジェネレーティブ』とは、コンピューターアルゴリズムで何かを生成・構築するもの。ジェネレーティブアートであれば随分昔からあります。例えば Gerg Nees の Computergrafik は、コンピューターアルゴリズムによって作られたグラフィックアートを 1965 年に発表しています。最近だと Processing のようなグラフィックに特化したプログラミング言語が登場したことで、敷居が少しずつ下がってきたと思います。 デザインの世界で注目なのは、図面作成 (CAD) ソフトウェアの AutoCAD を開発している Autodesk の Generative Design

IA

UIの意味付けに情報アーキテクチャは強い味方

Atomic Designは数ある分類方法のひとつ Atomic Design のように UI の『粒度』で分類することがあります。ボタンやフォーム要素のような小さな『分子』。大小様々な要素で構成された『ページ』と呼ばれる大きな集合体。UI を積み木構造のように考えやすくなりますが、Atomic Design 特有の思想であって、特定のアプリケーションの UI に適した分類ではない場合があります。 汎用性をもたせるために、Atoms、Molecules、Organisms、Templates、Pages の 5 段階が作られていますが、web サイトやアプリケーションによっては段階が多すぎます。無理に当てはめようとするあまり、Molecules かOrganisms かを議論するということにもなりかねません。 よくある話でボタンの分類があります。ボタンは Atom と呼べますが、アイコン付きボタンはどうでしょう。 2 つの

UI

良いUIでも悪い体験は作れる

下図は、デジタルカードゲーム「Magic: The Gathering Arena(MTG: Arena)」の画面。現在、βテスト中なので一般公開時には大きく変わる可能性がありますが、良い UI が良いデザインになるとは限らないという例で紹介しています。 カードパックを購入するには、Gems という通貨が必要になります。ゲーム用の通貨を購入してアイテム課金するゲームは他にもたくさんあります。押しやすいボタン。分かりやすいラベル。魅力的なグラフィック。ちょっとしたアニメーションを加えた演出を見ると MTG: Arena は優れた UI デザインと捉えることができます。デジタルカードゲームを楽しみたいユーザーの気持ちを高めるデザインと言えるはずです。 魅力的な表面とは裏腹に、たくさん Gem を購入してもらうための仕掛けが隠されています。例えば 6 パック分のカード(1,200 Gems)を手に入れるために、1,600 Gems 分の課金をします。6

UI

透明かつ自動化するUIデザイン

上図は、Facebook, Instagram, Snapchat をはじめとしたサービスが提供している「ストーリー」でよく見かける動きです。ストーリーはここ 1, 2 年で一気に広まりましたし、毎日観覧している人もいると思います。 UIデザインも成熟期に入ってきて、ベストプラクティスと呼ばれるものが出揃ってきました。タイムラインのUI、ナビゲーションのUI、ギャラリーのUI など、様々なコンポーネントがどのアプリを見ても大して変わらなくなりましたし、そこから大きく外れたものは「使いにくい」と言われる場合もあります。 ストーリー式 UI も他のコンポーネントと同様、似たり寄ったりになってきていますが今までの UI になかった特徴的なところがあります。 操作のための UI が極めて少ない: 従来であればスキップしたり次の動画を見るための操作 UI があったところが、ストーリー式 UI にはそれらがほとんどない。スワイプのようなジェスチャーを使うことを大前提としている。 自動的に次のコンテンツへ移動する: 従来であれば次のコンテンツを見るか見ないか決めることができる UI があったが、ユーザーの意思に関係なく次の動画が再生される。ジェスチャー操作はできるものの、

UI

Sketchから学ぶコンポーネントデザイン

部品から設計することに慣れる デザインツールとして Sketch や Figma を推している理由のひとつにシンボルがあります。Adobe CC ライブラリのアセット管理とは異なり、デザインした部品(コンポーネント)を拡張したり組み合わせることができるのが魅力。様々なスクリーンサイズに耐えられるように作るのはもちろん、デザインを運用していくには、部品からしっかりデザインできるのはこれからのツールでは必須です。 コードが書ける人、コードを書く思考が分かる人であれば、部品から作ってレゴブロックのように積み上げるという Atomic Design 的な考え方は当然と思えるでしょう。なので、デザインシステムを作りましょうという考えに至りますが、画面の全体像から徐々にディテールを作るやり方でデザインしていた人には難しかったりします。いきなり部品から作ることに慣れていないですし、マクロ(画面全体)とミクロ(部品)両方を交互に見ながら設計できるツールを使っているとも限りません。 全体からディテールを作るという進め方の弱点は、UI デザインに必須の一貫性を失いがちになりになるところ。また、ひとつひとつの画面の見た目作りになってしまい、全体像を見失うこともあります。 昨年、何度か Sketch セミナーで講師をした理由は、コンポーネントを積み上げて設計をする能力を身につけなければ、デザインシステムどころではないと感じたからです。Sketch が物足りないところはありますが、

UI

デザインの運用って何ですか?

公開しても終わらない コンテンツマーケティングの文脈でコンテンツの運用という言葉を耳にすると思います。いつ、誰に、何を、どのように配信するかを決めて、複数人で実践していくには運用が欠かせません。新しいコンテンツを作り続けなければいけませんし、現存コンテンツの維持・管理も必要になります。 コンテンツの運用で「公開したらあとは待つのみ」「納品したら終わり」という考えはありません。放置するとたちまち埋もれてしまい、存在していないのと同じになります。また、利用者の趣向・動向に合わせてチューニングをしていかなければ、ますます遠い存在になります。 公開したらデザインの仕事が終わるわけではないという意味でコンテンツの運用と似ていますが、デザインの運用は以下の点を解決することを目的とします。 コンテンツの量に依存した『固い』デザインにしない 基本的なことであれば短時間で実装ができる 誰が触っても最低限の品質が担保できる 一貫性のあるデザインが実装しやすくなる ひとりのスターデザイナーに頼り切らない 必要に応じて変更・改善し続けることができる CMS を導入してコンテンツを運用していくための体制ができていたとしても、デザインがそれに追いついていない場合があります。「こんなことがしたい」という施策に対して、デザイナーがひとつひとつ手作りをしていては商機を逃すこともありますし、人手がいくらあっても足りなくなります。新着情報しか更新できなかったり、特定のデザイナーが動くまで待つという状態は避けなければいけません。 運用という考え方の切り替え 事業会社で働いていたり、内製をしている組織であれば、デザインの運用ができるように日々試行錯誤していると思います。

UI

デザインシステムにおける色の命名ルール

崩れない色名にする 前回「デザインシステムに採用する色を決める5つのルール」を通して、色の名前の付け方や整理の仕方を紹介しました。これを受けてウェブデザイナーの深沢幸治郎さん(@witch_doktor)が「ウェブサイトに使われる色に固有の名前をつけてみる」という記事を書いてくれました。色の命名にまつわる苦労や工夫について読むことができるので、ぜひ参考にしてください。 前回の補足として、デザインシステムにおける色名の付け方の工夫を 3 つ紹介。色の整理をするときの参考にしてください。 色名=変数 色の名前を付けるのに困っている方は、Kromatic がオススメ。カラーパネルのスライダーを動かすか HEX 値を入力するだけで、色名を提示してれます。他にも color-names という 10,000 以上の色名が収録されたライブラリもありますし、Wikipedia にも色名は幾つかあります。 🌈色にユニークな名前を付けると言っても良い名前が思いつかん!という方は「Kromatic」を使ってみてはいかがでしょう。 pic.twitter.com/S6P7k7NT02

UI

デザインシステムに採用する色を決める5つのルール

始めの一歩としての色共有 ひとりのデザイナーに頼らず、チームで運用できる体制を作るためにも デザインシステム は有用なツールです。しかし、様々な UI コンポーネントと決まりごとが揃ったものを作るのは骨が折れる作業です。デザイナー(もしくはエンジニア)が独自で作って「さぁ使いましょう」と公開しても、使ってもらえるとは限りません。また、デザインシステムをどこで共有して、どのように使われるのかも考慮しなければならず、他社の真似事では済まないこともあります。 作る前から課題が山積みでなかなか手が出せないかもしれませんが、何か始めなければゴールに辿り着くことはありません。そんな現場でデザインシステムを作る場合、色から始めることをオススメしています。 色なんて単純なところは出来ていると思う方は多いと思います。デザイナーであればパレットにしてまとめているでしょうし、エンジニアであれば色は変数にして整理しているでしょう。しかし、現実は少し複雑です。 上図はある大企業サイトで使用されているコーポレートカラーらしき色を摘出したものす。HEX値が違うだけでなく、なぜ違う値にしたのか判断が難しいものがあります。恐らく最初は色の統一がされていたと思いますが、運用を続けていくうちに次第に色が増えてしまう場合があります。ドキュメンテーションがされていないまま外注をしてしまうと、新たなカラーバリエーションが増えるリスクも出てきます。 PSD, Sketch ファイルといったデザインファイルを見なければ色の使い方が分からない状態ではエンジニアはどれを使えば良いのか分かりません。デザイナー以外の人がアクセスできる場にルールを記載しておかなければ、数年前のソースコードから色をコピーされて流用される恐れもあります。 デザイナーとエンジニアの連携だけでなく、マーケッターや営業といった他の業種の方に使ってもらえる仕組みも忘れてはならない部分です。作った製品で色が統一されているのに、営業資料は違う色が使われてしまう状況を未然に防ぐことが理想です。

UI

成熟期に入ったUIデザインとデザインシステム

先進的から最適化へ 3年前、Facebook が今までのニュースフィードを完全に変えた「Paper」というアプリをリリースしました。ネイティブコンポーネントが使われていないオリジナルの UI とインタラクション。今までありそうでなかった新しい操作方法を提案していました。Paper をはじめ、様々な実験的なアプリを Creative Labs としてリリースを続けていましたが、2015 年にラボは閉鎖され、その半年後には Paper も配信停止されました。 今でも Things 3 for iOS のように新鮮な UI とインタラクションが生まれる場があるものの、あまり見かけなくなりました。今のアプリ UI デザインは、目新しいものを作るより、今まで培われたノウハウを基に使いやすさ、見やすさを磨き上げるフェイズに来ています。斬新なアニメーションと目新しい形状のメニューを作るより、ガイドラインにある Tab Bar / Bottom Navigation を実装したほうが開発しやすいですし、利用者も迷わず操作ができます。

UI

意外と難しいボタンのお話

ボタン?それともリンク? 昨年からデザインシステムをテーマにしたセミナーやワークショップを何度か開催していますが、ワークショップに参加した方から「ボタンは難しい」という感想をいただくことがあります。ボタンの見た目を作ることも奥深いですが、もっと難しいのが、いつ、どこで、どのように使うかを共有すること。考え始めると「そもそもボタンとは何か?」といった疑問が浮かび上がります。 フォーム要素と一緒にあれば、ボタンだと断言しやすいです。HTML であればマークアップも <button> になりますし、アプリでも iOS であれば UIButton を使えば良いと判断できるはずです。 文章のあとに「今すぐ始める」というラベルが付いた要素があるとしたら、これはボタンと呼べるでしょうか。角丸のような装飾、注目されやすい色が使われているので、ボタンと見なすことができます。見た目はボタンっぽいですが、果たして本当にボタンと呼べるでしょうか。ただ、見た目がボタンになっているだけで、リンクと呼ぶこともできると思います。 Material Designではボタンのような見た目のもの(Raised Button)と、

UI

結局デザインシステムは何なのか

フロントエンドからの影響 昨年開催されたワークショップ「パターンラボ – 柔軟性と拡張性をデザインに取り込む方法」をはじめ、記事やイベントを通して維持・管理ができるデザインついて情報発信しています。CMS が広く普及して以来、コンテンツ配信を長く続けるための仕組み作りが模索されているものの、デザインは発展途上です。早く作る、効率よく作るまで議論されるものの、デザインをどう維持するのか、どうすれば最低限の品質を担保できるかまで発展しないことがあります。 1977 年に建築家クリストファー・アレグザンダーの著書「 Pattern Language 」で、パターンが街作りに柔軟性と拡張性を持たせると説いています。彼に異論を唱える人もいますし、街に個性が失われるという意見にも一理あります。しかし、彼の考え方が今の情報設計(IA)に多大な影響を及ぼしていることは間違いありません。情報や装いに一貫性を持たせることは、作り手の効率化だけでなく、使う人・みている人も学習がしやすくなります。形状、色、インタラクションが毎回違うボタンでは、それがボタンと認知されるまで時間がかかってしまいます。 Web サイトにおける UI パターンをカタログした「デザイニング・インターフェース」は良書ですが、パターンを設計していく上で個人的にインパクトがあったのが

UI

デザインしやすい部品の分け方を考える

Atomic Design の課題 デザインシステムを作っていく際、Atomic Design は非常に参考になる考え方です。Atomic Design は以下の 5 つの要素によって構成されていて、Pages へ近づくほど、より複雑で大きなものになります。 Atom : UI を構成する最小かつ基礎要素。ラベルやボタンなどが含まれる。 Molecules : 2 つ以上の Atom によって構成された小さなグループ。ラベル、インプット、ボタンで構成された検索フィールドはその一例。 Organisms : 2 つ以上の Molecules もしくは Atoms によって構成されており、画面上で独自の枠組みになっていることが多い。 Templates : コンテンツ構造が分かる大きな枠組みで、利用文脈によって分類できるレイアウトになっている。 Pages : テンプレートが実際どのように扱われているか、Atoms から構成された部品が効果的に使われているか分かるもの。 Atomic Design

UI

デザイナーがデザインシステムに参加するための課題と対策

実装寄りの情報だけでは不十分 コンテンツだけでなくデザインも運用していきたいと考えたとき、デザインシステムを作ることが不可欠です。属人性を省きつつ、最低限の品質を担保することが可能なデザインシステムですが、作りさえすれば組織で広まるのかというと、そんなことはありません。 Salesforce の Lightning Design System、MailChimp の Design Patterns をはじめ、自社でデザインシステムを取り入れるためのインスピレーションは幾つか見つけることができますが、フロントエンド寄りになりがちです。早く Web サイトやアプリを実装するためのガイドラインなので当然ではあるものの、これだけではデザイナーがデザインシステムへの参加が難しくなる場合があります。多くの要因は「デザイン」と「コード」にある溝と大きく関わっています。 コードが分からないと参加が難しい デザイナーが作ったものに対してエンジニアがコードに変換してドキュメント化するわけですが、これではデザインシステムと直接的な関わりが持てないので、システムの運用・改善に消極的になる可能性があります。簡易 CMS が導入されていなければ参加の敷居は高くなります。 デザイナーはデザインツールでデザインする コードにまで落とし込まれた文書があっても、デザイナーから見れば遠い存在です。コードをデザインツールに取り込んでデザインできるわけではありませんし、すべてのデザインをコードから始めるには無理があります。日々使うデザインツールとはまったく別の場所にデザインシステムがあるように見えます。 対外向けのドキュメントとして、実装寄りのルールを明確にするためにデザインシステムは有効です。

UI

会話から考える情報設計のコツ

会話はデザインの基盤 2016年は、Facebook Platform や Slack Bot のようなチャットを利用した会話式 UI が話題になりました。人工知能(AI)の話題とも重なって『バズった』UI デザインでしたが注意が必要です。利用者の期待をコントロールしなかったり、情報のインプットとアウトプットの工夫がないと「やっぱり使えない」「会話型でないほうが便利」という結果になります。何でも会話式 UI ではなく、現実的かつ有効な活用例が今後出てくることを期待しています。 『会話』とは、チャットのような見た目のインターフェイスだけを指しているわけではありません。Amazon Echo や、Google Home のように GUI をもたないデバイスでも会話はありますし、できることが少ないとはいえ Siri にしてもそうです。今のデザインにおける会話は、こうした次世代の話題が多いですが、Web サイトやアプリでも根底的なところはコンピューターと人間との会話で成り立っています。利用者が「

UI

AIの進化から学ぶ会話型UIの課題

UIを考える前に本質を探る 人と情報の関係が会話(チャット)のようになることに伴い、コンテンツだけでなく UI デザインも、会話の中でどのように表示すると適切なのか考える必要があります。会話型になる UI デザインについて2年前に記事にしましたが、今は状況が大きく異なります。 自然言語が使えるチャットボット「ELIZA」は 1960年代に開発されました。 Facebook Messenger はボットの開発やコンテンツの最適化ができるプラットフォームを発表していますし、Slack Bots は開発者にとって馴染みの深いものになっています。 また、友人のように振る舞うことができる Xiaoice(微软小冰)も多くの方に利用されるようになりました。Xiaoice は、昨年 WeChat でリリースされて以来、数百万のフォロワーがいる人気ボット。同じ技術が採用されているりんなは、 LINE で楽しむことができます。ボットが友達と呼べる日は遠い未来の話ではありません。 チャットは友人・知人と会話をするためだけでなく、サービス利用の形状になりつつあります。ボットからのアドバイスをもらいながらショッピングができる Fify。今晩の宿泊地が探せる HotelTonight

UI

UIガイドラインから学ぶライティングの基礎

言葉で決まるアプリの印象 2 年前に発表されて以来、細かな更新が続いている Material Design。最近、UI の動きに関するガイドが大幅に改変されたことで、感覚的なところも共有しやすくなってきました。Android アプリにおける UI デザインの基礎を固める上で、Material Design は非常に参考になりますが、このガイドラインは見た目のことばかり書かれているわけではありません。 Material Design の中には「Writing」と呼ばれる言葉遣いに関する項目があります。ボタンのような操作 UI のラベルはもちろん、エラーメッセージや、挨拶文など、アプリに表示されるテキストすべてに関してガイドラインが制定されています。言葉は大事なインターフェイスですから、きちんと項目をつくって紹介してあるのは素晴らしいことです。 以下、「Writing」項目で紹介されているガイドラインの意訳と私見の解説。項目が多く、英語に特化したものもあるので、気になるポイントをピックアップしました。 「You あなた」「My わたし」とは誰なのか明確にする 「あなたのマイアカウント…

UI

小さく考えて積み上げるデザイン思考

体験のグラデーション デジタルは 0 と 1 で構成された世界であることから、すべてを正確に決めることができるように見えます。しかし、実際のところ紙のデザインに比べてはるかに流動的で予測が難しかったりします。グラフィックツールでつくった世界がそのままの形で再現されることはまずありませんし、利用者の環境によって見た目を変わることもあります。 昔からすべてのブラウザで Web サイトの見た目をまったく同じにすることはできないと言われていますし、スクリーンサイズや OS のバージョンが多彩なスマートデバイスでも同様のことがいえます。しかし、見た目を同じにすることはできないからといって、ビジュアルデザインを諦めるという意味ではありません。Web やアプリをはじめとしたデジタルプロダクトのデザインで難しいのは、何をどこまでをデザインによってコントロールするのかを考えることです。 デザインのコントロールをブラウザが ECMAScript や CSS をはじめとした技術をどれくらいサポートしているかといった観点から判断することがあります。しかし、この考え方ではデザインにおける課題の半分しか取り組んでいません。例えば GOV.UK は「Browsers we support and why」という記事で、デザインが行うべきサポートを簡潔に表現しています。 In simple terms

UI

プロトタイプに発生する溝と対処法

完成品になれない溝をどう埋める あたかも完成品に見えてしまうデザインカンプには、様々な暗黙の了解が存在します。グラフィックツールで Web ブラウザ上での見た目を再現しようとしても、実際 HTML / CSS で組まれたデザインの見た目と同じになることはありません。どこまで静止画を作り込んでも、実際の完成品には成り得ない大きな溝が存在します。この溝が大きな誤解に繋がることがあります。 例えばレスポンシブ Web デザインの場合、幾つかの大きさで静止画のデザインを用意したとしても、その間(可変状態)でどうなるか想像するのが難しい場合があります。また、レスポンシブ Web サイトにおける表現は多彩になってきています。要素の順番を Flexbox で変えることもできますし、画像の配置の仕方もより柔軟で表現豊かになってきています。知識や経験がある方であれば静止画では表現されていない「実はこうなる」という部分を踏まえてデザインを見ることができますが、誰でもできることではありません。 見た目は完成品のように見えるデザインカンプも、実は完成品から離れた存在であることは少なくありません。完成品に見えてしまうことによる誤解やリスクのほうが高まる場合があります。 これは Web サイトだけでなくアプリデザインにも同様のことがいえます。スクリーンに直接触れて操作することから、静止画で判断がつかないところがたくさんあります。スマートデバイスの関わり方はパソコン時代に比べて多種多様なので、誰でも分かる操作方法は多くありません。そこで、静止画ではなく操作ができるプロトタイプを作ることが必須になってきたわけですが、

UI

すべてがUIになるVRの世界

先日、報道を VR で楽しむ NYT VR を試してみました。VR はゲームをはじめとしたエンターテイメント性の高い分野で注目されていましたが、 NYT VR はジャーナリズムからのアプローチだったので新鮮でした。これは仮想空間だと分かっていても、次第に世界に没頭してしまい、現実と仮想の境目が曖昧になる感覚は VR 体験ならではです。 スマートウォッチをはじめとしたウェアラブルや IoT の登場によって、従来のような GUI を前提としたインタラクションデザインではなく、No GUI のデザインが注目され始めています。すべてをボタンのような操作 UI で表現するのではなく、音声、触感、行動でインプット・アウトプットすることがありえます。しかし、VR を体験していると、No GUI とは別に、Everything UI という世界もありえると思い始めてきました。Everything UI

UI

大きいスクリーンのタッチデザインを考える

タッチは大前提 発表後、発売を待たずに売れ切れ状態になった Surface Book。ノートパソコン並みの大きさを誇る iPad Pro。それぞれコンセプトが異なる製品ですが、スクリーンサイズが従来のタブレットの域を超えたものが注目されているのは、デスクトップパソコン以外で本格的な作業をしたいというニーズが高まりつつあるからでしょう。 Adobe のコアアプリも Windows 向けにタッチフレンドリーに改良が加えられています。 Windows だけでなく、Linux 製の Gnome はバージョン 3 以来、ジェスチャー操作をサポートしています。GUI も大きめのアイコンや操作 UI が実装されているのも印象的です。 今年 Acer がリリースした DCシリーズ は、Chrome OS をベースにしたデスクトップパソコン。マウスとキーボードで操作はできますが、スクリーンに触れて操作もできます。このモデルは 10 本の指をつかったジェスチャーにも対応していて、大型モニターならではの操作を可能にしています。 従来はスマートフォンとタブレットがタッチデバイスので代名詞でしたが、デスクトップを含め、

UI

スマートウォッチで加速する瞬間の体験デザイン

先日からソニーの SmartWatch 3 を使い始めました。以前から Fitbit のような運動に最適なウェアラブルは使っていましたが、スマートウォッチと呼べるものは初めての使用になります。店頭で触ったり、動画を見るだけでは理解できないことが分かって勉強になります。 今回はスマートウォッチの利用を通して感じた、デザインの課題を 2 点紹介します。 Web != Webブラウザ スマートウォッチのような小さなスクリーンで Web を見るのは非常に困難です。一応、Androidアプリがありますし、Samsung Gear S には Opera mini が実装されているので、Web を見ることができます。しかし、指で画面全体が隠れてしまうほどの小さなスクリーンでは、スマートフォンに最適化されたサイトですら満足に操作したり読むことができません。Apple Watch であれば Web ブラウザすらない状態です。 Web へ繋がる窓口が失われるように見えますが、そんなことはありません。私たちはよく Web と、

UI

2015年以降のUIデザイン展望

消えるハードとソフトの境界線 Apple Watch のドキュメンテーション には、以下のような言葉がデザインコンセプトとして記載されています。 Even the physical border of the Retina display has been considered, resulting in edge-to-edge UI design that effectively renders that border invisible. Thoughtful app design should contribute to this experience of hardware and software feeling indistinguishable. 物理的なオブジェクトとソフトウェアには境界線がなく、UI