CAVIN Tech Blog

CAVIN Inc.のエンジニアブログです。 技術的な内容に加え、福岡市 (Fukuoka Growth Next / fgn) でのスタートアップ運営の日常や、舞台裏をお伝えします。

スタートアップで経験したことを振り返る

スタートアップで経験したことを振り返る | CAVIN Tech Blog

こんにちは、記事随筆にやっと上達が見られるようになったと自負しているCAVINスタッフの竹崎です。

今年大学を卒業し、新社会人となるためCAVINを卒業します。

そのため12月中旬から3月下旬までの約3ヶ月を振りかえり、経験したことやそこから得られた気づきなどをつらつら書いていきます。 客観的に見ると、スタートアップってのはこんなスピード感なんだなとか、逆にここら辺は CAVINらしいなとかがわかってもらえれば幸いです。

目次

エンジン全開モードの時期に加入

常に、エンジン全開モードのメンバーですが、自分がジョインした時の弊社の状況を振り返ると、サービスの開発がすでに始まっていて、新聞や雑誌、ラジオやテレビなどのメディアに露出したり、ピッチやイベントへの登壇を積極的に行なったりすることで認知を拡大していこうとしているところでした。

4つの学び

UIUX領域のキャリアを歩もうと考えていましたが、基本的に、学べることはなんでも学んでやるというスタンスなので、そこから全力で走り続けた3ヶ月間でした。 大きく4つの事を学べたと思っているので、具体的に経験するに至った経緯や、経験した事で得た気づきをそれぞれまとめていきます。

ジョイン後3日目からPM

自分の場合、スタートアップってなに?から1日目が始まったので、3日で、業界とスタートアップの概念を叩きこんだのを覚えています。そこからジョイン後3日目にMTGを組んでもらい、PMという役割を教えていただいたところ、「とりあえず1つ企画してみなよ」の一言で、いきなりイベントの企画を開始しました。

イベント概要ですが、書初め大会3.0という事で、新年一発目の社内イベントを遂行できました。以下に記事としてもまとめてあります。

cavin-backstage.hatenablog.jp

PMとしての基礎を身につける

PMを経験してみて気づいたのは、先回りする力が重要だという事です。

先見性は、物事がどのように進んでいくのかを、頭の中で想定することができる能力だと思っています。その質が上がれば上がるほど、最悪の状況を想定でき、そこを最低限満たす事ができるように業務を設定できます。

それにより、プロジェクトを成功に導ける可能性は高くなると思います。当然、先見性の質を高めるためには経験が必要なので、野球選手がバッターボックスに立つ機会を増やして上手くなるように、PMというバッターボックスにどんどん立っていきたいです。

UI/UX領域の実務と知識を蓄える

前半で申し上げた通り、UIUX領域でキャリアを歩んでいこうと考えていたので、プロダクト開発の業務も行いました。

ペルソナの作成や、サービスのレスポンシブ対応のためのUIデザインに携わり、プロダクトのUIデザインで必要となるAdobeのXDやFigmaなどのツールを使いこなせるようになりました。

cavin-backstage.hatenablog.jp

また、ツールの使い方だけではなく、Appleが提唱しているデザインの基本原則などをインプットする時間をとり、実際のサービスに落とし込む事でより良いサービスを作る事に貢献できたと感じています。

cavin-backstage.hatenablog.jp

UI/UX領域の実務を経験してみて、観察と改善のスピードを上げることが重要だと思いました。サービスの質を上げるために、ユーザーの情報を集めたり、インターフェースのガイドラインを読み込んだり、認知心理など学術的な教養からの学びを即座にサービスに転換することが求められてる、そう感じました。

マネジメント兼組織作り(3月)

2月下旬は、新しいスタッフの加入もあり、各スタッフが行っているプロジェクトの進捗を確認するなど、 自分の事だけでなくメンバーの動きを意識し始めた時期でした。

3月に突入し、Web Marketingチームの組織構築を任されました。

