Yasuhisa Hasegawa - Yasuhisa Hasegawa (Page 29)

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

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

デザインシステム

要素名クイズから始めるUIの呼び名合わせ

あなただったら画面にある大きなテキストを何と呼びますか？強調されたテキストが 2 つあるとしたら、それぞれどう名付けますか？「見出し」「タイトル」「ヘッダー」など様々な呼び名が考えられます。HTMLの知識があると、「H1, H2」と呼ぶかもしれません。これらは情報の意味を表す言葉ですが、「テキスト（大）」のように見た目で呼ぶこともできます。見た目を呼び名にするのは良くないという意見もあると思いますが、汎用性のある実装にするのに適している場合があります。よく目にする要素でも言葉が合っていないことがよくあります。役職・背景が異なれば呼び名が違うだけでなく、そもそも何と呼べば良いか分からない要素も少なくありません。 2年前から実施している「パターンラボ」というワークショップ [https://yasuhisa.com/could/article/ui-pattern-workshop/] では、一貫性のない UI を視覚化するだけでなく、言葉も一致していないことを体験してもらっています。ワークショップでは、デザイナー、フロントエンドエンジニア、ディレクターといった違う役

ビジネス

ビジネスを考慮したデザイン提案をする前に決めておきたいこと

改善の意味を合わせる Web サイトやアプリの運用・改善は欠かすことができないプロセス。一発で正解を出すのが難しいのはもちろん、市場やユーザーの動きも常に変わるので、それに合わせた対応が必要になります。改善をすることに異論を唱える人はいないと思いますが、何に対して改善したいと言っているのか異なる場合があります。例えば web サイトやアプリの制作者（デザイナーや開発者）であれば、UI や使い勝手を改善したいと考えるはずです。しかしマーケターであれば流入チャンネルを改善したいと考えるかもしれないですし、経営幹部であれば収益を上げるための施策を改善と呼ぶかもしれません。それぞれが考える改善をしていても最大の効果は得られませんし、ひとつに集中しなければ効果が見えてこない場合があります。また、ビジネスインパクト（利益になるかどうか）を考えたとき、私たちがやりたい UI 改善による効果が極めて小さい場合があります。押しやすいボタンにデザインを変えたとしても、ユーザー数が少ない中では望める効果を得るのは難しいです。それより、ユーザー数を増やすための施策にデザイナーが参加するほうがビ

プロセス

デザインをスケールさせるためのツール選び

なぜスケールすべきなのかよく多くの改善、より早い提案・対応が求められている今日。エンジニアは昔から大規模化して動くための施策と実践を続けていますが、デザイナーは大規模化の歴史がないといっても過言ではありません。エンジニアのように確固したワークフローの構築が難しいというのもありますが、デザインは『個人プレー』で作るものというニュアンスが強かったという背景もあると思います。しかし、いつまでも個人に依存したデザインをしていると、新しい施策や改善がひとりのデザイナーの動き次第になります。もちろん、それでも運用可能な環境はありますが、増え続けるビジネスサイドの要望に対応するために、ひとりでデザインを続けるのは困難です。ひとつひとつ対応してるときは、「分かりやすい一貫性のあるデザインを作ろう」と思って取り組んでいたとしても、全体を振り返ると実はそうではないということはあります。ではどうやってデザインをスケールさせていくのかというと、国内外問わず手探りの状態です。人事からマネージメントまで様々な課題がありますし、最適なチーム構成も組織によって異なります。Spotify は Squad

デザインシステム

デザインシステムの最初の一歩として原則を作る理由

デザイナーはもちろん、プロダクトマネージャーや開発者も巻き込んで原則を作ることがありますが、作って終わりということはありません。

UX

調査を当たり前にするための第一歩

調査という行為は日常では当たり前車や家など高い買い物をするとき、値段や見た目だけで買うことはないと思います。専門家や信頼できる知人に相談することがありますし、書籍やインターネットで情報収集することもあります。買う前に調査するのも「失敗したくない」「自分にとって最良なものが欲しい」という欲求があるからでしょう。値段が高いのであればなおさらです。購入前の調査は車や家のような高い買い物だけではありません。食事、書籍、服など数千円のものでも調査をすることがあります。インターネットのおかげで情報と近くなったことから、あらゆることが調査しやすくなったかもしれません。高い買い物であれば調査は必ずするといっても過言ではありませんが、web サイトやアプリ開発になるとそうでもなかったりします。高い買い物をしているにも関わらず調査をしないところが今もありますし、定量調査はするものの、ユーザーの声を聞くという定性調査までできていないところがあります。日常であれば数千円の買い物でも調査することがあるにも関わらず、数百万以上かかる web サイトでは調査をしないというのも不思議な話です。身

ツール

次世代デザインツールはどこへ向かうのか　後編

* 次世代デザインツールはどこへ向かうのか　前編 [http://www.yasuhisa.com/could/article/nextgen-design-tools/] * 次世代デザインツールはどこへ向かうのか　中編 [http://www.yasuhisa.com/could/article/nextgen-design-tools-2/] デザインをスケールさせていくデザインツールの現在と未来を考えたとき、デザインシステム [http://www.yasuhisa.com/could/article/what-is-design-system/] の存在は無視できません。今のデザインツールはデザインシステムの作成・運用に最適化するための機能実装がされています。 * 一貫性のあるデザインの作りやすさ * コンポーネント（部品）として捉えた UI の管理 * 複数人のデザイナーによるプロダクトデザインの運用 * コードへの書き出しなどエンジニアとの連携ひとりのデザイナーに頼るのではなく、組織でデザインを運用していくためにデザインシステムのニー

UI

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

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

ツール

次世代デザインツールはどこへ向かうのか　中編

実装を考えながら作れなかった従来のツール 6年前になりますが、 web のデザインは枠のない世界である [http://www.yasuhisa.com/could/article/wd101-no-edge/] と説明したことがあります。様々なスクリーンサイズのことを考慮して作らなければならないと頭で分かっていても、デザインツールでそれを実現するのが困難でした。10年以上大きな変化がなかったデザインツールに対して、実装側はどんどん進化し続けていました。Web だとフロントエンド技術とワークフローに大きな進展がありましたし、ネイティブアプリも　1　年おきに OS と周りの開発環境がアップグレードしています。開発は目まぐるしいスピードで変化しているのに対して、デザイン環境は大きく変わっていなかったことが、今私たちが抱えているデザインと開発の溝の根源ではないかと考えています。2010年代はデザインツールの革命期 [http://www.yasuhisa.com/could/article/design-tools-revolution/] と呼んでも良いくらい様々なデザインツール