Web施策のスピードを上げるためにデザイナーが鍛えること２つ
こんにちは。デザイナーのkenjow @kchil です。現在はレシピサービスのWeb版の改善に取り組んでいます。
Webアプリはネイティブアプリと違い、リリースの際にプラットフォームの審査が無いので、仮説検証のサイクルを早く回すことができます。
現在私が属しているチームはPM（エンジニア）、エンジニア、デザイナーの合計３人ですが、１週間に１施策くらいのペースで進めています。
スピードが重視されるWeb施策ですが、それをこなす中でデザイナーとして鍛えていることについて書こうと思います。
効率をよくするための「考え方」を鍛える
デザインのクオリティを損なわずにスピードを上げるためには、仮説検証のサイクルを効率よくまわす必要があります。
そしてそのためには、効率をよくする「考え方」の癖をつける必要があるように感じます。
自分なりに、効率をよくするための「考え方」について書こうと思います。
①失敗したら次にどうするかを考えておく
成功することに期待はするものの、一方で失敗した時のことを考え、次にどんなアクションをとるべきか考えておくことは大事だと感じます。
もちろん施策を成功に導くため、定性調査は事前にしっかりと行います。ユーザーのインサイトを知ることは施策を成功させるためにとても大事です。しかし、それを分かったからといって一発でユーザーが求めている機能を提供することは本当に難しいです。
なので、数値が悪かった。失敗だ。となったときに立ち止まらないために、ユーザーに提案したい機能のアイディアをいくつもストックしておくと良いです。
例として、以前レシピページの直帰率を下げる施策を行っていた時の流れを紹介します。
まず以下のような仮説を立てました。
ユーザーは、
レシピを見ているときに画面の上に検索窓があれば、
直帰せず再検索できる
そこで、レシピページを一定以上スクロールしたときに検索窓が表示されるようにして、直帰率が下がるかどうかを検証しました。
そして、リリースをする前に、以下のような図を作り、この施策が失敗した（＝直帰率が下がらない）ときのことについて考えました。
事前のユーザーテストにて、レシピページがある程度スクロールされているということについては確信がありました。
また、検索窓がタップされたらサジェストを出すことで、タップさえしてもらえれば遷移してもらえる可能性は高いと考えていました。
なので一番の懸念は「検索窓がタップされない」ことでした。
タップされなかった場合の対応として考えたことは以下の３つです。
①検索窓の場所が悪いため気づかれていない
→検索窓を出す場所を変える
②検索窓の文言が魅力的ではない
→別の文言に変える
③検索窓＝テキスト入力＝面倒くさい
→ワンタップで検索結果に遷移できる導線を出す
①と②については、大きなインパクトは見込めそうにないので、やるとしたら③だと考えていました。
なので、この施策をリリースした直後に、③の機能案に着手しました。
懸念した通り、検索窓のCTRは期待値を下回りましたが、すぐに次の施策を打つことができました。
その施策では、検索窓の施策よりも数値が改善されたため、「ワンタップで遷移させる」という方向性は悪くないということが分かりました。
このように失敗と小さな成功を繰り返しながら、ユーザーが求めている機能に近づけていくよう取り組んでいます。
施策が失敗するとしたらそれはなぜか？その場合はどうすれば良いのか？と常に考えることで、テンポよく次の施策を打つことができると思います。
②小さくジャンプする
デザイナーはアイディアを膨らませるのが得意です。なので、例えばその機能や画面の理想的な状態とは何かを考えた上で、実現可能なアイディアに落とし込んでいくという順番で思考すると思います。
しかし、施策を速く回すことを優先するときは、現状との差分は何なのかについて着目して考え、まず小さなジャンプをした方が手戻りは少なくなります。
例えるとこんなイメージです。
理想像は一旦頭の片隅に置きつつ、今回検証したいことは何なのか？それを検証するためにはどんな差分が必要なのか？と考えながらデザインをします。
迷路の中にいて、目の前にたくさんの分かれ道があるところを想像してみてください。
どの道が正解かは分からないので、１つ選んだ道を少しだけ進んでみます。
いきなり突っ走るのではなく、まず少しだけ進んでみることで、方向性の間違えに気づいた時に、後戻りが容易になります。行き止まりまで突っ走ってしまうと、そこまで走った時間が無駄になってしまうし、後戻りするのも大変ですよね。
サービス開発においても、多くの選択肢がある中で１つずつ検証をしていき、ユーザーが求めていない選択肢を潰していくイメージです。
一気にゴールまでジャンプできたら良いものの、不確実な選択肢を地道に潰していく方が手戻りが少なく、着実にゴールへ向かっていく手応えがつかめると思います。
ただし、理想像をちゃんと頭の片隅に置いておくというところがミソで、最終的にはその理想像に近づけていくようにします。
実装するための「筋肉」を鍛える
やはりデザイナーもフロントエンドのコーディングはできた方が効率が良いです。特にHTML/CSSはデザイナーでも取り組みやすいと思います。
完全に分業する場合は、デザイナーとエンジニアの間で複数回バトンの受け渡しが必要になります。
デザイナーも実装に加わることで、バトンを受け渡しする回数をなるべく減らすことができます。
また、コーディング知識がある程度あれば、大体の実装工数のイメージがついた状態でデザインを提案することができたり、エンジニアと仕様をすり合わせる際スムーズにコミュニケーションをとることができたりするというメリットもあります。
ただし、デザイナーの実装スピードが遅かったり精度が悪かったりすると、結局エンジニアが巻き取らなければならなくなるので、逆に非効率的になってしまいます。
それでは、効率的で精度が良い実装のスキルをどのように習得すれば良いのかというと、それはもう数をこなすべきだと思います。つまり筋トレです。
HTMLとCSSを書く「筋肉」を鍛えましょう。
何千行、何万行も書いてください。
このとき純粋なタイピング速度を上げていくことも大事です。
ところで、実際の筋トレをするときに正しい姿勢で行うことで効果が高まるように、実装するための筋肉もなるべく正しい方向性で鍛えていく方が実用的であると思います。
今回は私が重視している項目について書きます。
①HTML/CSSの仕様を正しく理解する
仕様への理解が曖昧だと、レイアウト崩れなどのバグへの対応に時間がかかったり、そもそもバグを生み出しやすかったりします。
実現方法がよく分からない時にブログなどで公開されているソースコードを参考にするのは良いですが、コピペしてレイアウトが崩れる→それがなぜか分からない、という状態であれば仕様への正しい理解ができていないということになると思います。
Webのドキュメントとしては、MDN Web Docsを読むのがおすすめです。
MDNはブラウザの３ベンダであるMicrosoft, Google, Mozillaが協力して作成しているため、信頼性が高いです。
HTMLやCSSの仕様が分からないときは参考にすると良いと思います。
②Webアプリの仕組みを理解する
ここからはHTML/CSSの話から少し逸れてしまうのですが、HTML/CSSの知識だけでWebアプリの開発に加わろうとすると「この画面がどうやって動いているのか分からない」という壁にぶつかると思います。
大抵の現場ではWebアプリケーションフレームワークを利用していると思うので、自分の現場で利用されているフレームワークへの理解を深めると良いと思います。
例えばRuby on Railsのプロジェクトである場合、基本的にはViewしか触らないとしても、MVCモデル（Model・View・Controllerの構造）まで理解していた方が良いです。
Rails開発の場合、その画面のViewの構造を理解した上でマークアップすることが求められると思います。しかし、Viewの構造を理解するためには、ControllerやModelとのやりとりを理解しなければ、どんな処理が行われているのか結局理解できないという場合が多いです。
また、この構造がわかっていれば、新規でViewを作成する場合にも、デザイナーがルーティングの設定をできるので何かと効率的になります。
Progateという学習サービスは実際にコードを書きながら学べるので、ざっと全体の構造を理解するという点においておすすめです。
蛇足ですが、ifなどの簡単な構文も覚えるとViewの設計がスムーズになります。
③Gitの仕組みを理解する
経験上、実装に取り組むデザイナーが意外と時間を食われるのが、Gitの操作ミスを解決することであるように感じます。
もちろん身近にいるエンジニアに大声で助けを求めても良いと思いますが、ミスをしたら自分で解決できるようにする、そもそもミスをなるべく減らすことができるようにするための心がけは大事だと思います。
コマンドラインでの操作が苦手な場合は、GUIアプリを使うことで操作ミスを減らすこともできると思います。個人的には、裏側でどんなGit操作が行われているかだけでも知っておくことがおすすめです。
おわりに
Webの施策をなるべく速く回すためにデザイナーが鍛えると良いと思うことについて２つ、自分の考えを書きました。
効率をよくするための「考え方」を鍛える
・失敗したら次にどうするかを考えておく
施策が失敗するとしたらそれはなぜか？
その場合はどうすれば良いのか？と常に考える
・小さくジャンプする
今回検証したいことは何なのか？
それを検証するためにはどんな差分が必要なのか？
と最小限の差分について考えながらデザインする
実装するための「筋肉」を鍛える
とにかくHTML/CSSをたくさん書く。そして言語の仕様、フレームワークの仕組みを理解する努力をする
Web開発に携わるデザイナーの方に興味を持っていただけたら嬉しいです。
そして、クックパッドではデザイナーを募集中です🙌
クックパッドのデザイナーはWebに限らず様々な領域で活躍しています。興味を持って頂けたらぜひご連絡ください！
この記事が気に入ったらサポートをしてみませんか？