訳も知らないで

デザイン&プログラミングのことも書くし、それ以外のことも書く。

サイトユーザーの行動を録画できるツール - Jaco

手軽にユーザーの行動を録画するツールがあったので なにか使えるかもと思い少し触ってみました。

導入が簡単で使いやすそうです。

www.getjaco.com

イメージ

一覧 f:id:blog_711fumi:20170919020544p:plain

動画表示 f:id:blog_711fumi:20170919020601p:plain

良かったところ

freeプランがあり試しやすい

freeプランでも1,000セッション/月まで利用可能、チームメンバーの制限なしだったのでお試ししやすいですね。

GTMで管理可能

Google Tag Managerでスクリプトを埋め込めるので、アプリケーション側にあまり手を入れずに導入することができます。

http://kb.getjaco.com/docs/installing-jaco-using-google-tag-manager

ユーザーの特定が可能

こういったツールでは当たり前ですが、User IDなどを渡してあげることでユーザーを特定することができます。 (GTMの場合はDataLayerなんかを使って変数を渡してあげることでいけそう)

http://kb.getjaco.com/v1.0/reference#identify

その他

  • IPやドメイン、Agentの種類などで対象に含めない指定ができる
  • 様々なサービスとの連携が可能(Slack, Google Analytics, Mixpanel…)
  • idやclass名で反応させない要素を指定できたり、inputに入力されたテキストがわからないようにマスク(?に置き換える)したりできる

デザイナーと「世界一やさしい問題解決の授業」

デザインとは、問題解決と価値創造である

と誰かが言ったとか言わないとか。

デザイナーである以上、自分の持つスキルを使って問題解決や価値創造を目指すことになります。
そこで大事になってくるのが情報の整理・分析だと思うのですが、これがなかなか難しい。
何から手を付けていいのかわからない。

そんな時参考になったのが「世界一やさしい問題解決の授業」という本です。

世界一やさしい問題解決の授業

世界一やさしい問題解決の授業―自分で考え、行動する力が身につく

世界一やさしい問題解決の授業―自分で考え、行動する力が身につく

問題解決能力を身につけるために、問題にどのように取り組んでいけばよいかがとてもわかり易くまとめられています。
だって中学生向けの本なんだもの。

本書には

  • 問題の原因を見極め、打ち手を考える
  • 目標を設定し、達成するための方法を決める

という2つの具体例が載っています。
本書の流れに沿って考えを整理していくことで、具体的なアクションや計画、注目すべき指標(数値)がクリアになっていきます。

私の場合

おそらくデキるデザイナーさんは頭のなかで無意識にやっていることなのでしょうが、慣れてない私は設計などを始める際に本の流れに沿って「問題解決のスタート」をきるようにしています。

整理を進め、「この情報は深掘りしたほうが良さそう」「打ち手の具体的な内容を考えたい」など詳細を考えるタイミングでいわゆるデザインの知識やフレームワークなどを絡めて具体的なアイディアに持っていく事が多いです。
(以前はいきなり詳細から考え初めていたため、今振り返るといきあたりばったりな施策が多かったかなぁ…と反省)

整理しておくことで

ゴールが明確になるので

  • 自信(根拠)を持って打ち手を実行することができます
  • 打ち手がうまく行かなくても、方針を変更しやすくなります
  • 現状(うまくいったかどうか)がわかります

私みたいに何から手を付けてよいかわからず困っている方にはこの本をおすすめします。
なんせすぐ読めちゃうからな。

新人さんとかにもおすすめですね

デザインワークを進める上で何を押さえておくべきか

(ビジュアル)デザインを考える上で準備が足りず時間を無駄にしてしまったことがあったので
デザインワークを進める上でやるべきことをざっくりですがまとめておこうかと。

あくまでイメージを変える・新しく構築するようなデザインワークの場合の話です(新サイトデザイン、LP作成など)。
社内の人に依頼されたタスクを振り返って書いたものなので、
社外のクライアントとの仕事だともっと細かく確認すべきことがあると思います。

依頼を確認

  • なぜ必要か、何を解決したいのか
  • ターゲットは誰か
  • 誰が最終決定権をもつのか(誰がデザインに責任を持つのか)
    • 依頼主?
    • デザイナー自身?

どこまでやっていいのか

  • 時間をかけていいのか
    • ダメなら既存のリソースを有効活用する
  • どこまでこだわるのか(一から作るのか、すでにあるリソースを使用するのか等)
  • 方向性の変更(ぜんぜん違う方法、やっぱりやらない)

調べる

  • プロダクトについて
  • ターゲットについて
  • 類似プロダクト
  • 業界・歴史・市場など世の中一般的な情報
  • 参考になりそうなデザイン
    • ムードボード作成

調査

  • ターゲット(と関係者)に聞く
    • イメージがわかる既存のサイトやイメージをピックアップして意見を聞く
      • 案を作ってから、ではなく作る前に(既存のものを利用して)できたら手間が省ける

方針を決める

  • 方針を言語化する
    • 上記の内容
    • (ペルソナ)
      • メイン
      • サブ
    • キーワード
    • トーリー

事前準備まとめ資料

  • (競合・参考)調査結果をまとめる
  • コンセプトシート作成

方針のレビュー

デザイン案作成に着手する前に方針を関係者にレビューしてもらう

だいじなこと

  • 必要無さそうでもこっそりかならずやっておかないとあとでいろんなものがブレて死ぬ。
  • まとめたものをどこまで関係者に見せたほうが良いかは場合による(見せないほうが良い場合もありそう)