20日という短期間の中で何もない状態からチームを構築するという経験を通して、”定性的なゴールを決める”というのは大事だと感じました。

最終的なゴールとしては、「メンバー間の対話を生み出せる環境と、新しく加入したメンバーがすぐに稼働できる状態」としました。そのために行なったこととしては、組織領域の定義、オウンドメディアの立ち位置、メンバーの構成などをまとめて、ビジュアル化しました。

最後に、チーム会議で資料を共有し、フィードバックをもらった時に、自分が目標としていた最低限のラインは超えられたと実感できたので安心しました。

最後に

オフィスで行う何気ない会話や1対1で行う対話により、互いのことを深く理解しそこからの歩み寄りを通して、人生観や価値観についても学びが多くありました。

そして、ビジネス力や専門性の部分はもちろん大切だけど、その土台となる考え方や独自の哲学を磨いて行くことでより価値を生みだせると気づきました。

以上、約3ヶ月間のCAVINで経験した事とそこで得た気づきを書かせていただきました。

まずペルソナからはじめよ

まずペルソナからはじめよ | CAVIN Tech Blog

こんにちは🤗

CAVINインターンの竹崎です。

今回はUI・UX領域でも重要なペルソナを作成しました。そこで、実際にUIデザインをする前に、ペルソナを作成することでどんなメリットがあるのか、また具体的にどんな情報をまとめたのかを書いていきます。

目次

ペルソナとは

ペルソナは、実際に存在する一人のユーザーを想定してまとめていきます。よくマーケティングで使われるターゲットと違うのは、ターゲットが一定の集団を表したもので、ペルソナが個人レベルの情報を表しているところです。ターゲットを決めることでより物を売りやすくすることはできますが、本当に売れる物を作る時にはまずユーザー定義をしてあげる必要があると思います。

ペルソナが決まってないとUIデザインに一貫性がない

反対にペルソナが決まっていないとどうなるでしょうか?プロダクトやサービスを触る人が明確に定義できていないと、UIをデザインする時の根拠が少なかったり、ユーザーにあった情報設計ができなかったりします。

例えば、タクシーの自動車配車アプリのデザインをする際、30代~40代のビジネスマンをターゲットとして置いているとします。一見ターゲットもあっていて、間違いのないように思えますが、真のユーザーは、「タクシー手配に不満を持っていて、何か新しいサービスが生まれないか期待している、30代のビジネスマン。」かもしれません。この時、ペルソナを定義することで、より良いUIデザインができます。

どんな情報をまとめたか

実際にユーザーになり得る人にヒアリングを行うことで、より現実的なペルソナを作成しました。 ここでは、プロフィールなどの個人情報は架空の情報となっています。弊社のプロダクトを利用するユーザーは農家さんと花屋さんになるため、それぞれのペルソナを定義しました。ペルソナ作成していく上で、大きく4つの情報をまとめています。

ペルソナ作成 どんな情報をまとめたか | CAVIN Tech Blog

1. Profile

個人の基本情報をまとめたもの。名前、年齢、性別、職業、使ってるアプリ、趣味などその他の情報。

2. Behavior(行動)

普段の行動パターンを洗い出すことで、状況に応じて相手の行動を予想できるようにする。

3. Pain(痛み・悩み)

普段の行動において、不便に感じていることなどを洗い出す。プロダクトに機能を付けていく際の 優先順位をつける根拠ともなる。

4. Goal(目標・希望)

達成したい目標を洗い出すことで、ユーザーの本当に求めているものが理解できる。



リサーチで得た情報を4つの項目でまとめてみると、農家さんと花屋さんの業務フローの違いや、それぞれが持つ悩みと目標が見えてきました。 情報をまとめた後は、ペルソナをデザインチームで共有するためにビジュアル化しました。

ペルソナ作成後の変化

ペルソナ定義したことでUIデザインの際に、誰に向けてこのサービスを作ってるのか、どうすればその人が快適に使えるUIになるのかを考えるようになったと思います。

