Goalist Design Blog

cssが効かない!時のDevTools(検証)による原因究明方法

f:id:k-mitsui:20180829155300p:plain

こんにちは、ミツイです。

cssを組む時にchromeの検証は必要不可欠ですよね。
ゴーリストではデザインチームがコーディングまで行うことが多いので、chromeのDevTools(検証)にはお世話になりっぱなしです。
下手したらillustratorとかSketchとかよりも使ってるツールですが、その実、使われ方が共有されていなかったりするので、僕なりの使い方を書いておこうと思います。

要素の検証ざっくり紹介

まずは、DevToolsの基本的な使い方から。
呼び出し方は大きく分けて、
・右クリック→検証
・cmd + Option + c(cmd + Option + iでも出ますが、cの方がハイライトする場所を選択できるので便利です)
f:id:k-mitsui:20180829123058p:plain
f:id:k-mitsui:20180829123115p:plain
の2種類があります。
どちらからでも良いので、とりあえず開いてみましょう。

Elements・Console・Sources・Network・Timeline・Profiles・Application・Securityのモードがあります。
f:id:k-mitsui:20180829123128p:plain
今回見てほしいのはElementsパネルだけです。

Elementsパネルをざっくり言うと、左がHTML(DOM Tree)で右がcss、です。
cssの部分(Styles pane)は、Styles・Computed・EventListeners・DOM Breakpoints・Properties・Accessibilityのタブがありますが、今回見てほしいのはStylesタブだけ!
f:id:k-mitsui:20180829123151p:plain

DOM treeで要素を探す

・実際のページの検証したい部分をもう一回右クリック→検証
・cmd + Option + c(もしくはcmd + Shift + c。何でショートカットがどちらもOKになってるんでしょうかね。。)
で実際の画面上で選択部分が色付きになります。
f:id:k-mitsui:20180829123211p:plain
青が本体、緑はパディング、オレンジがマージンです。
実際の画面上にtootltipの形で縦横のサイズが表示されます。これもよく使いますね。

f:id:k-mitsui:20180829123222p:plain
imgタグのsrcの値をホバーすると表示画像サイズと元のサイズが表示されます。これも、助かる。

画像のurlを知りたいけど、imgタグがない!

f:id:k-mitsui:20180829123238p:plain
cssのbackground(background-image)に書いてあることが多々あります。
画像の縦横比が変則的でbackground-size:containかcover を使いたい時などにありがち。

階層多すぎて、次の要素を探すの大変。。

f:id:k-mitsui:20180829123258p:plain
適度に閉じた方が構造含めて見やすいですよ。
フッター部分にある階層をクリックして、必要な階層に移動するのも使えます。

Styles paneを見る。上から順に。

f:id:k-mitsui:20180829123325p:plain

セレクタ {  
   プロパティ: 値;  
}  

がバババッと並んでますが、上にあるものが強いセレクタです。
※セレクタには強さってものがありまして、基本的にはどれだけ詳細に書かれているかってことになります。
詳しくは下記ページがわかりやすいです。

『CSSセレクタの優先度を手軽に計算して比較できるツール「Specificity Calculator」 』 https://nelog.jp/specificity-calculator

同じ要素に対して同じプロパティの指定があった場合、Style pane上で上に書いてあるスタイルの方が効くってことです(基本は)。
負けている“プロパティ:値”は、打ち消し線がついてます。
なお、セレクタで勝ってても、!importantで負ける場合もあるので、一番上にあるからと言って油断はできません。
また、継承されるタイプのスタイルは打ち消し線で消されていても反映されている場合があるので、こちらも合わせて注意です。
f:id:k-mitsui:20180829123350p:plain

該当のcssが書いてない。

右クリックやセレクトモードを使ってページの該当部分を選択しても、書いたはずのセレクタが見つからないなんてことがあります。 ・選択されているDOMの子供(か子孫)に書いてある。
・選択されているDOMの親(か祖先)に書いてある。
・選択されているDOMのbefore要素・after要素に書いてある。
f:id:k-mitsui:20180829123434p:plain
・javascriptを使ってインラインスタイル(HTML上にstyle=""で書くスタイル指定)に吐き出されるようにしてある。
f:id:k-mitsui:20180829123446p:plain

他のスタイル指定に打ち消されている。。

【対処法→】セレクタを強く書き換える。上の記事を読みつつ、子孫セレクタを使ったり、複数クラスにしたり。!importantは基本的に使わないでください。未来の自分や同僚のために。

ライブラリのcssに負けている(ことごとく)。。

【対処法→】cssを読み込む順番を変える。カスタムスタイルシートは後で読み込みます。cssは後勝ちなので。
いや、あるんですよ。意外と。wordpressとかで特に。
f:id:k-mitsui:20180829123514p:plain

セレクタの強さが無茶苦茶になってきてて、!importantが連発してある。。

【対処法→】classの命名規則を考え直したほうが良いですね。静的ページならBEM、SMACSS、OOCSS等を使って書く。Angularやreact等ならcssのカプセル化をするのがオススメです。

そもそも書いたはずのセレクタがない。。

【対処法→】Style paneに書いたはずのセレクタがない。下の方まで見たけど見当たらない。。。
原因は様々です。頑張って原因を探ります。よくあるのは、
・セレクタが間違ってしまっている。間違った子孫セレクタの書き方等(scssで書いてるとありがち)。
・そもそも、該当するスタイルが書かれているcssが読まれていない。リンク切れ。(ローカルで作業しているのにcssファイルだけ本番ファイルを見ていたなんてことも)
・cssのセミコロンやコロンの閉じ忘れ。(cssファイルの一番上に書いたら効くのに下の方に書くと効かない、何ていうのはこの可能性ありです)。
・media queryで違うディスプレイサイズを指定していた(その辺り一帯が実はモバイル用のcssになっていたり。。そのためにも、media queryはごそっと書くんではなくこまめに書くのをおすすめします。)
・カプセル化の影響で効かない(Angularとかでありがち)。
・ブラウザのキャッシュが残っているだけ(スーパーリロードは、cmd + shift + r)。

