まずペルソナからはじめよ
こんにちは🤗
CAVINインターンの竹崎です。
今回はUI・UX領域でも重要なペルソナを作成しました。そこで、実際にUIデザインをする前に、ペルソナを作成することでどんなメリットがあるのか、また具体的にどんな情報をまとめたのかを書いていきます。
目次
ペルソナとは
ペルソナは、実際に存在する一人のユーザーを想定してまとめていきます。よくマーケティングで使われるターゲットと違うのは、ターゲットが一定の集団を表したもので、ペルソナが個人レベルの情報を表しているところです。ターゲットを決めることでより物を売りやすくすることはできますが、本当に売れる物を作る時にはまずユーザー定義をしてあげる必要があると思います。
ペルソナが決まってないとUIデザインに一貫性がない
反対にペルソナが決まっていないとどうなるでしょうか？プロダクトやサービスを触る人が明確に定義できていないと、UIをデザインする時の根拠が少なかったり、ユーザーにあった情報設計ができなかったりします。
例えば、タクシーの自動車配車アプリのデザインをする際、30代~40代のビジネスマンをターゲットとして置いているとします。一見ターゲットもあっていて、間違いのないように思えますが、真のユーザーは、「タクシー手配に不満を持っていて、何か新しいサービスが生まれないか期待している、30代のビジネスマン。」かもしれません。この時、ペルソナを定義することで、より良いUIデザインができます。
どんな情報をまとめたか
実際にユーザーになり得る人にヒアリングを行うことで、より現実的なペルソナを作成しました。 ここでは、プロフィールなどの個人情報は架空の情報となっています。弊社のプロダクトを利用するユーザーは農家さんと花屋さんになるため、それぞれのペルソナを定義しました。ペルソナ作成していく上で、大きく4つの情報をまとめています。
1. Profile
個人の基本情報をまとめたもの。名前、年齢、性別、職業、使ってるアプリ、趣味などその他の情報。
2. Behavior(行動)
普段の行動パターンを洗い出すことで、状況に応じて相手の行動を予想できるようにする。
3. Pain(痛み・悩み)
普段の行動において、不便に感じていることなどを洗い出す。プロダクトに機能を付けていく際の 優先順位をつける根拠ともなる。
4. Goal(目標・希望)
達成したい目標を洗い出すことで、ユーザーの本当に求めているものが理解できる。
リサーチで得た情報を4つの項目でまとめてみると、農家さんと花屋さんの業務フローの違いや、それぞれが持つ悩みと目標が見えてきました。
情報をまとめた後は、ペルソナをデザインチームで共有するためにビジュアル化しました。
ペルソナ作成後の変化
ペルソナ定義したことでUIデザインの際に、誰に向けてこのサービスを作ってるのか、どうすればその人が快適に使えるUIになるのかを考えるようになったと思います。
サービスのレスポンシブデザインを行なった際、農家さん側のナビゲーションの項目が5つありました。この時、農家さんがどこでこのサービスを使い、その中のどの機能を使うのかを想定すると、最低限必要な機能は5つのうちの4つの機能だということに気づきました。
そのため、ナビゲーションバーにある項目の数を減らし、減らした項目をメニュー内に置くことで、ユーザーが求めている機能を直感的に利用できるようにしました。
他にも、フォントの大きさや、ボタンの配置、アイコンの種類に至るまで、根拠を持って制作できたため、ペルソナが抱えている悩みや目標を洗い出しまとめることは、サービスの使いやすさや使った後の満足感をあげる上で非常に重要な部分だと思います。
まとめ
今回、ペルソナ作成からUIデザインまでを経験してみて、ものづくりをする際にはペルソナのような誰が、何を、なぜ、いつ、どう使うのかを理解出来るものがないと、良いプロダクトは作れないなと感じました。また、ペルソナをビジュアル化しておくと、その人になった気持ちになって情報設計できるので、ペルソナ定義の優先順位の高さに気づくことができました。以上、「まずペルソナからはじめよ」でした。
パスワードマネージャーにLastPassを採用しました🎉
こんにちは🌸
開発の中原です🤗
今回CAVIN Inc. でLastpassを導入したのでそのことをお話しようと思います！
目次
Lastpassとは🤔
Lastpassはパスワードマネージャーです。
Lastpassのパスワード(マスターパスワード)さえ覚えておけば、他のパスワードを覚えておく必要がなくなります。
Lastpassのブログには、ワシントンポストの「90日ごとに新しいパスワードを作成するのがいかに大変か」という記事を引用し、 Lastpassを使用することで、Password fatigue(パスワードを管理したり定期的に変更する大変さ)から開放されると書かれていました。
どうして必要だったか
パスワードをSlack等でやりとりしてしまうのはセキュリティ的によくないのはよく知られています。
特に私たちのチームは、以下のような働き方をしているのでパスワードを管理する必要がありました。
- 外出先でPCを使う
- 社外のパートナーとパスワードの共有をする
- 使うサービスがどんどん増えていく時期で共有のタスクが頻発する
Lastpassで解決したかったこと
Lastpassを導入することで、以下の問題を解決できました。
- ショルダーハックの防止
- 権限の切り分け
- スムーズなパスワード共有
導入
導入にあたり、チーム全体で取り組む必要がありました！ 具体的な導入の流れを紹介したいと思います🤗
チームのメンバーにやってもらったこと
拡張機能をインストール
LastPassのブラウザ拡張機能をインストールしてもらいました。 幸い、チームの全員がChromeを使用していたのでスムーズに導入ができました。
招待メールを確認してもらう
Lastpassでユーザーを追加すると、メールが送信されます。 ユーザーにそのメールにあるリンクをクリックして、招待を承認してもらう必要があります。
パスワードを設定してもらう
承認した後に表示される管理画面で、パスワードを設定してもらいます。 Lastpassでは、ユーザー毎のパスワードをマスターパスワードと呼んでいます。
二段階認証(二要素認証)を設定してもらう
今のチームでは任意としていますが、できる限り二段階認証を設定してもらうようにしています。 ただ、認証を求められる頻度が高いので解消したいです..😣
認証ツールも多く用意されていますが、今回はGoogle Authenticatorを採用しました！
管理者としてやったこと
ユーザーグループを作成する
LastPassはフォルダにユーザーとパスワードを追加していく操作イメージなのですが、ユーザーを一人ずつ追加するのは大変です。そこで、Lastpassではユーザーグループを作成できるようです🎉
ユーザーグループのいい点
例えば、ユーザーを一人追加した場合にユーザーグループを作成せずに必要なフォルダに招待をするとフォルダの数だけ招待をしなければなりません。これだと、Lastpassの管理が大変です..😣
そこで、ユーザーグループを作成するとユーザーの追加が1回で完了します！
さらに、フォルダを権限別で分けることによってユーザー追加の際は権限を気にせずに作業することができました！🎉
共有フォルダを作成する
共有フォルダは権限別に分けています。 私たちのチームの一例を紹介します！ - Shered-marketing マーケティングチームが使用するパスワードを管理するフォルダ - Shered-outsource 主に、外部パートナーの開発チームにパスワードを共有する時に使用するフォルダ - Shared-sales セールスチームが使用するフォルダ
管理したいパスワードを登録する
環境変数ファイルなども登録する
パスワードだけではなく、環境変数なども管理することができます。 画像のように多くの管理フォーマットが用意されていますが今のところPASSWORDとSECURE NOTEだけで十分管理できています💪
有料版に乗り換え中です
はじめは、トライアル版から利用をスタートしましたが現在有料版に移行中です。
というのも、トライアル版の期限が過ぎても全機能が使えなくなるわけではなく Admin consoleという画面の機能のみ使えなくなります。
Admin consoleには、ユーザーを管理する機能がありそこにアクセスができないことで招待ができなくなってしまったので、新規で追加するユーザーは有料版のLastpassに招待するようにして徐々に移行を進めて行こうと思います！
カンバン方式のツールにAirtableを採用しました🎉
こんにちは✌️開発の中原です。
皆さんはタスク管理にどういうサービスを採用していますか？
今回はカンバン方式導入までの背景とAirtableのカンバンの良い点、運用してみての感想を共有します✌️
目次:
- CAVIN Inc.では、Airtableを全面採用しています
- タスク管理が必要になった背景
- やりたかったこと
- 選択肢に挙がったサービス
- なぜAirtableが選ばれたのか
- どんなレーンがあるか公開します
- 運用してみた感想
CAVIN Inc.では、Airtableを全面採用しています
Airtableに関しては、前回の記事でも言及しています。
CAVIN Inc. では、
- シナリオ
- 開発メンバー
- DBの設計
など、開発に関する情報はAirtableに集約しています。
タスク管理が必要になった背景
以前はタスクをGithubのIssueで管理していました。
しかし、GithubのIssueはあくまで開発のTODOに近く、
開発以外の場所から要件が上がってきたときに集約する場所がなかったため、
結果SlackやAirtable, Githhubなどに散財していました。
実際、Githubのアカウントを持っているのは開発者だけですし、 開発の見える化を社内全体に対して行うのは難しいと感じていました..。
やりたかったこと
- 開発者じゃなくても追加・編集・閲覧ができる
- 1スプリントでやることの見える化
- 形骸化しない
選択肢に挙がったサービス
いずれも、カンバン方式に対応できます。
- Asana
- Zenhub
なぜAirtableが選ばれたのか
上記の選択肢とやりたかったことに加え、
- 価格
- 拡張性
の面から比較してみましたが、
結局はAirtableでもカンバン方式のツールが用意されていたので
採用となりました🎉
長所
- シナリオとの紐付けができる。
シナリオをAirtableで作成していたので、あとで作られたデータとの紐付けが容易にできます。
- リポジトリを跨いだタスク管理が可能になりました。
無理にGithubと紐づけなくても今のところ問題はありません。 必要があれば、コードレビューのときにAirtableのURLを貼ります。
解決したい点
- 具体的な実装方法などを話し合うのにチャットがしづらいです。 なので、結論と議論したSlackのURLを出来るだけ紐付けるようにして運用しています。
どんなレーンがあるか公開します
Icebox
Iceboxは以下の2つの意味で使用しています。
- まだ要件が定まっていない
- Backlogに入れたものの何故やるのかを熟考したい
Backlog
Backlogは1スプリント内で開発のやることをリスト化したものとしています。
2020年3月現在では、1スプリントを2〜3週間として取り組んでいます。
また、Backlogの中でもIssueごとに
- Highest
- High
- Middle
- Low
の優先度をつけて上から順に並べるようにしています。
Doing
実際に取り組んでいる途中のタスクはここに移動させます。
この作業はIssueのオーナー(アサインされた人)が行うようにしています。
Done
Doneはコードレビューが終わり、開発ブランチにマージされたIssueを置くレーンです。
Test
DoneにあるIssueの単体テスト・結合テストを行います。
Release
本番環境にリリースしたIssueはReleaseに移動させます。
今後は、Releaseレーンが全体周知のためのリリースノートとしての役割も果たせるのではないかと検証しているところです。
運用してみた感想
運用を始めたのが2020年3月2日からですが、今のところ開発メンバーも使いこなしてくれているようです✌️
運用のコツは、
- Issueのオーナーを明確にする
- 必要な情報を紐づける・きちんと書く
だと思います✌️
書いていて思いましたが、これらはGithubのIssueで運用する場合にも当てはまるのではないでしょうか。
それでは素敵なカンバンライフを！🤗
福岡のITスタートアップで使っているAirtableを晒してみる
実際に使っているAirtableを紹介することにしたきっかけ
スタートアップでは様々な形でタスクを管理するかと思うのですが、
CAVINではAirtableを使ってタスク管理をしています。
実際の管理の仕方を今回の記事では紹介してみようと思います。
Airtableとは？
以前の記事でも出てきましたがAirtableとはクラウドデータベースと呼ばれ、
GoogleSpreadSheetとデータベースを合わせた機能や便利な拡張機能も多く、
ビジネスサイドにも技術サイドにも便利なツールです。
AirtableのCAVINでの用途
ガントチャートなども作ることができるのでプロジェクトの初期段階での業務設計や、
メンバーの連絡先などの情報、組織図などもAirtableで整理しています。
Google Driveと使い分ける時もありますが、
基本的な会社に関する情報はAirtableで管理しております。
拡張機能で適するアウトプットを手軽に選ぶことができる点と、
情報を正規化(入力規則を整備)や元データを参照して入力することができるので、
スマートデータがAirtable上に自然にストックされるので都合が良いためです。
実際のAirtable
PROJECTテーブル
プロジェクトとしてどの順番で何をしなくてはいけないか、TASK管理の一歩手前の業務設計の段階のテーブルになっています。
ここでざっくりとしたスケジュール感やタスクの依存関係などを整理しています。
主なカラム[カラム名 (カラムの入力規則)]
NAME(short text)---プロジェクトの名前
START(calendar)---プロジェクト開始予定の日付
END(calendar)---プロジェクト終了予定の日付
TEAM(multiple select)---チーム名
OWNER(link to another record)---誰がプロジェクトの責任者か
PLAYER(link to another record)---プロジェクトに参加するプレイヤーリスト
ESTIMATE HOURS(number)---予想プロジェクト完了までの時間
PROGRESS(percent)---プロジェクトの進捗率
TASK(link to another record)---プロジェクトを構成するタスク
DONE(check box)---終わったか否か
TASKテーブル
タスクはここに集まります。
複数チャンネルから集まることもありますが、チームごとにTASKのテーブルはありここでタスクは管理されます。
これをもとに締め切りに間に合っていないタスクについては毎日18時にリマインドが自動的に飛ぶ形になっています。
主なカラム[カラム名 (カラムの入力規則)]
STATUS(single select)---タスクの状態(yet, on going, pend, delay, done)
OWNER(link to another record)---タスクのオーナーが誰か
START(calendar)---タスク開始予定の日付
END(calendar)---タスク終了予定の日付
PROJECT(link to another record)---どのプロジェクトのタスクか
SLACK REF(URL)---タスクの経緯をさかのぼる用のslackのリンク
BLOCKED BY(link to another record)---依存関係にありこのタスクが終わらないと始められないもの
MEMBERテーブル
タスクのオーナーや今どのプロジェクトに参加しているかを参照するためのメンバーリストとメールアドレス等の基本情報をまとめています
主なカラム[カラム名 (カラムの入力規則)]
NAME(short text)---staffの名前
ROLE(multiple select)---社内での役割
TASK(link to another record)---その人にアサインされているタスク一覧
CONTRACTED(check box)---契約書を巻いているか否か
E-MAIL(short text)---メールアドレス
Slack id(short text)---Slackのid
TOOLS(link to another record)---その人に付与されているユーザー権限
RECORD ID (formula)---タスク管理やツール管理テーブルで参照する用のAirtableのid
CHANNEL LISTテーブル
現在存在するSlackチャンネルがまとまっています。
SlackからAirtableに自動的にタスクが追加される社内システムを作ったのですが、
それの参照用の情報が載っています。 社内のSlack運用を確認するためのチャンネルにもなっています。 主なカラム[カラム名 (カラムの入力規則)]
STATUS(single select)---タスクの自動追加スクリプトをdeployしているか否か
TOOLSテーブル
社内で導入してるツールを一覧にしております。 月額費用や、使用者の一覧、支払いを管理している人(管理者アカウントを持っている人)は誰かなどがまとまっているので、 プラン変更の必要性が生じた時に誰に相談したら良いかが分かるのと、 社内全体でどんなツールを導入しているのか全体を確認をすることができるので見直しの定点観測が楽になります。 主なカラム[カラム名 (カラムの入力規則)]
NAME(short text)---ツールの名前
PLAN(short text)---ツールのプラン
PRICE(price)---ツールの費用
PAYMENT CYCLE(single select)---上記ツールの費用の支払い周期(年間なのか月額なのか、買い切りなのか)
DIVISION(multiple select)---どこの部署が買っているか
USER(multiple select)---ツールのユーザーは誰がいるか
WHO PAYS(short text)---通常はCAVIN、誰か建て替えた場合はその人の名前が入る
⑤使ってみて良いところ 記入した物から特に関数などを打ち込むことなくガントチャートにすることができたり、
データを正規化した状態で保存できることから二次利用をすることがしやすい点はAirtableにしかない点だと思います。
特にデータを正規化することができることで複数プロジェクトが同時に動いている時に誰が何の仕事をしているかを把握することができ、
社内の状態を知った上で改善することに役に立つかと思います。
また正規化してあることでAirtableと連携して社内システムを開発する時に
連携以外のことを考えなくて済むのでスムーズに開発をすることができます。
⑥これから改善の余地があるところと展望 Airtable自体がベースが複数ある場合(開発チーム/マーケティングチームのような形でスプレッドシート別に用意する形)の時に、
リアルタイムの同期はできていないため、会社全体の状況を知るにはAPIを叩いて一回読み出す必要があることや、
手入力する必要がある等まだ便利にできるところはあるので、それはこれからになるかなと思っております。
⑦まとめ まだ社内のシステムや管理方法には改善の余地はあるのですが、その時にも意識することなく正規化されたデータを保存することができるのは、
やりながら改善するスタートアップにはとても便利なツールになっています。
これからもAirtableを使った記事を書いていこうと思いますのでお楽しみ～
HIGをUIデザインに落とし込んでみた
こんにちは、CAVINインターンの竹崎です。今回は、前回書いた記事の続編ということで HIGを読んでみて、実際にWebサービスのモバイル用レスポンシブデザインをしていく上で どんな所が活きたのかをまとめてみました。
結論から言って、HIGを読み込む事でデザイン原則を網羅できるので 実践デザインでのミスを減らせると思います。さらに、HIG実践してみてユーザー視点に立つ事の 重要性、ペルソナ定義をする事が必要だということに気づきました。
では、UIデザインをする上で意識した事を実例をもとに書いていきます。
前回の記事
目次
ナビゲーションは必要最小限の機能を
こちらのナビゲーションバーはフラットナビゲーションと呼ばれます。ユーザーを目的地に誘導する際に サービス内の様々な所から遷移が可能となっています。基本的にどこのページからでも、目的地に到達ができるようになっているため、そもそもユーザーがこのサービスで何を達成したいのかを理解する必要があります。ナビゲーションはコンテンツを得るために素早く、簡単にするべきだとHIGにも書かれています。
"Design an information structure that makes it fast and easy to get to content. Organize your information structure in a way that requires a minimum number of taps, swipes, and screens."
引用: IOS HIG "Navigation"より
このデザインをする時、PC版だと5つあったナビゲーションタブを１つ減らして4つにしました。減らした１つの機能は、ユーザーが目的を達成させるために必ずしも必要ではない機能だったからです。
アイコンとタイトルを直感的に
アイコンについて、HIGの原文では、ユーザーが意図しやすいアイコンで、良く知られているイメージを使いなさいとあります。
"Use system icons as intended. Every system-provided image has a specific, well-known meaning. To avoid confusing users, it’s essential that each image be used in accordance with its meaning and recommended usage."
引用: IOS HIG "System Icons"より
ここでは、以下の二点を軸にアイコンとタイトルを改善しました。
- ユーザーがアイコンとタイトルを見て一瞬で何ができるかを想像できるか
- ビジュアルのバランスは整っているか
①の方は、ダッシュボード→ホームにタイトルとアイコンを変更。
ダッシュボードは元々、運転席の正面にあるスピードメータや燃料量などの運転の際
必要な情報が集約されてる場所を言います。Webサービスでは、あらゆる情報が１つにまとまっている
ページの事をダッシュボードと名付けることがあります。
そのため、このWebサービスでも、運用の際情報を１つの画面で確認するためのページをダッシュボードとしていました。
しかし、ユーザーがその言葉を聞いて、なんとなくでもいいからこのダッシュボードという言葉が 何かを連想できるかを考えた時、適しませんでした。また、ダッシュボードという言葉の 長さという視点で見たとき、モバイル対応だと余白が足りず、すっきりしたビジュアルにならなかったのでタイトル、アイコンを変更。
②はアイコンが抽象的すぎて、ユーザーが認識するのに負荷が掛かると感じたので、アイコンを 生産者が納品を管理する際使用するコンテナを意識したアイコンにしました。
カッコイイけど使えないよりも、ダサいけど価値があるモノ
IGの原則に当てはめてデザインしていく上で、もう１つ重要なことに気づきました。それは、ユーザーがどこの誰なのか？どこに住んでいるのか？どんな考えを持っているのか？などなど、ユーザーの定義が欠かせないということです。
プロダクトデザインに関する本や記事を見ていくと、「ユーザー目線で物を作れ」やら「ユーザーが迷わないシステム設計を」みたいなことが良く書かれててあります。しかし、ユーザーとは具体的に誰なのか？
ユーザーの定義が決まっていないと、仮説を立ててデザインをする事も出来ない上、本当にプロダクトを使って欲しいユーザーにとって価値の無いモノになるかもしれません。反対にユーザーを定義してあげる事で、仮説と改善を繰り返す事もでき、ダサいけど価値があるプロダクトを作ることができます。
HIGをUIデザインに落とし込んでみて
HIGは、UIデザインをする上で本当に基本的なデザイン原則が書かれています。そのため、なんとなくデザインから脱却するためにも、HIGやAndroidのインターフェースガイドラインは読み込む必要があると思います。HIGに書かれているデザイン原則や、ネットに書かれているTipsは、プロダクトを触るユーザーが、"違和感なく、使いやすく"するための知識ではありますが、時代や環境が変われば人間の認知心理も変化していくので認知心理に関する持続的なインプットが必要だと思います。今後もHIGや認知心理を学び実践に落とし込んでいきます。
UIデザインでHIGを学ぶべき3つの理由
こんにちは、CAVINインターンの竹崎です。
最近は主にUI/UXデザイン領域を担当しています。UIの勉強は始めたばかりなので、まず何をすればいいのかを
UI/UXのプロの方に聞いてみたところ、「まずは、HIGを見てみよう。」と言われたので言われた通りHIGのインプットから始めました。
目次
HIGとは
HIGとは、Apple Human Interface Guidelinesの略称で、アップルがアプリケーション開発者向けに
提唱しているデザイン原則のドキュメントです。アップルのデザイン主義から、IOS、Mac、Apple watchなどデバイスごとにおけるデザインのルールが記載されています。
アップルの目的は、アプリケーションインターフェイスをより直感的で学習しやすく、一貫性のあるものにすることにより、ユーザーのエクスペリエンスを改善することにあります。
UIデザインでHIGを学ぶべき理由
1. ユーザーを目的地に誘導するため
アップルが提唱するアプリケーションのデザイン原則では、「１つのアプリで、１つの目的が達成されるように設計を行う」とあります。
例えばIOSアプリでいうと、カメラアプリは写真を撮るという１つの目的があり、その目的をユーザーが達成しやすいように設計されています。
このように、まずはこのサービスでできる事は何か、そして目的地を設定してあげて、達成するための手順をどうデザインしていくかを考えていきます。
2. 顧客体験を向上させるため
UIデザインは顧客体験を向上させるためにかなり重要な部分になります。
顧客体験(UX)とは、サービスに触れる前から実際に触った後までを時間軸としてます。そのため、実際にサービスに触れる段階であるUIを改善する事で、顧客体験も改善することに繋がります。
例えば、iOSの基準では、最小フォントサイズは 11pt で、本文の基準は 16pt が推奨とあり、ボタンやフォントの大きさを少し修正しただけでも、ユーザーがそのサービスに触れた後の満足度を向上させることに繋がります。
3. チームでの共通言語となるため
アプリケーションはWebサービスを構築していく際、ある程度のガイドラインに沿ってデザインを進めていくことで、開発者との共通言語として説明ができるため単純にスピードがあがります。
また、UIを見た時にUI/UX的に良くない理由をきちんと説明する事ができるので、デザインチームの中でも、デザインの質を詰めていく際も重要となってきます。
これだけは押さえときたい機能や原則
実際にガイドラインを読んでみて、この原則使えそうだなとか、これ知らないとデザインする時失敗するなとかあったので、3つの機能の意味と注意点を紹介していきます。
モダリティ
モダリィティは、ある目的を達成させるために一時的に以前の画面から分岐するデザイン技法の事を指しています。例えば、Webサイトでレストランを調べて、お店に予約の電話をする時に、電話番号のアイコンを押すと、モーダルとして電話番号の画面が一時的に表示されるものがあります。 モダリティを使うタイミングは基本的に、ユーザーが注目する必要があり、重要な決定をする場面で使われます。また、モーダルは二段階で使用することを推奨していません。なぜなら、モダリティ自体が今 自分がいる場所がわかりづらくなってしまうため、さらにそこからモーダルを使うと、ユーザーの現在地が掴みにくくなるからです。
引用: IOS HIG "Modality"
ナビゲーション
ユーザーがナビゲーションを使う時というのは、基本的に自分のいる場所がわからない場合や、予期しているページが見つからない時などです。そのため、そのサービスの構造や目的がわかりやすいようにナビゲーションを配置する必要があります。ナビゲーションのスタイルも様々でアプリの目的ごとに仕様を変えていきます。
引用: IOS HIG "Navigation"
ナビゲーションを配置する際はこれだけは意識しようね
ナビゲーションのスタイルに関わらず、次の目的地の行き方やユーザがアプリ内のどこにいるのかを認識させなければならないということです。
そのためには、遷移ボタンやアイコンなどを、ユーザーが行きたいページに行けるように、わかりやすくデザインしていきます。具体的には、アイコンなどを感覚的に理解できることや、言葉で説明できるようにならなければなりません。また、目的を達成させるまでのルートを最短にし、到達しやすい情報設計をしていきます。
フィードバック
まず、フィードバックはユーザーの現在の状況をまとめて表示する機能です。
フィードバック機能の理想は、ユーザーが何もせずとも重要な情報を得ることができ、なおかつそのフィードバックがユーザ行動の邪魔をしないことです。例えば、メールなどのアプリでは、送信ボタンを押すと送信完了がわかるようにデザインされています。送信した後の情報は、画面の中央ではなく目立たない場所でなおかつ的確な情報を伝えられる設計になっていることがわかります。また、フィードバック機能をつける際は、不必要な警告を避ける必要があります。警告表示を乱発しすぎると、ユーザー側がその表示にも慣れるようになり、 本当に伝えたい情報を見落としてしまう可能性があるからです。
引用: IOS HIG "Feedback"
これからやってみたいこと
ガイドラインに書いてある機能や原則などは顧客心理をとらえるのに非常に役立ったので、もっと深くガイドラインを読み込んでいきたいです。
また、文書を読んでみて思ったのが、デザイン原則を読んでいくうちにアップルの思想みたいなものを感じたので面白かったです。
もちろんここに書いてあるのはHIGのほんの一部となるので、気になった方はぜひ読んでみてください。
このように、HIGを読むことで、アップルが提唱するデザインの基本ルールをおさえることができました。これにより、サービスを利用してもらった時の顧客体験を向上させることに繋がると感じました。
ということで、次回はHIGを学んだことで、実践だとどんな所が役に立ったのかを自分の体験を元に書いていきます。よろしくお願いします。
CAVIN Inc.ではてなブログをきちんと運用する
こんにちは。エンジニアの中原です✌️
今回は弊社でテックブログを運用する際に気をつけているポイントを紹介したいと思います。
目次
はじめに
テックブログに割けるリソースや目的によって、できることは変わってきます。
まずは、運用規模などを簡単に説明します。
| どんなブログか | 基本的に技術ブログ それに加えて、働く環境にフォーカスした記事を書いてもいいよねという雰囲気 |
| 目的 | エンジニア採用 |
| 執筆できる人数 | 3人*1 |
| 更新頻度 | 1記事/週 |
| 流入経路 | FBからの流入を狙っている。オーガニックサーチは想定していない。 |
採用のために継続的な運用が必要ですが、私は開発のタスクと並行してテックブログを運用する必要があります。
なので、一番効果的なところに力を注ぎ やらなくていいことは出来るだけやらないように運用したい！
と、試行錯誤しつつ運用をしています✌️
Facebookでの見せ方に気を配る
Facebookからの流入を狙っているので、シェアされた際に内容がわかりやすく興味を引くものである必要があります。
1. キャッチーで簡潔なタイトルをつける
「キャッチーで簡潔な」とはどういうことでしょうか🤔
私の理解ではこうです。
キャッチーさ
ビッグキーワードのみで構わないので1ワードは必ず含むことと捉えています。
前述した通りオーガニックサーチは狙っていないので、これさえ間違えなければ何について書かれているかがわかる品質は担保できると思います。
ビックワードとは
SEO対策において、サーチエンジンで検索される回数が多く、一般性の高いキーワード。
引用: ビッグキーワード | コトバンク
簡潔さ
Facebookからの流入を狙っているので、 Facebookでシェアした時に見切れない文字数 という定義が合っていると思います。
2. アイキャッチを設定する
アイキャッチは、
- ユーザーの第一印象に関わるもの
- タイトルだけでは伝わらない記事のイメージを補填するもの
と捉えています。
つまり、アイキャッチは記事を読んでもらうためにとても重要な項目です。
なので、毎回ブランディングマネージャーにアイキャッチを用意してもらうようにお願いしています✌️
アイキャッチ画像はFacebookのOGP画像にもなるので、設定は必須です！
OGP画像とは
OGP とは Open Graph Protocol (オープン・グラフ・プロトコル)の略称です。 Facebook、TwitterなどSNSと連携し、シェアされたときに、ページのタイトル、URL、概要、画像（サムネイル）を正しく伝えるためにHTMLソースに記述するタグ情報です。
引用: OGP Open Graph Protocol - SEO最新用語集│SEO Pack
3. 記事の概要を記入する
記事の概要は、編集画面の編集オプションで編集できます。
これはヘッダー内のmetaタグに挿入されます。
この設定は、検索結果に表示された際のタイトル下のスニペットとしても表示されます。
4. シェアデバッガーを使う
1、2、3でタイトル、アイキャッチ、記事の概要を設定したあとは、 Facebookに投稿する前にデバッグしてみましょう✌️
写真は、Facebookが提供しているシェアデバッガーというツールです。
はてなブログを始めた当初は、全てのOGPタグの設定をすることが必須と思っていましたが実際にデバッグしてみると
- アイキャッチ
- タイトル
に一番力を注ぐべきで、
- 記事の概要
は数文字しか表示されておらず、記事を読んでもらう要素にはなりにくいということがわかりました。
計測をしよう
実際に計測をするためにGoogle AnalyticsとGoogle Tag Managerを設置しました✌️
どちらも細かくCVを設定できますが、まずは
- ページビューが測定できる
- ユーザーがリンクを押したことを計測できる
を目標に設定しました✌️
これで、最低限のデータは蓄積できるはず！
これからやってみたいこと
継続的に運用ができるようになり、書きたい記事がたくさんあります！
そこで、これから試してみたいことを書きます✌️
内部対策
記事数が増えてきたら、過去の関連記事を添付するようにします！
ユーザーをサイト内で行き来させ、平均ページ滞在時間を伸ばす意図があります。
狙った日時に投稿する
とはいえ、まだまだデータが蓄積できておらず、
Facebookでシェアした時間=たくさん読まれている時間
なので、もう少し多くのデータを蓄積できたら 戦略的に投稿日時を設定したいと思います。