サービスのレスポンシブデザインを行なった際、農家さん側のナビゲーションの項目が5つありました。この時、農家さんがどこでこのサービスを使い、その中のどの機能を使うのかを想定すると、最低限必要な機能は5つのうちの4つの機能だということに気づきました。

そのため、ナビゲーションバーにある項目の数を減らし、減らした項目をメニュー内に置くことで、ユーザーが求めている機能を直感的に利用できるようにしました。

他にも、フォントの大きさや、ボタンの配置、アイコンの種類に至るまで、根拠を持って制作できたため、ペルソナが抱えている悩みや目標を洗い出しまとめることは、サービスの使いやすさや使った後の満足感をあげる上で非常に重要な部分だと思います。

まとめ

今回、ペルソナ作成からUIデザインまでを経験してみて、ものづくりをする際にはペルソナのような誰が、何を、なぜ、いつ、どう使うのかを理解出来るものがないと、良いプロダクトは作れないなと感じました。また、ペルソナをビジュアル化しておくと、その人になった気持ちになって情報設計できるので、ペルソナ定義の優先順位の高さに気づくことができました。以上、「まずペルソナからはじめよ」でした。

パスワードマネージャーにLastPassを採用しました🎉

パスワードマネージャーにLastPassを採用しました🎉 | CAVIN Tech Blogこんにちは🌸 開発の中原です🤗

今回CAVIN Inc. でLastpassを導入したのでそのことをお話しようと思います!

目次

Lastpassとは🤔

Lastpassはパスワードマネージャーです。

Lastpassのパスワード(マスターパスワード)さえ覚えておけば、他のパスワードを覚えておく必要がなくなります。

Lastpassのブログには、ワシントンポストの「90日ごとに新しいパスワードを作成するのがいかに大変か」という記事を引用し、 Lastpassを使用することで、Password fatigue(パスワードを管理したり定期的に変更する大変さ)から開放されると書かれていました。

blog.lastpass.com

どうして必要だったか

パスワードをSlack等でやりとりしてしまうのはセキュリティ的によくないのはよく知られています。

特に私たちのチームは、以下のような働き方をしているのでパスワードを管理する必要がありました。

  • 外出先でPCを使う
  • 社外のパートナーとパスワードの共有をする
  • 使うサービスがどんどん増えていく時期で共有のタスクが頻発する

Lastpassで解決したかったこと

Lastpassを導入することで、以下の問題を解決できました。

導入

導入にあたり、チーム全体で取り組む必要がありました! 具体的な導入の流れを紹介したいと思います🤗

チームのメンバーにやってもらったこと

拡張機能をインストール

LastPassのブラウザ拡張機能をインストールしてもらいました。 幸い、チームの全員がChromeを使用していたのでスムーズに導入ができました。

chrome.google.com

招待メールを確認してもらう

Lastpassでユーザーを追加すると、メールが送信されます。 ユーザーにそのメールにあるリンクをクリックして、招待を承認してもらう必要があります。

パスワードを設定してもらう

承認した後に表示される管理画面で、パスワードを設定してもらいます。 Lastpassでは、ユーザー毎のパスワードをスターパスワードと呼んでいます。

二段階認証(二要素認証)を設定してもらう

今のチームでは任意としていますが、できる限り二段階認証を設定してもらうようにしています。 ただ、認証を求められる頻度が高いので解消したいです..😣

認証ツールも多く用意されていますが、今回はGoogle Authenticatorを採用しました!

f:id:cavin_backstage:20200318123440p:plain

管理者としてやったこと

ユーザーグループを作成する

LastPassはフォルダにユーザーとパスワードを追加していく操作イメージなのですが、ユーザーを一人ずつ追加するのは大変です。そこで、Lastpassではユーザーグループを作成できるようです🎉

ユーザーグループのいい点

