Tagged

プロセス

A collection of 69 posts

プロセス

Q&A 成果物に合わせた説明の仕方が知りたい

> インハウスで3人ほどの少人数のデザイン部門にいますが、周りの知識レベルがバラバラで、デザイン批評をするのが難しいです。 また、途中成果物(ワイヤーフレーム、デザインカンプなど)がそもそもどういう目的で作られるものかも理解されていない状態です。 伝えやすくするためのコツや手段があれば知りたいです。 匿名 プロセスを進めるために手段がある 「デザインカンプを作らないと分かってもらえない」というのは昔からある制作者の悩み。デザインカンプは漠然としたビジュアルの印象を共有するためであれば良い途中成果物ですが、コンテンツの検討やインタラクションなど不得意分野もあります。 デザインカンプを作ったデザイナーは、それを通して何を共有して決めたいか頭の中でイメージしていますが、見ている側は下図のような様々な課題を一気に見せられているようなものです。 デザインといっても解決している課題は様々です。 いきなりデザインカンプを作ることの危険性は単に制作コストがかかるだけはありません。高いファシリーテション能力がないと、話が様々な方向へ広がってしまいます。ビジュアルの刺激が強いことから、本当

コンテンツ

ラベルデザインから読み解くコンテンツ設計の課題

色やタイポグラフィだけでなく、言葉でプロダクトの雰囲気が決まることがあります。早期からダミー文字を避けて [https://yasuhisa.com/could/article/lorenipsum-isnot-good/] コンテンツをデザインするべきですが、簡単に作れるものではありません。 良い事例を探そうとすると必ず辿り着くのが Mailchimp の Voice and Tone [https://styleguide.mailchimp.com/voice-and-tone/] 。「Mailchimp らしさ」が明文化されているだけでなく、ライティングの基礎も書かれている優良コンテンツです。しかし、英語の壁がありますし、文化の違いもあるのでそのまま真似するのは困難です。 そこで今回はラベルのライティングというミクロの視点と、出来上がるまでのプロセスを把握するマクロの視点からコンテンツの課題と対策を紹介します。 ラベルデザインにある3つの特徴 UI のラベルをどのようにデザインすれば良いのかを考える上で、 Airbnb [https://www.airbnb.jp/]

ビジネス

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

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

プロセス

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

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

プロセス

デザインの過程を見せるのはスキルアップの近道になる理由

結果だけでなく過程も 途中経過を見せることはデザインへの誤解が生じると考える人はいるかもしれません。また、途中経過は『企業秘密』だから見せるべきではないと考える人もいるでしょう。そもそも恥ずかしいから見せたくない人も少なくありません。自分も最初は恥ずかしかったですし、そもそも途中経過は見せる必要ないと思っていたほうでした。 しかし、今は途中経過を見せなければ良いデザインが生まれないと考えるようになりました。手描きのものから、インタラクションがあるものまで様々な形状を作っては見せています。仕事現場だけでなく、 Twitter [https://twitter.com/yhassy] や Instagram [https://www.instagram.com/yhassy/] のような場でも見せることもありますし、このブログにしてもデザインにおける途中経過を文章として表していることが多いです。 完成されたモノをどう作るかというノウハウも重要ですが、デザインという『よく分からないもの』が生まれるまでのプロセスを見せるほうに興味があります。 > Anyone who influe

デザインシステム

デザインシステムが作り出す明文化への道

明文化をテーマにしていた2016年 今年の初めデザイン SDK のようなものが欲しい [http://www.yasuhisa.com/could/article/design-sdk/] という記事を書きました。開発者から提案されているフロントエンド寄りのスタイルガイド [http://www.yasuhisa.com/could/article/starting-webdesign-system/] はコードの品質管理と、見た目の再現性を高める上で有効な手段です。しかし、これだとコードを理解していることがスタイルガイドの利用・関与の大前提になります。すべてのデザインがコードから始まるとは限らないですし、デザイナーであれば Sketch や Photoshop といった日々使うツールを活用して最低限の品質を保つ手段が必要になります。 共通言語を作っていく。 これは文字通り言葉だけでなく、UI を始めた視覚的な部分など、今まで好みや感覚で済ませていたこともきちんと言葉にすることも指しています。デザイン批評 [http://www.yasuhisa.com/could/articl

プロセス

プロセスなんて下手でも我流でも気にしない

デザインプロセスの儀式化 随分昔の話になりますが、茶道(表千家)をしばらく学んでいた頃があります。日本伝統をひとつでも知っておきたかったというのもありますし、茶道にある特有の礼儀に興味があったのが理由です。茶道は、使う道具はもちろん、たてかた、飲み方にも決まったルール・プロセスがあります。できあがった茶の味だけでなく、茶がたてられる過程も楽しむのが茶道の魅力であり奥深さです。 完成品だけでなく、過程を重んじるのは茶道だけの話ではありません。日本に昔からある芸道だけでなく、「寿司を食べる」といった食の世界にもあります。美味しく寿司をいただくには、決まった順序がありますし、正しいとされる礼儀もあります。プロセスというより、一種の『儀式』と呼ぶことができるでしょう。 過程(プロセス)を重んじ、儀式のように進めるという行為は日本文化だけでなく、他国でもあります。プロセスには言葉として表現するのが難しい魅力があるものの、無心で信じるのは良くありません。今日のデザインにおいて、どの環境、どのプロジェクトでも適応できる完全無欠のプロセスは存在しません。しかし、それでも私たちは確実性や安心を求

デザイン

ありがちなプロトタイプ失敗パターン

次へ進むための『何か』 プロトタイプは今日の設計プロセスにおいて必須の役割を果たしている … といった論調を見かけることがあります。特にアプリの場合、Web サイト制作以上に開発者とデザイナーの密接なコミュニケーションが必要になるので、単なる静止画データの受け渡しでは不十分です。そこで「プロトタイプを作りましょう」となるわけですが、他のツールと同様、手法を取り入れただけで制作における課題が解決されることはごくまれです。 プロトタイプは、紙で作るもの [http://www.yasuhisa.com/could/article/reintroduction-to-paper-prototype/]から、 Principle [http://principleformac.com/] のようなアプリケーションを使ってインタラクションを加えるものまであります。プロトタイプの完成度も制作スピードもツールによってまちまちなので、どのように扱えば良いのか迷う方も少なくありません。また、新しいツールを採用してプロトタイプ(のようなもの)を作ってみたけど、以前と状況が変わらないどころか、大変に

デザイン

デザインドキュメンテーションにある制作と共有の課題

ドキュメンテーションのための3つの課題 Web サイトデザインはもちろん、アプリデザインでも画面ではなく部品から始める [http://www.yasuhisa.com/could/article/wd101-start-with-components/] ほうが有効です。画面ごとで制作していくと、いつの間にか一貫性を失うことがありますし、様々なスクリーンサイズに対応するためのルールを後付けにすると、結局またやり直しになってしまうこともあります。 では、インターフェイスを一度見直してスタイルガイド(パターンライブラリ)を作り始めれば良いのかというと、それほど単純は話ではありません。私の中で以下の 3 つの課題があると考えています。 * 人とコトの課題 – これはワークショップを通して指摘しましたが [http://www.yasuhisa.com/could/article/ui-pattern-workshop/] 、ステークホルダーによって優先順位が違えば、指している要素の呼び名が違うことがあります。制作側視点だけで作ると思わぬ誤解が発生する可能性があります。

プロセス

なぜ自信をもってデザインを説明するべきなのか

コラボレーションは難しい コラボレーションは今日のデザインプロセスにおいて必須です。様々な分野の専門家たちが集まるからこそ、より良い製品へと進化していきます。専門家だからこそ出せるインプットによって、最適な解決策が見つかる … はずなのですが、実際そうはいかないことがあります。立場が違えば、物事の捉え方も違います。それぞれが置かれている状況によって、意見が分かれることがあります。意見が一致すればコラボレーションとしての相乗効果が生まれますが、そうでないときは、不平や妥協する人が出てくるでしょうし、最悪の場合は製品の利用体験を損なうものを実装してしまうこともあります。 コラボレーションは響きの良い言葉ですが、一筋縄にはいきません。意見が合わないとき、私たちはよく自己防衛の姿勢になりがちです。「これは違う」と言われると、反射的に「そんなことはない」と言うことがありますが、こうしたやりとりがコラボレーションの歯車を狂わしていきます。自分を守ること、相手の意見を変えることが先決になり、肝心の課題解決の話し合いではなくなっていきます。こうなると以下の 3 パターンで話に決着が付いていきます