踏まえての進め方例

  1. やりたいこと、依頼内容、目的をまとめる
  2. ↑を関係者間でFix
  3. 競合や世の中の参考になりそうな表現・ビジュアル・イメージを集めてデザインの方向性を固めていく
  4. ↑を関係者間でFix
  5. デザイン案を作成し、レビューをおこなう。事前にデザインの意図や理由をまとめておく:コンセプトシートの作成
  6. レビュー等で方向性の変更などあればコンセプトシートに反映させてデザインの修正をおこなう
  7. 5-6を繰り返し、コンセプトが具体化されているか→デザインの詳細・クオリティどうこうのレベルまで落とし込んでいく

某スーパーのセルフレジUI

最近自宅近くの某スーパーにセルフレジが登場しました。
正確にいうと「セミセルフレジ」というものらしく、バーコードの読み取りは店員さんがやってくれて支払いをセルフレジで済ますというもの。
小売店で最近増えているらしいですね。

ルフレジのUI

完全にうろ覚えですみませんですが、上から順に並べると

  1. ディスプレイ(タッチ可能)
  2. レシート出力(&確かこの横にカード入れるところがあったような…違うかも)
  3. 硬化を入れるところ
  4. お釣りが出るところ
  5. 紙幣を入れるところ

みたいな感じでした。

つらい

操作(ユーザーの行動)順と使用する部分を照らし合わせると、

  1. 現金払いかカード払いかを選択:a
  2. 代金を入れる:c, e
  3. お釣りを受け取る:d
  4. レシートを受け取る:b

となります。
(カードで支払いしたことないので↑は現金支払いの場合)

このレジ、操作部分の並びがユーザーの基本となる行動に全く沿っていないため、次にどこを操作してよいか非常にわかりづらいんです。。

あと特にひどいと思ったのが2。
硬化と紙幣を入れる部分が離れているため、初めて使ったときに硬化を入れたあと「紙幣はどこに入れるん??」ってめっちゃ迷ってしまいました。

普通は「お金を入れる部分」「お釣りを出す部分」ってUIの分け方すると思うんですけど、おそらくハードの構造上「硬化を扱う部分」「紙幣を扱う部分」って分け方するのが楽だったのかなーと推測しています。

レシートがお釣りの近くから出ないのも戸惑いましたが、レシートはカード支払いの場合も必要なのでここになったんでしょうね。
一番下でもいいような気がしますがこれもハードの問題でしょうか。

まとめ

まったく関係ないけど紙のクーポンとか独自のポイントカードとかなくしてくれたら嬉しい。

Atomic DesignでWebサービスのフロントエンドをイメージする

Atomic Designというコンポーネントを組み合わせてシステムを構築していく手法がイメージしやすそうだったので、実際にWebサービスのフロントエンドデザインに当てはめるとどんな感じになるのか考えた。

Atomic Designについてはこの辺を参照
Atomic Design | Brad Frost
珍しいワークフロー:Atomic Designの原則とSketchでデザインからプログラミングまで | デザイン | POSTD

CSS

Atomic Designの階層?を意識してスタイルを定義する。

  • ATOMS
  • MOLECULES
  • ORGANISMS
  • TEMPLATES/PAGES

各階層について

ATOMS

最小単位なので、ボタンやリンクといったものから、カラーやフォントなんかもATOMOSとして扱うようだが、 実際にコーディングすることを考えたとき、カラーやフォントといったコンポーネントを修飾するようなスタイル定義はATOMSから外したほうがわかりやすいのでは。

MOLECULES

ATOMOSを組み合わせた、テキストボックス+ボタンのような一つの処理をまとめたシンプルなコンポーネントのスタイルを指す。

ORGANISMS

MOLECULESを組み合わせた、ヘッダーナビゲーションとか検索フォームとか再利用可能なコンポーネントのスタイル。

TEMPLATES/PAGES

各ページごと、もしくはViewファイルごとのレイアウトを定義する。
ファイル名がURLだったりViewファイル名?になるイメージ。

CSSディレクトリ構成イメージ

コンポーネントに関しては↑の階層で整理して、それ以外をbaseやutilsみたいな感じで用意してあげるのがいいかなと。

  • base: サイト全体に及ぶようなベースとなるスタイルやリセットCSS、Sassの変数定義、@import用ファイルなど
  • utils: カラーやフォントなどコンポーネントを修飾するためのスタイル、コンポーネントとは呼べない汎用的なCSSなど
  • atoms
  • molecules
  • organisms
  • templates

実装

コンポーネントCSSCSS modulesなどで実装してあげるとキレイな感じがする(後述のJSから利用する)。
普通にCSS書く場合、CSSがグローバルなことは変わりないので今まで通りBEMとか使うことになるんだろうきっと。

HTML

もしRailsのPartialのようにView(HTML)ファイルが分割できるのであればORGANISMSはPartialに切り出す、みたいな方針にするのもアリかも…と思ったが、ORGANISMS以外の単位でPartialに切り出したいという場面は結構ありそうなので微妙かも。

HTML(Viewファイル構成)は切り離して考えても良さそう。

JS

React.jsやRiot.jsのようなViewも含めてコンポーネント単位で実装するようなものを使っていると、Atomic Designの考え方がそのまま適応できてわかりやすいのでは。 CSSと同じように4階層に分けて実装できそう。

MOLECULESやORGANISMSを実装してコンポーネントを呼び出したり、SPAでTEMPLATES/PAGESを作ったり。 Atomsを実装することはあまりなさそうかな??

スタイルガイド

スタイルガイドでATOMS〜ORGANISMS(+base, utils)の使用例を見れるようにする。

考えてみて

ほんとにイメージ通り実装できるかサンプルを作ってみたいところです(希望)