例えば、ユーザーを一人追加した場合にユーザーグループを作成せずに必要なフォルダに招待をするとフォルダの数だけ招待をしなければなりません。これだと、Lastpassの管理が大変です..😣

Lastpassのユーザーグループ機能 | CAVIN Tech Blog
ユーザーを複数のフォルダに招待しなければならない

そこで、ユーザーグループを作成するとユーザーの追加が1回で完了します! さらに、フォルダを権限別で分けることによってユーザー追加の際は権限を気にせずに作業することができました!🎉

Lastpassのユーザーグループ機能 | CAVIN Tech Blog
ユーザーグループに追加するだけで必要なパスワードを共有することができる

共有フォルダを作成する

共有フォルダは権限別に分けています。 私たちのチームの一例を紹介します! - Shered-marketing マーケティングチームが使用するパスワードを管理するフォルダ - Shered-outsource 主に、外部パートナーの開発チームにパスワードを共有する時に使用するフォルダ - Shared-sales セールスチームが使用するフォルダ

管理したいパスワードを登録する

f:id:cavin_backstage:20200318122253p:plain

環境変数ファイルなども登録する

f:id:cavin_backstage:20200318122459p:plain

パスワードだけではなく、環境変数なども管理することができます。 画像のように多くの管理フォーマットが用意されていますが今のところPASSWORDSECURE NOTEだけで十分管理できています💪

有料版に乗り換え中です

はじめは、トライアル版から利用をスタートしましたが現在有料版に移行中です。

というのも、トライアル版の期限が過ぎても全機能が使えなくなるわけではなく Admin consoleという画面の機能のみ使えなくなります。

Admin consoleには、ユーザーを管理する機能がありそこにアクセスができないことで招待ができなくなってしまったので、新規で追加するユーザーは有料版のLastpassに招待するようにして徐々に移行を進めて行こうと思います!

カンバン方式のツールにAirtableを採用しました🎉

カンバン方式のツールにAirtableを採用しました🎉 | CAVIN Tech Blog

こんにちは✌️開発の中原です。

皆さんはタスク管理にどういうサービスを採用していますか?

今回はカンバン方式導入までの背景とAirtableのカンバンの良い点、運用してみての感想を共有します✌️

目次:

CAVIN Inc.では、Airtableを全面採用しています

Airtableに関しては、前回の記事でも言及しています。

cavin-backstage.hatenablog.jp

CAVIN Inc. では、

  • シナリオ
  • 開発メンバー
  • DBの設計

など、開発に関する情報はAirtableに集約しています。

タスク管理が必要になった背景

以前はタスクをGithubのIssueで管理していました。

しかし、GithubのIssueはあくまで開発のTODOに近く、
開発以外の場所から要件が上がってきたときに集約する場所がなかったため、
結果SlackやAirtable, Githhubなどに散財していました。

実際、Githubのアカウントを持っているのは開発者だけですし、 開発の見える化を社内全体に対して行うのは難しいと感じていました..。

やりたかったこと

  • 開発者じゃなくても追加・編集・閲覧ができる
  • 1スプリントでやることの見える化
  • 形骸化しない

選択肢に挙がったサービス

いずれも、カンバン方式に対応できます。

  • Asana

asana.com

  • Zenhub

www.zenhub.com

github.blog

なぜAirtableが選ばれたのか

上記の選択肢とやりたかったことに加え、

  • 価格
  • 拡張性

の面から比較してみましたが、
結局はAirtableでもカンバン方式のツールが用意されていたので
採用となりました🎉

長所

  • シナリオとの紐付けができる。

シナリオをAirtableで作成していたので、あとで作られたデータとの紐付けが容易にできます。

無理にGithubと紐づけなくても今のところ問題はありません。 必要があれば、コードレビューのときにAirtableのURLを貼ります。

解決したい点

  • 具体的な実装方法などを話し合うのにチャットがしづらいです。 なので、結論と議論したSlackのURLを出来るだけ紐付けるようにして運用しています。

