※この記事は、Speee Advent Calendar 9日目の記事です。 昨日の記事はこちら
- はじめまして
- 前職時代は、、、
- Speeeにジョインして、、、
- クライアントワーク(受託)とSpeeeのインハウスデザイナーのちがい
- フェーズによって、デザイナーの役割も変わるんだ！
- 目的によって、デザイナーに求めらるもの
- まとめ
- あとがき
はじめまして
こんにちは！Speee デザイナーのさとこです。(デザイナー歴17年の40歳になりました😄)
今日は、プロダクトのフェーズやプロジェクトによって、デザイナーの役割って違うんだなーーー、というお話をしたいと思います。
組織を横断してデザインに携わってきた経験から、
- クライアントワーク(受託)とSpeeeのインハウスデザイナーのちがい
- プロダクトのフェーズによるちがい
という色々な「ちがい」を整理しながらお話できたらなーと思っています。
まずは、簡単に自己紹介をします。
前職時代は、、、
- 事業会社のSI部門でお客様のWebサイトやサービス開発のデザイン、Webディレクション、プロジェクトマネジメントをやってたよ
- 新規開発がメインだったよ
- クライアントワーク歴13年
Speeeにジョインして、、、
- PDCAをまわしてプロダクトをグロースさせていきたい！という熱い思いで3年前にジョイン
- 現在は、組織を横断してtoC,toBのプロジェクトに関わっているよ
普段の業務：チームのアウトプット
- 新規プロダクト開発
- インバウンド営業改善
- 広告運用
- 自社集客(SEO)
- メディア運営
- まれに販促物製作
クライアントワーク(受託)とSpeeeのインハウスデザイナーのちがい
大きな違いは、2つだと思います。
・ 1つ目は、開発形式の違い
・ 2つ目は、デザイナーの役割の幅の違い
事業会社のSI部門で受託でWEBサイトの構築やアプリ制作をやっていた私の個人の主観で書いています。2021年の今とは違う部分もあるかもしれません。ご了承くださいm(＿ ＿)m
ちがいって？
- 受託の場合、ウォーターフォール形式の開発がメイン
- デザインの専門家として参戦👨🌾
- Speeeのインハウスの場合、アジャイル形式の開発がメイン
- 実装以外のオールラウンダーとして参戦🧙♀️🧙♀️🧙♀️
- 目的や状況に合わせて何でもやる ←ここが大きな違い
ウォーターフォール形式は、工程分割で開発を進め、全ての工程を完了してリリースします。
前職のデザイナーは、特に分業化が進んでいたためデザインに専念していました。ディレクターやプロジェクトマネージャーは、全工程にタッチする体制でした。
アジャイル形式は、イテレーション単位でリリースをし、チーム・施策の目的や状況に合わせてデザイナーの動きは必要に応じて変わります。カバー範囲が広くなるイメージです。
Speeeにジョインして、アジャイルで開発するようになって、目的とゴールを強く意識し、”より深くユーザに何を届けるのか？” を考えてデザインをするようになったと思います。
デザイナーの役割の幅イメージ
フェーズによって、デザイナーの役割も変わるんだ！
アジャイル開発を通して、プロダクトのフェーズによって、デザイナーに求められるものが分かってきました❗️
はじめは、すべてを完璧にやろうとして悪戦苦闘していました。
時間がどれだけあっても足りず、、、ひとりで疲弊していました😭
リリースするからには、ちゃんとしたものを届けたい。。。
いつの間にか、自分がユーザファーストじゃないデザイナーになっていることに気づきました。。。
ユーザの課題、目的にフォーカスして、チームで議論しアウトプットを重ねていくことで、プロダクトのフェーズにあったデザインが少しずつ見えてきました✨
目的によって、デザイナーに求めらるもの
実際に対応しているデザインの大小をまとめてみました。
- 大：ガッツリ系
- LPや新規開発、改善施策など
- LPや新規開発、改善施策など
- 小：さっぱり系
- 既存のコンテンツの拡充など
ガッツリ系では、課題などをヒアリングをして噛み砕き、どんな人に、どんな情報を届けると目的を達成するアクションになるのかを考えながら、デザインに落としていきます。 ヒアリングからアウトプットまで以下のように考えています。
- ヒアリングしていること
- 現状の課題
- なぜ必要なのか(目的)
- 達成しようとしていること(ゴール)
- 事業が目指す方向のどこに繋がることなのか
- 今後の計画
- アウトプットする際に考えていること
- 競合とどうやって差別化を図るか
- ターゲットに、最適なフォントサイズ、行間、画面幅、、、
- 最適なメインカラー、サブカラー、画面遷移を考慮したカラーの定義
- 視認性、可読性、操作性、、、
- 画面内に記載する文言は最適な表現か
- ファーストビューに必要な要素がおさまっているか
- メインユーザのデバイス
- 成果をあげるために追加する要素はないか？
- 施策の目的が伝わっているか
逆に、さっぱり系と定義した既存のコンテンツの拡充の場合は、実装後の軽いレビューだけを対応し、可読性が担保できているかという観点で確認をしているくらいです。
デザインの大小によって、ここまで対応する内容を変えています。
まとめ
今回、まとめてみて改めて伝えるのは難しいけれど、整理されていくプロセスも含めて、たのしいなーと思いました！
わたしは、デザインは課題解決のためのひとつのツールだと思っています。デザインを通してユーザ、クライアント、事業の課題を解決していけるように日々精進していきます👨🌾課題解決のために必要なことを取捨選択して、トライ＆エラーを繰り返しながら、やっていきます！！！
あとがき
今回のブログタイトルは、ゆっけがつけてくれました！
さすがブログリーダー！ありがとう ^ ^
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁💁💁
tech.speee.jp
エンジニアだけでなく、様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