書いたはずのセレクタが見つからないとDevToolsは使いものになりません。
とりあえずstyle paneに出るように修正していってください。

cssを直す

style paneに目的のセレクタがあったら、DevTools上で編集していきます。
プロパティ名、値の部分をクリックするとそれぞれ編集状態になるので修正します。
f:id:k-mitsui:20180829123612p:plain
サジェスト機能があるので、基本的にはそれを使っていきましょう(スペルミスで効かないという無駄時間をなくすため)。
f:id:k-mitsui:20180829123937p:plain

色指定の左にある■をクリックすると
こんなのが出てきて、
f:id:k-mitsui:20180829124002p:plain
直感的に色の変更をできるので便利です。

あと、各セレクタの右に書いてあるファイル名と行数は非常に便利です。 sass(scss)だと、セレクタを検索しても出てこなかったりするのでこれがないと結構困ります。 f:id:k-mitsui:20180829124206p:plain
(ネストしている場合はその塊の先頭行までしかわからないのがたまに傷ですが。。ちなみにAtomでは ctrl + g で指定した行へ移動できます。)

まとめ

表示崩れをcssファイルだけ見て直すとか、0から作る時にcssファイルだけ見て書くとか、今ではもう考えられないです。
できるなら、DevToolsで完結したいくらい。(Atomのプラグインでそういうのありそうですね。なかったら、作れないかしらん)
もしまだ使ったことがないという方いましたら、今すぐcmd + option + c で検証してみてください。
もちろんDevToolsはcssコーディング以外にも活躍するので、機会があればそれらについても書いてみたいと思います。 ではまた!

社内報作ってみた 後編 〜デザインとコーディング〜

こんにちは。マスダです。
前回に引き続き、社内報制作について書いていきたいと思います!
ラフについては前回書いたので、今回はデザインとコーディングについてです。

社内報はこちらからご覧いただけます。

ゴーリスト社内報
ゴーリスト社内報

ざっくりと説明すると、
デザインの工程では、ピクトグラムの作成や配色やそれぞれの要素の細かい配置・余白などを決めていきます。(今回は配色について書きます)
コーディングはデザインをweb上で誰でも見ることができるようにHTMLやCSSを書くことになります。 

 

与えたい印象から配色を決めようとした…!

まずはじめに色を決めるところから始めました。
色はサイトの印象を決める重要な要素の一つになります。
たとえば、赤は力強さや情熱を連想させる色で、青はクールさや信頼感を与える色です。

 

なので、サイトを作るときは、訪れた人にどのような印象を持ってもらいたいかを考えて色を選ぶ必要があります。
また、サイトには1つの色だけではなく、複数の色が使われていることがほとんどですが、この色の組み合わせを配色と言います。
配色はランダムに色を選ぶのではなく、統一感のある色の組み合わせを考える必要があります。
配色はメインカラーとサブカラー、アクセントカラーの割合が7:2:1が一番見栄えがするらしいです。

さて、社内報でどんな色を使うのか、これにはとても悩みました。

まずはゴーリストがどのような会社だと思ってもらいたいのかを考えたのですが、なんせまだ入社して3ヶ月目なので、どんな会社かわからないです。
しいていうなら、情熱的とまではいかないものの、活発なイメージとかメリハリのあるイメージがありました。(研修では営業部のみなさんとの関わりが多かったからかもしれないです。)

なので、今回は「活発・メリハリ」というキーワードを元に色を考えました。

これらのキーワードを連想させるような色、、そんなに色の知識も多くない中いろいろググりまして、活発さを表すのはオレンジなんじゃないか!という結論に至りました。
また、メリハリの部分は一つの色では表せないと思い、使う色のコントラストを強めることによって表そうと思いました。

そこで、彩度の高いオレンジと白の組み合わせでデザインをし始めました。

ところが、、、

どうしても私のしっくりくるものが作れません。
というのも、私の好みがメリハリのあるはっきりとしたものではなくて、曖昧なふわっとしたものなので今回作ろうとしているものとはほぼ真逆だったからです。

これはこれは大変でした。
どこに色を使えばいいのかやそもそものメリハリのつけかた。まったくわからなかったです。
とにかく作っては先輩にレビューしてもらいつつようやく完成したのがこちら。

f:id:ikamasuda:20180828160049p:plain

うーん、今見てもやっぱりしっくりこないです。
自分の好みじゃないからなのか、色の使いどころがおかしいからなのか、単色しか使っていないからなのか。
明確に言語化することは難しいですが、なんかしっくりきません。

 

とりあえず自分のしっくりくる配色を考えてみた

これを社内報発案者の林さんにも共有したところ、作っている人がしっくりこないんじゃダメでしょということで、1からもう一度やり直し。

配色が1パターンだと良いのか悪いのか決めることができないので、数パターン作ってどれがいいのか決めることとなりました。

また、与えたいイメージとかなしにして、自分の好きなように作ってみるのもいいんじゃない?
というアドバイスもいただいたので、配色パターンでしっくりくるものを探してきて色の割合を考えつつ配色していきました。