どんなレーンがあるか公開します

 Airtable カンバン方式 レーン | CAVIN Tech Blog

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レーンが全体周知のためのリリースノートとしての役割も果たせるのではないかと検証しているところです。

運用してみた感想

Airtable カンバン方式 Slack | CAVIN Tech Blog 運用を始めたのが2020年3月2日からですが、今のところ開発メンバーも使いこなしてくれているようです✌️

運用のコツは、

  • Issueのオーナーを明確にする
  • 必要な情報を紐づける・きちんと書く

だと思います✌️

書いていて思いましたが、これらはGithubのIssueで運用する場合にも当てはまるのではないでしょうか。


それでは素敵なカンバンライフを!🤗

福岡のITスタートアップで使っているAirtableを晒してみる

airtable_exposed_thumbnail
airtable_exposed_thumbnail

実際に使っているAirtableを紹介することにしたきっかけ

スタートアップでは様々な形でタスクを管理するかと思うのですが、

CAVINではAirtableを使ってタスク管理をしています。

実際の管理の仕方を今回の記事では紹介してみようと思います。

Airtableとは?

以前の記事でも出てきましたがAirtableとはクラウドデータベースと呼ばれ、

GoogleSpreadSheetとデータベースを合わせた機能や便利な拡張機能も多く、

ビジネスサイドにも技術サイドにも便利なツールです。

cavin-backstage.hatenablog.jp

AirtableCAVINでの用途

ガントチャートなども作ることができるのでプロジェクトの初期段階での業務設計や、

メンバーの連絡先などの情報、組織図なども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運用を確認するためのチャンネルにもなっています。 主なカラム[カラム名 (カラムの入力規則)]

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の予定をGoogleカレンダーに、

手入力する必要がある等まだ便利にできるところはあるので、それはこれからになるかなと思っております。

⑦まとめ まだ社内のシステムや管理方法には改善の余地はあるのですが、その時にも意識することなく正規化されたデータを保存することができるのは、

やりながら改善するスタートアップにはとても便利なツールになっています。

これからもAirtableを使った記事を書いていこうと思いますのでお楽しみ~

HIGをUIデザインに落とし込んでみた

ヒューマンインターフェイスガイドライン(HIG)をUIデザインに落とし込んでみた | CAVIN Tech Blog

こんにちは、CAVINインターンの竹崎です。今回は、前回書いた記事の続編ということで HIGを読んでみて、実際にWebサービスのモバイル用レスポンシブデザインをしていく上で どんな所が活きたのかをまとめてみました。

結論から言って、HIGを読み込む事でデザイン原則を網羅できるので 実践デザインでのミスを減らせると思います。さらに、HIG実践してみてユーザー視点に立つ事の 重要性、ペルソナ定義をする事が必要だということに気づきました。

では、UIデザインをする上で意識した事を実例をもとに書いていきます。

前回の記事

cavin-backstage.hatenablog.jp

目次

ナビゲーションは必要最小限の機能を

ナビゲーションは必要最小限の機能を

こちらのナビゲーションバーはフラットナビゲーションと呼ばれます。ユーザーを目的地に誘導する際に サービス内の様々な所から遷移が可能となっています。基本的にどこのページからでも、目的地に到達ができるようになっているため、そもそもユーザーがこのサービスで何を達成したいのかを理解する必要があります。ナビゲーションはコンテンツを得るために素早く、簡単にするべきだと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つあったナビゲーションタブを1つ減らして4つにしました。減らした1つの機能は、ユーザーが目的を達成させるために必ずしも必要ではない機能だったからです。

アイコンとタイトルを直感的に

アイコンについて、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サービスでは、あらゆる情報が1つにまとまっている ページの事をダッシュボードと名付けることがあります。
そのため、このWebサービスでも、運用の際情報を1つの画面で確認するためのページをダッシュボードとしていました。

