「アクティブ数が増えない」 「コンバージョン率が悪い」 「リリースした〇〇が使われない」 「オンボーディングがうまくできていない」 デジタルプロダクトの改善する際に取り上げられるフレーズたち。これらのフレーズが多くの会話やアイデア発散の起点となることがあります。しかし、これらはすべて課題ではなく、症状です。「アクティブ数が増えない」のは、開発陣の行動やステークホルダーの判断の結果（症状）であり、課題そのものではありません。真の課題を特定するためには、「なぜアクティブ数が増えなかったのか？」という深掘りする問いかけが必要となります。 単に「アクティブ数が増えない」という症状だけを見て対策を立てるのは、医者が具体的な診断をせずに治療を始めるのと似ています。このアプローチで一時的な改善が見られることもあるかもしれませんが、真の原因を突き止めずにアプローチをすると、その結果から学ぶことは少ないでし

デザインの推進は簡単なことではありません。デザインの定義が広がり過ぎてしまったことで人によって解釈や期待が異なりますし、デザイナーの責任範囲も様々です。あれこれ挑戦を続けても物事は思うように早く進まないですし、時には悲観的になるかもしれません。 物事が進むのが遅いのはごく自然なことです。何か実践するだけであれば、一週間あればできるかもしれません。ただ、そこで作ろうとしている価値を組織全体に浸透させるのは時間がかかります。組織が大きければ数年かかることもあります。長期戦だからこそ難しいですし、諦めてしまうこともありますが、うまく進める方法もあります。 中核へいくほど進みが緩やかですが、インパクトが大きくなります手段の目的化にある罠例えば UI ライブラリを作ることを目標とします。とりあえず作ることはできるかもしれませんが、作業コストに担う効果は得ることができるでしょうか。 UI ライブラリを

良い感じに、が通じなくなるとき小さな組織だと肩書きや世間の定義に囚われることなく、周りとコミュニケーションをとりながら働くシーンがよくあります。そんな現場で働くデザイナーはプロダクトのあり方を深堀するフェイズから入ることが多いですし、実装にまで携わる方もいます。分野を絞ってスキルを伸ばしたい方には向いていませんが、課題発見と解決のための活動に第一線で関わりたいのであれば最高の仕事環境だと思います。 人数が少ないうちは良い感じの間合いをとってコラボレーションする働き方がしやすいです。誰が何をしているかも見えやすいですし、少し話すだけ物事が決まって進んでいきます。 こうした小さな規模で出来ていたことが、人数が増えると次第に難しくなっていきます。組織が大きくなると、様々な領域が重なる兼任業から、特定領域のスキルと経験が豊富な専門業が増えていきます。 小規模で出来ていた『空気を読んで良い感じにコラ

リモートのプレゼンは進化がない かれこれ 15 年近くKeynoteを使ったプレゼンを続けています。10名以下の小規模のものから 1,000 人を超える大規模のものまで数多くのプレゼンをしてきました。自分にとって Keynote はプレゼンに欠かせない大事なツールですが、最近は利用する機会がかなり減りました。 凝ったアニメーションを作るのも楽しみのひとつ ありがたいことに今でもイベントで登壇する機会がありますが、今年は COVID-19 の影響もあって、ほぼすべてのイベントがフルリモートに切り替わりました。イベントの形が大きく変わったと共に自分のプレゼンスタイルも少しずつ変わり、結果的に Keynote が活躍するタイミングがなくなりました。 国内外のリモートイベントに幾つか参加して感じたのが、リアル会場からリモートに変わったにも関わらず、プレゼンのスタイルが以前からまったく変わっていない

受け身のままでは後退する 長くキャリアを積んだとしても、時に「デザインとは？」という疑問が頭に浮かび上がります。様々な定義がありますし、文脈や状況に応じて正解といえるデザインが変わると思います。私が携わっている web サイトやアプリケーション（デジタルプロダクト）という観点からデザインを捉えると「デザインは交渉すること」だと思っています。 ユーザーの立場・視点を想像して、質の高いプロダクトをデザインしたいと考えるのは良いですが、その想いをそのまま周りに伝えても理解されません。デザイナーが考える「質」は、その職域に携わる人独特の視点であることは多々ありますし、技術制約やビジネスゴールを考慮するとコスト高という場合もあります。 だから諦めましょう … ではないからこそ交渉する必要があります。デザイナーは与えられた課題に対して解決案を作るといった受け身の仕事になりやすいことから、指示・注文・提

今までも何度か デザインシステム に関する記事を書いてきましたが、手段や考え方が中心でした。今回はプロセスに注目して、代表的な課題を図にしてみました。すべてのケースに当てはまるわけではないですが、参考にしてください。 大まかな進め方 「デザインシステムを作りました！」とドカンと発表したほうがインパクトがあるように見えますが、苦労したわりには誰も使わないものになる可能性が高いです。実際はデザインシステムの中にあるものを小さく切り出して少しずつ変えていくことになります。 正攻法であればデザイン原則から始めたほうが良いと思っていますが、組織としてどうあるべきかといった根本的なところが明文化されていないのであれば、そこからスタートしたほうが良いでしょう。デザイン原則があったほうがデザインの議論がしやすくなるので早期にもっておきたいですが、1 日でも早く成果を出したいのであれば、まず色からはじめてみ