読者です 読者をやめる 読者になる 読者になる

訳も知らないで

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

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

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

あくまでイメージを変える・新しく構築するようなデザインワークの場合の話です(新サイトデザイン、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)の使用例を見れるようにする。

考えてみて

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

Loop processing for NodeList at JS ( ES6 )

Make a note as it is a frequent process.
(get some element and use it at loop processing by JavaScript)

Use for-of

See the Pen Loop processing by for-of for NodeList at JS(ES6) by Fumihiro Nakahara (@711fumi) on CodePen.

Use Array.from (If you need Array returned)

See the Pen Loop processing by Array.from for NodeList at JS(ES6) by Fumihiro Nakahara (@711fumi) on CodePen.

If I need to write in ES5, use Array.prototype.forEach.call() ?

I feel again the merit of Jquery...
Why Is it recommended to not use JQuery? is it a performance problem? Is the library large?

エンジニア(プログラマー)はランニングに向いている

そんな気がしています。
※ここで言うランニングとは長距離走のことね

効率化

ランニング力を上げるために重要なのが、無駄を省く(効率化する)という考え方。

  • 無駄な脂肪、筋肉をつけない
  • 効率の良いトレーニングを行う(根性論じゃない)
  • 無駄なペースの上げ下げをしない
  • 走るときの荷物はなるべく少なくする

など、無駄(冗長)なことを良しとしないエンジニアは
ランニング力向上に必要な考え方が得意なわけです。

自己との対話

ランニングは自己との対話です。
体の状態はどうか、練習の負荷は適切か、シューズは自分に合っているか、など
自分を客観視して、コントロール(チューニング)していくことが重要になってきます。

これって、マシンとの対話に近い気がするんですよね(プログラミング、ハードウェアのチューニング)
練習やツールや食事なんかを自分に与えて、結果をモニタリングしてフィードバックを次の行動に活かす。
こういったトライアンドエラーはエンジニアの得意とするとこなのではと。

ツールへのこだわり

ランニングはシンプルなスポーツですが、ハマるといろんなものにこだわりだします。
シューズやウエアに始まり、補給食やプロテイン、筋トレグッズや疲労回復グッズ…

道具にこだわるエンジニアならきっとそのへんも楽しめることでしょう。

効率化できない部分

ただどうしても劇的には効率化できない部分があります。
それはトレーニング時間です。

ランニング力を向上させるには、どうしてもある程度長い時間走る必要があります。
効率を気にするエンジニアにとってこれは苦痛。

ただ最近はありがたいこととにエンジニア向けのPodcastがたくさんありますし、聴ける本なんかもたくさん出ているようなので、勉強しながら安心してランニングを続けることができます。

初心者の方へ

ランニング力を向上させるのにエンジニアは向いているって書いたんですけど、
初心者の人はゆっくり会話できるようなペースで、余裕を持って楽しんで走ることをおすすめします。

楽しいのが一番。

おわりに

書き終わって思ったけど
これってランニングじゃなくてもなんでもいいような。