しかし、ユーザーがその言葉を聞いて、なんとなくでもいいからこのダッシュボードという言葉が 何かを連想できるかを考えた時、適しませんでした。また、ダッシュボードという言葉の 長さという視点で見たとき、モバイル対応だと余白が足りず、すっきりしたビジュアルにならなかったのでタイトル、アイコンを変更。

②はアイコンが抽象的すぎて、ユーザーが認識するのに負荷が掛かると感じたので、アイコンを 生産者が納品を管理する際使用するコンテナを意識したアイコンにしました。

カッコイイけど使えないよりも、ダサいけど価値があるモノ

IGの原則に当てはめてデザインしていく上で、もう1つ重要なことに気づきました。それは、ユーザーがどこの誰なのか?どこに住んでいるのか?どんな考えを持っているのか?などなど、ユーザーの定義が欠かせないということです。

プロダクトデザインに関する本や記事を見ていくと、「ユーザー目線で物を作れ」やら「ユーザーが迷わないシステム設計を」みたいなことが良く書かれててあります。しかし、ユーザーとは具体的に誰なのか?
ユーザーの定義が決まっていないと、仮説を立ててデザインをする事も出来ない上、本当にプロダクトを使って欲しいユーザーにとって価値の無いモノになるかもしれません。反対にユーザーを定義してあげる事で、仮説と改善を繰り返す事もでき、ダサいけど価値があるプロダクトを作ることができます。

HIGをUIデザインに落とし込んでみて

HIGは、UIデザインをする上で本当に基本的なデザイン原則が書かれています。そのため、なんとなくデザインから脱却するためにも、HIGやAndroidのインターフェースガイドラインは読み込む必要があると思います。HIGに書かれているデザイン原則や、ネットに書かれているTipsは、プロダクトを触るユーザーが、"違和感なく、使いやすく"するための知識ではありますが、時代や環境が変われば人間の認知心理も変化していくので認知心理に関する持続的なインプットが必要だと思います。今後もHIGや認知心理を学び実践に落とし込んでいきます。 

UIデザインでHIGを学ぶべき3つの理由

UIデザインでHIGを学ぶべき3つの理由 | CAVIN Tech Blog

こんにちは、CAVINインターンの竹崎です。
最近は主にUI/UXデザイン領域を担当しています。UIの勉強は始めたばかりなので、まず何をすればいいのかを UI/UXのプロの方に聞いてみたところ、「まずは、HIGを見てみよう。」と言われたので言われた通りHIGのインプットから始めました。

目次

HIGとは

HIGとは、Apple Human Interface Guidelinesの略称で、アップルがアプリケーション開発者向けに 提唱しているデザイン原則のドキュメントです。アップルのデザイン主義から、IOSMacApple watchなどデバイスごとにおけるデザインのルールが記載されています。

アップルの目的は、アプリケーションインターフェイスをより直感的で学習しやすく、一貫性のあるものにすることにより、ユーザーのエクスペリエンスを改善することにあります。

UIデザインでHIGを学ぶべき理由

1. ユーザーを目的地に誘導するため

アップルが提唱するアプリケーションのデザイン原則では、「1つのアプリで、1つの目的が達成されるように設計を行う」とあります。
例えばIOSアプリでいうと、カメラアプリは写真を撮るという1つの目的があり、その目的をユーザーが達成しやすいように設計されています。

このように、まずはこのサービスでできる事は何か、そして目的地を設定してあげて、達成するための手順をどうデザインしていくかを考えていきます。

2. 顧客体験を向上させるため

UIデザインは顧客体験を向上させるためにかなり重要な部分になります。
顧客体験(UX)とは、サービスに触れる前から実際に触った後までを時間軸としてます。そのため、実際にサービスに触れる段階であるUIを改善する事で、顧客体験も改善することに繋がります。
例えば、iOSの基準では、最小フォントサイズは 11pt で、本文の基準は 16pt が推奨とあり、ボタンやフォントの大きさを少し修正しただけでも、ユーザーがそのサービスに触れた後の満足度を向上させることに繋がります。

