Tagged

プロセス

A collection of 71 posts

プロセス

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

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

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

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

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

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