ちなみに、自分で配色を考えるのはとても難しいのでネット上に転がっているいろんな配色ツールを利用したりもしました。
たとえばこんなものです。(http://paletton.com/
1色指定すれば、相性のいい色を提案してくれます。

そして、いろんな配色を試したものがこちら。

ゴーリストカラーであるレッドを使ったものから、パステルカラーのものまで。

f:id:ikamasuda:20180828163700p:plain

これをひっさげてもう一度林さんのところへいきました。
すると、評価基準も加えてどのデザインがいいのか決めてもらうことができました。

評価基準は下記3点です
・コンテンツとの相性(ふんわりしてる)
・ゴーリストが持つイメージ(グイグイしすぎず中庸)
・全体(GoalistHPなど)との統一感(赤)

これらを総合評価したところ、これがピンとくる!というデザインでした。

f:id:ikamasuda:20180828164701p:plain

なんとこれは、自分の一番しっくりくる配色でした。
おそらく、自分が見慣れている色だと配色のバランスとかとりやすくまとまったものを作れるのですかね。

いろいろパターンを作ってみて、自分の好みのデザインがわかった気がします。
ふんわりしたものが好きで、メリハリのあるデザインはあまり好きじゃないし、作るのも苦手だということを感じました。

 

さて、デザインはこれで決定です。
(最初に、伝えたいイメージを考えたのはどこにいったんだというツッコミは置いておいて、、)

職種や文理のピクトグラムなども自分で作っていろいろ学びがありましたが、ちょっと長くなりそうなので割愛しちゃいます。

 

デザインが決まったらいよいよコーディングです!

 コーディングはさくっと!

 デザインについて書いたら少し長くなってしまったので、コーディングについてはちょこっとにしておきたいと思います。
まず、今作ったデザインをchromeなどのブラウザ上で見れるようにするには、HTMLで文書の構造を書き、CSSで見た目を装飾していきます。

デザインを正確に表現するためにはこの2つの言語を扱えるようにしなくてはいけません。

私の場合は大学生の時に自分のHPを作ったこともあり、基礎レベルの知識はあったので、デザインを表現するのは割とさくっといけたのですが、classの命名に一苦労しました。
自分だけがコードをいじるというわけではないので、誰が見てもこれはどの部品かというのを名前を見ただけで容易にわかるようにしなければいけません。

これが比較的難しかったです。

BEM(Block Element Modifier)という命名規則にならって名前をつけていきましたが、うーんどれがブロックで、エレメントで、、と判断するのが慣れておらず時間がかかりました。
あとは単純に日本語を英語にするのが面倒でした(笑)

コーディングは特筆することも思い浮かばず、、、というより他でまとめて書いた方がわかりやすいと思うので、このブログではさくっとこの辺で終わりたいと思います。

 

1から社内報を作ってみた まとめ

まずはなにか目的をもって制作するのは難しい!

ただ見た目をいい感じに整えるだけだと思っていたので(言い過ぎ)、ターゲットとか目的とかコンセプトとかをしっかり考えること、ターゲットの興味を引くようなコンテンツを考えることなど 、なぜ作るのかの目的を明確にして制作に取り組むのがいかに大変かを知りました。
また、今回は初めての制作ということでラフでどこまで詳細に作ってデザインではなにをするのかという制作の過程をはじめに思い描けていなかったために、過程を行ったり来たりしたしんどさもあったと思います。

なんとなくですが、ラフの段階ではコンテンツの内容を決めることと、コンテンツの中でどれが一番重要な情報かというのを決めること、色をどこにつけるのか白黒で考えておくことが大切なんじゃないかなと思いました。

そうするとデザインの段階では配色を決めたり要素の細かいところに統一感をだしたりすることに集中できていいのではないかと思います。

 

デザインというものは正解がないので、答えを求めたがる私にとってはもやもやが残るものでした。
本当にこれでいいのだろうか。私が作ったものが世に出ていいのか?とは今も思っています。
でも、こういった不安は経験値を積んでいくことでしか解消することはできないと思っているので、あれこれ考えるよりもとりあえず手を動かしていこうと思います。

 

いろいろ書きましたが、無事に社内報がリリースできてよかったです。
今後も社内報は月1回更新されていく予定ですので、興味がありましたらご覧ください。

ゴーリスト社内報

最後まで読んでいただきありがとうございます。

社内報を作ってみた 前編 〜制作のきっかけと、ラフ作成〜

こんにちは。マスダです。

まだまだひよっこでいつになったら自信が持てるようになるのかと日々悶々としています。
そんな私が、6月の職種別研修で製作したものが7月頭にリリースされました!
ゴーリスト初の社内報です!制作期間は1ヶ月。
はじめて自分で1から作ったので、その過程をざっくりと紹介したいと思います。

 

また、社内報ですが、社外にも公開しています!
下記から見ることができるので、興味がありましたらご覧ください!

 

ゴーリスト社内報

ゴーリスト社内報

https://fresh-recruiting.goalist.co.jp/newsletter/

 



社内報を作るきっかけは?

とある5月の某日。

 

「社内報作ってみたいんだよね。」
「それ、職種別研修で作ってもらったらいいんじゃない?」

 

というなにげない会話をきっかけに私が制作することになりました。

 

どうして社内報を作ろうと思ったのか人事部長に理由を聞いてみると、
スタバの店頭においてある「今日いるスタッフの紹介」を見て、これいいじゃん!となったからだそうです。

何がいいかというと、単純にへぇ〜が生まれる。
へぇ〜が生まれると、会話につながる、コミュニケーションが増える。いいですよね。

 

現在ゴーリストでは、社員数が40名近くに増えてきたので、部署が違うとほぼ喋らないという状況が生まれつつあります。

でも、これはあまり良くない状況で、部署間でコミュニケーションが生まれないとそれぞれの部署が思っていることが共有されなくなってしまいます。

なので、雑談ベースでも、いろいろな部署の人とコミュニケーションを取ることはは大切なんですね!

 

このコミュニケーションを活性化させるため、メンバーのことをもっとよく知るために社内報を作ることになったのです。



ターゲットと作る目的、コンセプトを考えよう!

さて、社内報を作るにあたり、まず行ったことはターゲットと目的、コンセプトの明確化です。

これらを明確にしておくことで、方向性を見失うことがなく一貫性を持って制作することができます。

f:id:ikamasuda:20180822124759p:plain

 

社内報制作の言い出しっぺの人事部長の林さんにいろいろとヒアリングしながら、目的やコンセプトを決めていきます。

 

まずは、ターゲット

今回の社内報は社内だけではなく、社外にも公開することが決まっていたので、ターゲットはゴーリストメンバーと新卒・中途の求職者。考えるまでもないです。

 

次に、作る目的

社内と社外の二つのターゲットがいるので、それぞれのターゲットで目的を決めます。
社内:コミュニケーションの活性化
社外:メンバーのこと、会社のことをより深く知ってもらう

うん、これもサクッと決まります。

 

最後に、コンセプト

これが難しいんですよね。
作る目的としてはメンバーのことを知ることができて、コミュニケーションの活性化につながること。

う〜ん。

割と個人のことにフォーカスする内容で、さらっと読める感じ!コミュニケーションしている感じ!

う〜ん。

へぇ〜とか、そうなんだ〜とか、わかる〜が生まれる感じ!

・・・。

「メンバーと対面しているように思えるwebページはどうでしょうか!」
「それいいね!」

 

ということで、「コンセプトは対面しているように思えるwebページ」に決定しました。



無事これでターゲット、目的、コンセプトが決まりました。

 

まとめると

ターゲットと目的
全社内メンバー:コミュニケーションの活性化
新卒・中途の求職者:メンバーのこと、会社のことをより深く知ってもらう

コンセプト
対面しているように感じるwebページ




はじめてラフを作ってみた

コンセプトなど諸々が決まったら次はいよいよ内容を考えていきます。

掲載するコンテンツと、そのコンテンツのレイアウトを考えます。

f:id:ikamasuda:20180822125141p:plain

今回の社内報は社内アンケートの回答結果をインフォグラフィックスでまとめたものです。

 

ということは、コンテンツを考えるために、

  1. アンケート回答を見て、
  2. みんなが興味惹かれる(へぇ〜となる)切り口を見つけ出し、
  3. インフォグラフィックでの表し方を考える

というなかなか大変な作業をすることになりました、、、

 

というか、そもそもラフ作成の作業にコンテンツを考えるフェーズと、そのコンテンツをどのように配置するか考えるフェーズがあるのを全く知らなかったので、

これらの作業を行ったり来たりしながらラフを作っており、めちゃくちゃ時間がかかりました。


コンテンツを固めてから、レイアウトを考えるのがいいですね!
社内報制作で学びました!


ということで、コンテンツを考えます。

今回の社内アンケートでは、

・出身学部
・好きな漫画
・好きな映画
・初めて買ったアルバム

の4つを聞きました。

 

これらのまとめ方を考えていきます。

見た人が「へぇ〜」となることが大事ですから、できるだけ違いが現れるようにまとめることを重視しました。

職種別にまとめたり、年齢別にまとめたり、ジャンル別にまとめたりといろいろな軸で集計してみて、一番面白い!と思える軸を採用します。

 

例えば出身学部の質問では、出身学部を文理に分類して、職種ごとに人数がわかるようにしました。

f:id:ikamasuda:20180821115219p:plain

これは、見た人が「エンジニアでも文系出身の人いるんだ〜、へぇ〜」となるようにするためです。

 

アンケートをまとめるのに一番苦労したのは好きな漫画です。
というのも、私自身が漫画を読まないので、どんな切り口のコンテンツが面白いと思ってもらえるのかがわからなかったからです。

まずはじめに思いついたのがこちら。

f:id:ikamasuda:20180822143935p:plain


漫画を青年漫画や少年漫画の大枠でわけて、どんな漫画を読む人がいるのかを表したもの。
「ふーん」って感じかなと思います。決して「へぇ〜」ではない気がします。

自分では思いつかなかったので、いろいろな人にアドバイスをもらって最終的にはこうなりました。

f:id:ikamasuda:20180822144139p:plain

メンバーの年齢と漫画のジャンルを表形式にして、それぞれの年代の人がどんな漫画を読んでいるのかがわかるようにしました。

情報が増えたことで、さっきよりは「へぇ〜」となると思います。

 

このような感じで他のアンケートもどのようにまとめるかの切り口を考えていきました。

他のアンケートをどのような切り口でまとめたのか知りたい方はぜひ社内報をご覧ください!

https://fresh-recruiting.goalist.co.jp/newsletter/

 

 

 

さて、切り口を考えた後はレイアウトをいい感じに整えていきます。

先ほどの出身学部のものを例に挙げると、全体での文理の割合を表す円グラフの大きさや職種別の人数を表したグラフの大きさなど、どの情報を一番見せたいか考えつつバランスを整えていきます。

こちらがはじめに考えたもの。

f:id:ikamasuda:20180822144840p:plain

全社員での文理の割合と、職種別の人数グラフが同じ大きさなので、いまいちどっちを見て欲しいのかパッとしません。

ということで、次に作ったのがこれ。

f:id:ikamasuda:20180821115219p:plain

職種別の方を大きくして、目がいくようにしました。
これなら、伝えたいことの「エンジニアにも文系出身の人がたくさんいます!」ということがわかりやすいです。

 

ラフを作るのは初めてなもので、先輩デザイナーの皆さんに何度もレビューしていただいて、もうちょっとメリハリあった方がいいとかアドバイスをたくさんいただきながら改善していきました。

 

ちなみにデザイン部では毎日朝会が開かれていて、その日やることの確認とレビューなどがあれば見ていただけるのでとても助かります。



レビューを繰り返して、コンテンツとレイアウトが決まればいよいよデザインに入っていきます。

長くなってしまったので、デザインとコーディングについては後編でお送りします。

最後まで読んでいただき、ありがとうございました〜

 

HTMLは変えたくない!でも、レスポンシブで表示順序を変えたい。そんなあなたに贈るFlexbox tips

f:id:e-nagata:20180822191534p:plain

お久しぶりです。レタスです。
前回書いたブログがなんと5月...だったことにびっくりです。
すでに8月、夏真っ盛り。もはや残暑。皆さんは今年の猛暑は大丈夫でしたか?
私個人の今年の夏はゆるくハイキングしたり、富士登山したり、川でSAPしたりと、野外で割とアクティブに遊ぶことが多かったです。
東京のオフィスより自然に近い方が好きなので、デザインの仕事と何かうまいこと繋げられないかな〜なんて思っているところです。


さて、今回はLP制作でコーディングしながら得たCSSネタについて書きたいと思います。
使う時はごくごく限られるかもしれないですが、私自身もflexboxで日頃利用しない組み方だったので、同じような場合に必要とする人がきっといるはず...!と見込んでメモしておきます。



ちなみに

そういうコーディングもデザイナーがやるの?という声が聞こえそうなので補足しますと。
ゴーリストデザイン部ではSketchやillustratorでのデザイン画面作成に加えて、フロントのコーディングも担当する場合が多いです。
WebページだったらHTML,CSS,JavaScriptを書き書き、
Webアプリなど、プロダクトであればHTML,CSSはこちらが担当し、何かしらの操作やアクションが関わる部分に関してはバックエンドのエンジニアさんにお願いし、それぞれカバーし合って実装してます。
専任のフロントエンドエンジニアが不在ゆえの体制ではあるのですが、作業自体や頭を使う部分が全然違うので、一つのプロジェクト内でも工程が変わるとがらりと気分が変わって面白いです。
得意不得意はありますが、未経験でも関係なくOJTで習得しながらやっています。
私はHTML・CSSの実装は割と苦労しませんでしたが、ロジックを書くのが不慣れなので、JavaScriptに関しては勉強中です。
デザイン部新卒のマスダさんは、デザインワークにも精を出しつつ、これからAngularの習得も目論んでいるようです。どっちもできるようになったら強いだろうな〜。
担当や仕事が分業しきってない規模の会社だからこそなのかもしれませんね。デザインエンジニアリングを深めるという点では良いのかも。

 

いざFlexboxの小ネタを共有せん

弊社サービスHRogチャートのLPを例にしていきます。

 

モバイル表示時、デスクトップとは異なる順番で要素を並べたい

こちらの図はサービスの特徴について説明する部分なのですが、目線が単調にならないように図を左右交互にレイアウトしています。
PCでの表示ですと、こうなります。

f:id:e-nagata:20180822165353p:plain
モバイルではそれを縦並びに表示させればよかろう...と思っていたところ、2番目の段落では図が先にきてしまいました...ヌーン。

f:id:e-nagata:20180822184114p:plain


それはそうなんですけど、順番が変わることについて考えていませんでした。モバイル表示の際には説明文が先に来るように入れ替えたい。

 

そこで登場するのがflexのorderプロパティです。こちらはflexがかかってるアイテムのレイアウトを、数字で順序づけた順に並べることができます。数字が小さい方が先にきます。
ついでに、Flex-directionプロパティを変更すると、並ぶ方向も自在に変えることができます。

参考:

Flex アイテムの順序を設定する - CSS: カスケーディングスタイルシート | MDN


ここでは特徴のテキストを記載している部分のクラス名を.feature、画像部分のクラス名を.feature__imageとして、
その二つを包むdivのクラス名を.feature__wrapperとしました。

.feature__wrapper{
  display:flex;
  flex-direction: column;
}

.feature{
  @media (max-width: 479px){
    order:1;
  }
}

.feature__image {
  @media (max-width: 479px){
    order: 2;
  }
}

すると、こう!

f:id:e-nagata:20180822184133p:plain

思い通りに並べることができました。



要素を縦並びに、かつ折り返すように並べたい

次はこちらです。

f:id:e-nagata:20180822161748p:plain


この中身をアイウエオ順で、縦並びに、かつリストアップされるアイテムが追加されても減っても影響のないように並べたい。

例えば、媒体名を表示している白い背景部分を.medias__detailとして、そこにflex-directionとflex-wrapプロパティを指定してあげます。

.medias__detail{
    display: flex;
    flex-direction: column;
    flex-wrap: wrap;
    height: auto;
    max-height: 280px;
}

flex-directionは子要素の並ぶ方向や始点を決めるプロパティで、
・row(横並び、HTMLの記載順に左から右へ)
・column(縦並び、HTMLの記載順に上から下へ)
・row-reverse(横並び、HTMLの記載順に右から左へ)
・column-reverse(縦並び、HTMLの記載順に下から上へ)
の4つの値から1つを設定できます。
※言語によっては左→右へ読むのがデフォルトではなく、右から左へ読む場合もありますので、アラビア語などでは方向が逆になります。

flex-wrapはflexのアイテムを単一ラインに押し込むか、あるいは複数ラインに折り返してもよいかを指定します。

flex-wrap - CSS: カスケーディングスタイルシート | MDN

 

今回はflex-direction:column;で縦並びにし、

flex-wrap: wrap;で.medias__detailのmax-heightを越えると勝手に次の列へ折り返すように指定しました。

これでどの部分に媒体名が増えたとしても、元からあった要素が後ろに押し出されていくだけなので修正や編集が楽ですね。

 

 

以上、Flexboxのtipsでした!

 

コーディングは調べるたびに小さな知識が増えるので面白いですね。

単語や調べたいことの適切な表現を知らないといけないのが難しいですが...日々日々ぐぐり力も増してってます!

ではまた!

新卒三期、ブログを書く(デザインチーム編)

こんにちは。この春に新卒で入社したマスダです。
2ヶ月間の新卒研修を無事に突破して、6月からデザイン部に配属となりした。
大学では樹木の研究をしていて、今までデザインというものに全く触れたことのない新参者です。

これからもたまに登場すると思いますので、よろしくお願いいたします。

いたって普通な自己紹介をすると、
大阪生まれ大阪育ち、子供の頃は虫取りなど自然と戯れ、大学ではその延長でサクラの研究をしていました。

趣味はゲームと手芸。
スプラトゥーン好き。
自分で筆箱とか鞄作ったり、最近は刺繍にはまっています。

というところでしょうか・・・。

スプラトゥーンについてはゴーリストブログの方で記事も書いていますのでよかったら読んでみてください。
イカ好きによる、スプラトゥーン2体験会!! - ゴーリストブログ

配属初日からリモートワーク!?

f:id:ikamasuda:20180706110549p:plain

さて、6月からデザイン部の所属になりましたが私は東京本社ではなく、大阪支社で働いています。
大阪支社は今のところオフィスにいるのは4人で、それぞれが違う部署に所属しているというなんとも不思議な状況です。
会話もほとんどなく、画面越しの東京の喋り声がたまに聞こえてきます。(会話がないからって、仲が悪いわけではないので誤解しないでください!)

・・・つまり、デザイン知識0の新卒が配属初日からいきなり遠い地に隔離されたわけです。

わたしなんにもできない、でざいんのことわかんない、しごとできないよ状態です。

でも、放置されているわけではないのでご心配なく。
実際はappear.inという無料でビデオ会議ができるサービスを利用して毎日チームのみなさんと顔を合わせています。
また、チャットでもつながっているので必要な情報のやりとりはいつでもできるようになっています。

とはいいつつも、ネットの状況が悪かったり、周囲が騒がしいと、ミーティングの声が聞こえづらくなり会話についていけなかったりということも実際はあります。
また、社内の情報も入ってきづらい状況ではあるのでアンテナをピンピンはってないといけないです。

デザイン部でのリモートワークについては今回が初めてで、まだまだ改善の余地はたくさんあると思います。

f:id:ikamasuda:20180706110657p:plain

いまはまだ、一人で考えるものが多いので密なコミュニケーションはそんなに必要はないですが、これから受け持つ仕事の規模が大きくなると考えると、メンバー全員の認識のズレが起きないように、もっと密なコミュニケーションを取る方法を考えないといけないと思ってます。

チームの課題ですね!

 

いまどんな仕事してるの?

先ほども言いましたが、私はいままでデザインに触れたことがほとんどありません。
唯一あるとすれば、大学のゼミの資料を見やすくレイアウトしてみたりとかそんな程度です。
なので、これからどんな障壁が待ち受けているのか、自分にデザインの仕事ができるのかなど全てが不安でしょうがないです。

でも、できないできないと言っているだけじゃ何も進まないのでわからないながらも手を動かさないといけません!


ということで、6月に配属されてから研修も兼ねて依頼されたお仕事は「社内報を作る!」です。
今回作る社内報は「メンバーのことをもっと知る」ことを目的に、メンバーほぼ全員にアンケートに答えてもらい、そのアンケートの回答をまとめたインフォグラフィックを作り、webページにするというものです。

なんだwebページを1枚作るのか。というような軽い気持ちでいました・・・が、素人の甘い考えでした!!!

webページを作るのにもたくさんの工程があって、ターゲットや目的を明確にしてそれを意識して作っていかないといけないのです。基本中の基本ですね・・・。(まじか!全然知らんかった!)
いままで、マイペースで自分好みのものしか作ったことがない上に、デザインの知識もほぼ無の状態からのスタート。

スムーズにいくわけもなく、ラフ作成からデザインと・・・苦戦しました。

f:id:ikamasuda:20180706110730p:plain

アンケートをまとめる切り口を考えたり、アイコンを作成したり、インフォグラフィック考えたり、とにかくやること盛りだくさん!
とくに、コンテンツの内容を考える工程を想定していなかったので、ターゲットが面白いと興味を持ってくれるものはなんだ、わからん!とかなっていました。

徐々にゴールに近づいていますが、まだまだ気を抜けない状態です。
社内報作成については、また別のところで詳しく書くことにしましょう。

 

と、デザイン初心者なりにイラストレーターの使い方からラフ作成、デザインと奮闘しながら日々頑張っております。
いずれは開発もデザインのこともわかるなんでも屋さんになりたいな〜なんて思っています。
どちらも未経験からの出発にはなりますが、バリバリ知識を詰め込んでいきたいですね!

 

どうぞよろしくお願いいたします!

f:id:ikamasuda:20180706111419p:plain

 

ふろぐんスタンプかわいい!

デザインチームおすすめ本(vol.1)

f:id:k-mitsui:20180425173544p:plain

こんにちは、ミツイです。

ゴーリストにはメンバーの自発的な学習や成長を支援、プロフェッショナル化を促進するため、書籍の購入を会社で負担する制度があります。
デザインチームでも、月に2冊くらいデザイン関連の書籍を購入して勉強しています。
デザイン系の書籍は値が張るモノも多いですが、こういう制度があると知識欲に従って思いきれるので、けっこう嬉しいですね。

チーム内でも「これは良書!」と思う本が幾つかあるので、おすすめ書籍を上げていこうと思います。
今回は第1回として「みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド」をご紹介します。

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

  • 作者: アーロン・イリザリー,アダム・コナー,長谷川恭久,安藤貴子
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2016/05/26
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (1件) を見る


著者紹介

アダム・コナー
MAD*POWというデザインコンサルティング会社のデザイナー。立派な髭がトレードマーク。
Adam Connor - Designer, Illustrator, Etcetera, Etcetera Adam Connor | Mad*Pow
アーロン・イリザリー
「Capital One」というファイナンシャル企業でCMとかUX設計とかをしている人。真面目キャラかと思ったら、結構がっつりタトゥーが入ってますね。
https://www.linkedin.com/in/aaroni Aaron Irizarry on Vimeo

おすすめポイント

『デザインについて相談されて思いつく限りのことを指摘したけど、結論が出ず「う〜ん」となって終わってしまう』
『アドバイスを貰いにいったら「いいね!」と言われて嬉しくなって帰ってきたが、何も解決していなかった』
などの経験がある方は是非ご一読頂きたい本。
デザイン批評(一般的に使う言葉で言うと“デザインレビュー”に近いです)する時に気をつけるべきことや批評に対して持つべきマインドセットを、かなり具体的に書いてあります。

ざっくり内容紹介

フィードバックの駄目パターン、OKパターン

レビューをした時に得られるフィードバックには反応型、指示型、批評型の3パターンあります。

反応型

「良いですね!」「格好いい!」「全然駄目」などの感情的なフィードバック。「良いですね!」が欲しくてレビューお願いしがちですが、批評とはそういうことではないです。
逆に「全然駄目!」と言われても、困りますよね。基本的にこの反応は、ただの好き嫌いです。

指示型

「ここをもっとこうしたらいいんじゃない?」というフィードバック。批評者が解決策を考えて、それを伝えるという形ですね。自分が批評する時にしがちです。。

批評型

デザインのある側面(etc.ボタンを大きくして目立たせたこと)に対して、
それが目的(etc.60代のユーザーが申し込み方法に迷わないようにする)に対して機能しているか、
またベストプラクティスを踏襲しているかどうかをフィードバックします。
こうすることでフィードバックを受けたデザイナーは、その側面について目的に対して機能する解決策を考える、という次回アクションが明確になります。

指示型のフィードバックがなんで問題か?
端的に言うと、このタイミングで解決策を考えるべきではないということです。
ここはこの本の肝でもあるので、もうちょっとだけ詳しく。
人は分析することと創造することを一緒にすることはできない、というのがこの本の主張です。確かにそう思います。
デザインする時はその間を振り子のように行ったり来たりするべきなのですが、批評の場ではそれをするべきではないです。
批評の場で解決策を言うということは、その人は創造に入ってしまっています。
なので、その人は分析して新たな課題を見つけることもできなければ、他の人が言う課題についてもちゃんと理解することができません。
これがミーティングの時に各人バラバラに起こると、、、
お互いのアイデアは論点がズレてるから受け入れられない、下手すりゃ話を聞いてないという状態になってしまいます。
アイデアを恊働して考えるのは良い(むしろやるべき)ですが、批評の場と恊働の場は分けるべきです。
ということで、指示型のフィードバックは批評の場ではしない。

ベストプラクティスって?
所定の状況における最善のアプローチまたは問題解決法を理解するのに役立つ、時間とともに確立されたヒューリスティックのこと。
ヒューリスティック評価で駄目なものは、駄目よって話です。


その後も、批評をする時される時の心構えや、批評しやすい文化を作ることの重要性、ペルソナ・シナリオ・原則・シナリオを基礎として共有すること、制作 プロセスのどのタイミングで批評すべきか等、かなり勉強になることが目白押しです。
かゆいところに手が届くように、普段難しいと思っていたチーム制作での課題について書いてあります。
“扱いにくい人”について1章を割いているところなど、著者たちもだいぶ苦労してきたんだろうなぁと思いますw


まとめ

批評を受ける側にしろ、する側にしろ、一読の価値はある本だと思います。
もちろん、この本で言う「批評」を当たり前に行えているデザイナーさんも多いと思いますが、重要なのはメンバー全員がその考えを持てているかどうか。
批評する側、される側、ミーティングに参加するメンバー、誰か一人でも意識が違えば、そこに対処するコストは結構なものです。
是非、チーム全員で本を回し読むか、勉強会など開いて共有することをおすすめします!
以上、ご清覧ありがとうございました!

LP制作を通してウェブマーケティングに関わってみたこと#1

f:id:e-nagata:20180515171535p:plain

お久しぶりです。レタスです。
この前新卒さんが入社したと思っていたら、もうGWが終わって夏の気配がすぐそこに。季節の変化が早いです...!

今回は自社プロダクトのLP(ランディングページ)制作に関して進めてきたことを記事にしようと思います。ゼロイチではなくリニューアル案件です。
ウェブサイト制作とは違った視点から取り組んでいるので、そのフローを書き留めていきます。

 

そもそもなぜリニューアルをしたのか

リニューアルを手がけるのはこちらのLP。ゴーリストの自社サービス「HRogチャート」について紹介するページです。

f:id:e-nagata:20180515171703p:plain
既存のHRogチャートLPはこちら
オリジナルキャラクターのカエルのふろぐんがトップでお出迎えしてくれます。どどん。
HRogチャートが分析ツールだけに、ふろぐんもグラフでデータを読み解いています。

このLPのベースは3~4年前に作られたものです。これまでも情報の更新や小さな修正、画像の差し替えなどはありましたが、なぜ今回大幅なリニューアルをするのか。
まずはその背景をお話ししたいと思います。

 

事業部の目標と実現のために

今まで構成を変えずにいたLPのリニューアルをなぜ着手することになったのか。

一番の大きな理由は、ウェブマーケティングの観点から現状への見直しが入ったことだと思います。
まず大元に、「ゴーリストのサービスに興味がある方に、もっと自社サービスを周知していき、さらにお問い合わせ数を増やしていく仕組みにしたい。」という目標が設定されました。
それを実現させるにはどうすれば良いのでしょうか?まずは現在の状況を把握しないことには対策がとれません。
そこで頼れるウェブマーケターの方に依頼し、ゴーリストのウェブサイト、サービスのLP、オウンドメディア「HRog」、メルマガ登録・配信、Facebook、etc...に至るまで、ウェブ周りのありとあらゆるデータを分析していただきました。
そのマーケターの方に解説してもらいながら、デザインチーム、HRog編集長と、関わるメンバーで現状を共有。
現在は目標に向かうための改善策と優先順位をたててもらい、じわりじわりと改善策を実行しているところです。

 

例えば何したの?

ほんの一部ですが、改善策についてお話しします。
例えば今回のHRogチャートLPへの流入ルートについて。
HRogチャートのようなサービスを欲しいと思う方※がLPに辿りつき、サービス情報を目にするにはどんなルートがあったのでしょうか。
(※HRogチャートを利用されるお客様は求人広告代理店勤務の営業マンや営業企画の方が多いです。業務で求人情報の市場調査をしたり、クライアント企業の競合となる会社の求人情報を比較分析するために使用されています。)

これまでには、おおよそ3つのパターンがありました。

(A)「求人情報」「分析」「リスト」などのキーワードを含む検索をした場合にLPを見つける

(B)HRogチャートの情報を別ルート(営業や口コミなど)から得、既にサービスの存在を知っている状態で検索する
(C)ゴーリストのウェブサイトからサービスページへ行き、アクセスする
等です。

f:id:e-nagata:20180515171902p:plain

(ウェブマーケターの方からいただいた資料より一部お借りしました)

 

そこから潜在的なニーズのある層に対して、どうすればもっとサービスの周知ができるのか。
その解の一つが、オウンドメディア「HRog」と連携したウェブマーケティングです。
HRogの読者層とHRogチャートのターゲット層は非常に近いため、自社記事の発信を通してアプローチを広げていくことで、サービスの周知度やお問い合わせ数も上がっていくのではないか。という仮説に基づいています。
HRog編集長の頑張りもあり、現在HRogでは月に10本程自社記事を作成・発信。
さらにHRogチャートを使った週間レポート記事は、今年の2月上旬にマーケターの方から見せ方(フォーマット)を変える提案をいただき、構成を修正・追加するなどの改善を行いました。キーワードや訴求ポイントを盛りこみ、HRogチャートならではの特徴も伝わるようにしたところ、HRogチャートLPへの流入数が3ヶ月(2018/02~2018/05)で5倍程度UPしました。

f:id:e-nagata:20180516143733p:plain

(ウェブマーケターの方からいただいた資料より一部お借りしました)

数値に見える明らかな成果!快挙!と喜んだのもつかの間、ここで問題が一つ。PV数が劇的に改善しても、肝心のコンバージョン数はなかなか伸びていなかったのです。
LPへのアクセスは増えたのに、サービスのお問い合わせ数は伸びない。ボトルネックは一体何だ...?


この問題について、定期レポート記事に施したのと同様に、LPの見せ方も改善すれば訪問者がサービスについて理解し、「このサービスを使ってみたい」と感じさせることができるのでは?(→お問い合わせ数も向上するのではないか?)という案が立てられました。

事業部全体の目標や、達成するためのマーケティング策を練る中、「サービスのお問い合わせをグロース(成長)させられない原因がここ(LPの構成)にあるだろう」というポイントが明確になり、LPリニューアルの優先度が高いものになりました。

 LPをいつか直したいね、デザイン見直したいね、といった会話はこれまでデザインチーム内でも上がっていたものの、ほとんど見た目の話に留まったものでした。きちんと工数をとって対応する必要がある、という理由はかなり曖昧なものだったと思います。
そのような経緯があってLP全体をリニューアルする話が決定したのでした。

 

詳細なペルソナ設定

上記にも書いた通り、HRogチャートのターゲットとなる層は求人広告代理店勤務の営業マンや営業企画の方です。しかし、両者をカバーするとなると実際の業務はもちろん、年齢層、ピタリとくる困りごとも異なってきます。
今回はこのどちらかに焦点をあて、軸をブラさないようにしてLPを構築しようという方針になりました。


HRogの自社記事のアクセス数を追っていると、よく見られた記事、そのタイトル、使われている文言、この表現やトピックがささっている読者はどの層か?と仮説を立てていくことができます。(データ分析って偉大ですね)
話し合った結果、今回フォーカスするのは「求人広告代理店勤務の営業マン」になりました。

一体彼はどんな営業マンなのでしょうか?思い当たる特徴をどんどん上げてペルソナ像を具体的にしていきましょう。
・若手(20代前半)
・仕事や情報収集への意識高め
・仕事で売上をあげたい...etc

f:id:e-nagata:20180516150044p:plain

(ウェブマーケターの方からいただいた資料より一部お借りしました)


マーケターの方にリードしていただきながら、JobToBeDone(この人が何を成し遂げたいか?その課題は?)や、家族構成、趣味、好みの雑誌...に至るまで詳細情報を埋めていきます。

何を隠そうHRog編集長が人材業界の営業出身ということもあり、このペルソナ設定については難なくクリア。
こんな情報まで必要なの?という項目もありますが、詳細を埋めておくことで、これ以降の作業を行う時も「この人がターゲットであるならば、◯◯が必要だろう、こっちの方が良いだろう」という想定がしやすくなります。実際、ピン留めがされていると何か迷ったときにも判断がしやすいなと感じました。

 

 

競合調査・理解

HRogチャートは求人市場分析ができるツールです。ニッチなフィールドに特化しているので、競合となるサービスはほぼないと言って良さそうです。
一方、HRogチャートでできる機能の一つに、「詳細な絞り込み条件でオリジナルの営業リストを作る」というものがあります。その機能に関しては、近い商材やそれを扱う企業を競合としてリサーチする必要があるでしょう。競合と思われる3社の、商材を紹介するページの内容やその表記・表現の方法を細かくチェックしました。 

f:id:e-nagata:20180516151110p:plain

(リサーチ表の一部)
他社との比較をすることで、同時にHRogチャートの強み・独自性も発見し、打ち出すことができますね。

 

 

一般的なLPの構成

現LPでは「HRogチャートでできること」について情報が並べられています。しかし、サービスを提供しているこちら側が伝えたい事柄ばかりが目立って、一方通行になってしまっている感が否めません。そもそも訪問者が知りたい情報は何だろう?サービスが彼らにどんな効果をもたらすのだろう?と根本的な構成を練り直す必要がありました。

そこで効果的なLPの基本構成についてリサーチ。

一般的なLPの基本構成を頭にいれたところで、さらに競合のサービス紹介ページとも比較してみます。このページでは何が謳われて、何が省かれているのか。HRogチャートの紹介にあてはめたとき必要となる情報はどれか。などを判断していきます。 

結果的に、HRogチャートのリニューアルではこのような構成を採用しました。

f:id:e-nagata:20180516154118p:plain

(こちらの記事を参考にさせていただきました。)

5年間のランディングページ制作で行き着いた鉄板の構成と7つのポイント|ferret [フェレット]

 

 

構成の確認

一般的なLPの構成と競合企業のLPをリサーチし、マーケターの方とその特徴について共有したあと、お互いの宿題としてHRogチャートに必要な情報の構成案を作ってくることにしました。

作成したものを見比べてみましょう。どれどれ

f:id:e-nagata:20180516155058p:plain

(マーケターの方作成) 

f:id:e-nagata:20180516154855p:plain

(レタス作成)

 ペルソナの心の声と表情を書いてあると感情の変化がとても汲み取りやすく、良いなと思いました。ナレッジとして次回から取り入れていきたいです。
両者で作成すると、照らし合わせたときにお互いの考えていたことが確認でき、差異があった場合にはどちらを採用するか、あるいは組み合わせるか、案をよりよくブラッシュアップできます。

複数人で案を揉むと進捗がかなりスピーディに感じます。
HRog編集長も毎週ミーティングに参加しているので、その場で即意見をもらえ、大きな修正や手戻りも少ない!ステークホルダーを含んだミーティングは今後も都合が許す限り行いたいものです。

余談ですが、デザインスプリントでもステークホルダーの参加について触れていましたね。方向性がちぐはぐしてしまったり、途中で決定が覆って作業時間が無駄になってしまわないよう、大事なポイントでは話し合いに参加してもらうようにする。情報をシェア&確認(できそうでなかなかできないことなので、今回はラッキーなのかも)。

 

編集長に最終確認後、LPの構成を微調整&FIXしました。これでいよいよワイヤー作成に歩を進められます! 

ふー、だいぶ長くなりました。

はたしてどんなLPになるのでしょう...。後編へ続きます!