3. チームでの共通言語となるため

アプリケーションはWebサービスを構築していく際、ある程度のガイドラインに沿ってデザインを進めていくことで、開発者との共通言語として説明ができるため単純にスピードがあがります。
また、UIを見た時にUI/UX的に良くない理由をきちんと説明する事ができるので、デザインチームの中でも、デザインの質を詰めていく際も重要となってきます。

これだけは押さえときたい機能や原則

実際にガイドラインを読んでみて、この原則使えそうだなとか、これ知らないとデザインする時失敗するなとかあったので、3つの機能の意味と注意点を紹介していきます。

モダリティ

Apple ヒューマンインターフェイスガイドライン | モダリティ

モダリィティは、ある目的を達成させるために一時的に以前の画面から分岐するデザイン技法の事を指しています。例えば、Webサイトでレストランを調べて、お店に予約の電話をする時に、電話番号のアイコンを押すと、モーダルとして電話番号の画面が一時的に表示されるものがあります。 モダリティを使うタイミングは基本的に、ユーザーが注目する必要があり、重要な決定をする場面で使われます。また、モーダルは二段階で使用することを推奨していません。なぜなら、モダリティ自体が今 自分がいる場所がわかりづらくなってしまうため、さらにそこからモーダルを使うと、ユーザーの現在地が掴みにくくなるからです。
引用: IOS HIG "Modality"

ナビゲーション

Apple ヒューマンインターフェイスガイドライン | フィードバック

ユーザーがナビゲーションを使う時というのは、基本的に自分のいる場所がわからない場合や、予期しているページが見つからない時などです。そのため、そのサービスの構造や目的がわかりやすいようにナビゲーションを配置する必要があります。ナビゲーションのスタイルも様々でアプリの目的ごとに仕様を変えていきます。
引用: IOS HIG "Navigation"

ナビゲーションを配置する際はこれだけは意識しようね

ナビゲーションのスタイルに関わらず、次の目的地の行き方やユーザがアプリ内のどこにいるのかを認識させなければならないということです。
そのためには、遷移ボタンやアイコンなどを、ユーザーが行きたいページに行けるように、わかりやすくデザインしていきます。具体的には、アイコンなどを感覚的に理解できることや、言葉で説明できるようにならなければなりません。また、目的を達成させるまでのルートを最短にし、到達しやすい情報設計をしていきます。

フィードバック

Apple ヒューマンインターフェイスガイドライン | フィードバック

まず、フィードバックはユーザーの現在の状況をまとめて表示する機能です。
フィードバック機能の理想は、ユーザーが何もせずとも重要な情報を得ることができ、なおかつそのフィードバックがユーザ行動の邪魔をしないことです。例えば、メールなどのアプリでは、送信ボタンを押すと送信完了がわかるようにデザインされています。送信した後の情報は、画面の中央ではなく目立たない場所でなおかつ的確な情報を伝えられる設計になっていることがわかります。また、フィードバック機能をつける際は、不必要な警告を避ける必要があります。警告表示を乱発しすぎると、ユーザー側がその表示にも慣れるようになり、 本当に伝えたい情報を見落としてしまう可能性があるからです。
引用: IOS HIG "Feedback"

これからやってみたいこと

ガイドラインに書いてある機能や原則などは顧客心理をとらえるのに非常に役立ったので、もっと深くガイドラインを読み込んでいきたいです。
また、文書を読んでみて思ったのが、デザイン原則を読んでいくうちにアップルの思想みたいなものを感じたので面白かったです。
もちろんここに書いてあるのはHIGのほんの一部となるので、気になった方はぜひ読んでみてください。

このように、HIGを読むことで、アップルが提唱するデザインの基本ルールをおさえることができました。これにより、サービスを利用してもらった時の顧客体験を向上させることに繋がると感じました。

ということで、次回はHIGを学んだことで、実践だとどんな所が役に立ったのかを自分の体験を元に書いていきます。よろしくお願いします。