fujiken design blog

でざいんをやっていく

北欧で「デザインと行動」を学んできた話

f:id:kenshir0f:20180730072735p:plain

こんにちは、ふじけん(@kenshir0f)です。
一週間ほど北欧で開催されたCIIDが主催のデザインワークショップに参加し「デザインと行動」について学んできたので、そこで得られた知見や感想を軽くまとめてみます。

ざっくり概要

CIIDとワークショップ

CIIDとは国際的な新興デザインスクールで、出身者はAppleIDEOAirbnbなどの先進的にデザインを取り組んでいる企業に就職しておりいわゆる世界的なデザインの登竜門と言われています。
そのCIIDが毎年開催しているワークショップの中で、僕はWeek4のDesign for Behavior & Impactを受講しました。

内容としては

  • 行動科学をどのようにサービスデザインに落とし込むか
  • 行動バイアスがどのように人の意思決定プロセスに影響するか
  • それらを適用するときのデザインプロセスはどう踏むのか
  • どうやって行動の変化を測定するのか

などなど、人の行動(Behavior)に絞って5日間がっつり体験するコースです。

僕はもともと人間工学(人間中心設計)を専攻していたのでBehaviorに関する基礎知識は持っていましたが、それをいざサービスのデザインに適応するとなると「うーん、正直自信ない、、、」とモヤモヤしていたので、今回のワークショップを通して腑に落ちた部分があったのでいくつか共有します。

人を変えることは難しい

まず念頭に置くべきことは「人の意志を変えるのは難しいので、人の周りの環境を変えること」です。例えば、

  • 明日早起きしようと思う夜の自分
  • 当日の朝、布団から出たくない自分

のように、人は時間や場所によって考えやその振る舞いが変わるため、人を直接変えることは非常に難しいことが分かります。(Planning fallacy)

人の周りの環境を整えるほうが結果として行動しやすく、例えば

  • 朝になったら自動でたたまれる布団
  • 朝になったらカーテンが自動で開く
  • アラームを洗面台に置く

など、朝に目覚めやすい環境を整える方が「朝絶対起きるぞ!」と意思決定するよりも遥かに行動を起こしやすいです。(self-control)

行動させるデザイン作成のプロセス

では、具体的に行動をさせるデザインを生み出すプロセスはどう踏むのか?
百聞は一見に如かずなので、こちらの動画を御覧ください。

この動画では一回で成功させていますが、基本は

  1. 行動観察(Listen)
  2. プロトタイプ構築(Build)
  3. テスト(Test)
  4. 反復(Repeat)

を行うことで、行動がどう変わっていくかを少ないコストで検証していくことができます。
僕的にはUIデザイン検証のBuildに時間が取られがちなので、とにかくすばやく作ってTestしていきたいですね。。。
これも「Buildの制限時間を設ける」など行動しやすい環境を整えることが大事かなと思います。

よくある誤解

ワークショップ中は「行動するデザインとそうじゃないデザイン」についての議論がかなり起きていました。 f:id:kenshir0f:20180730053553p:plain 上の図は議論で印象に残っていた内容です。

左の図は「後部座席に人を乗らせないデザイン」として参加者が調べてきたものですが、これは人の意思決定に影響させるだけであり具体的な行動をさせるデザインではありません。
行動させるなら「後ろをトゲトゲにして座らせないようにする」とぶっ飛んだことを言ってましたが、まさにそのとおりだなーと感じました。

右の図はクラス内にあったお菓子です。
実は3時間くらい経過しても「誰も右の入れ物からお菓子を取らなかった」という様子の写真で、人は面倒な要因を無意識に排除して行動する傾向があることが分かります。(Hassle Factors)

講義中でもいろんな仕掛けで参加者に「行動させるデザイン」を体験させながら進むワークショップだったので、実例で楽しみながら過ごせました。

さらに詳しく

他にも行動科学、行動バイアスと紐づけた行動の話など上げたらキリがなのですが、それらについてはcookpad tech kitchen #17でお話します。

cookpad.connpass.com

発表後にスライドを公開予定ですが、僕としては直接お話ししたり意見交換出来たら嬉しいので参加できる方はぜひ聞きに来てください。
(宣伝ごめんなさい...)

参加した感想

今回のワークショップは期待以上の学びやディスカッションができて120点の大満足でした。
ただ他のクラスでは期待していたのとちょっと違った...という人もいたので、講義内容など十分に調べた上で申し込むのが無難かなーと思います。

CIIDのワークショップは今年の12月にも開催されるみたいなので、興味ある分野があれば参加してみてはいかがでしょうか。

ではでは👋

開発スピードを上げるため、Sketchを辞めてFigmaに移行した話

f:id:kenshir0f:20180713002356p:plain

こんにちは、ふじけん (@kenshir0f) です。
普段はモバイルアプリを主としたサービス開発のデザイナーを担当しております。

業務ではSketchを使ってアプリのUIを組んでいるのですが、 先日チームの開発体制を見直すときにFigmaというデザインツールに移行しました。
Figmaに乗り換えるに至った経緯やプロコンなど、ざっくりまとめてみます。  

なぜsketchから乗り換えたのか

今まで他の人と共同で同じsketchデータを作業することがなかったのですが、メンバーが増えてからはabstractで共同で作業していました。
ライブラリを分けたりbranchを切ったりしながらデザインを行っていたのですが、しばらく経つと不満点がいくつか見えてきます。

  • 影響範囲がでかいライブラリを更新するとコンフリクトしやすい
  • branchを切って作業してマージするなどスピードが遅くなりやすい
  • デザイナーにbranchの概念を説明するところから始まるので理解が難しい
  • sketchをもっていない人がデザインデータを見れない

特にデザイナーが増えてくるとデザインスピードが落ちる傾向にあって、これはチームとして良くないためなんとかしたいなー。。。なんて思っているときに見つけたのがFigmaです。
いまのところ開発の中で一番スピードを出せるデザインツールだと感じています。

Figmaに決めた理由

Figmaweb上でデザインデータを作成することが出来るサービスです。
google docs や spread sheetみたいに共同で編集できるイメージですね。

基本的なことはSketchと同じですが、Figmaならではの圧倒的に強い点がありました。

  1. 同期的に作業ができる
  2. webから(招待すれば)誰でもデザインデータを見れる
  3. 誰でもコメントを付けられる
  4. 相手の作業状況やマウスカーソルを視認できる
  5. sketchのデータをそのままインポートできる

特に 1. 同期的に作業ができる が優れていて、
一つのデザインデータを全員で同時に作業できるため、誰かのデザインデータのアップロードを待つ必要がありません。
また 5. sketchのデータをそのままインポートできる が文字通りライブラリや継承されているsymbolなどのデータをそのままインポートすることができます。

しばらく使ってみて致命的な問題はなかったどころか、sketchにはない機能で前よりも作業スピードが早くなったのを実感したので、そのままFigmaに移行完了しました。  

移行するときに注意したこと

Figmaは業界で標準的なsketchと比べて比較的新しいサービスなため、いくつか懸念点を考慮した上で移行しました。
移行するときに判断基準とした項目はこちら。

  1. 今よりもチームとしてスピードを出してデザイン出来ること
  2. 僕が突然いなくなっても誰かが運用できること
  3. コストがかかりすぎない
  4. 数年後にデザインデータを移行できること

1, 2, 3は触っているうちにクリアになりました。
ただ4に関しては不安が残ります。というのも、Figmaがサービスを停止した場合はデザインデータがまるっと消えてしまうためです。また新たに使いやすいデザインツールが出たときに移行できるか、という点でも疑念が残ります。
しかし、sketchもデザインデータをエクスポートする機能はないにも関わらず丸っと移行することができたので、先のことを意識しすぎて現状を放置するよりも改善して先に進むことにしました。

実際に開発スピードが上がったと感じるところ

  • エンジニアがデザインデータを直接見て、マージンやフォントサイズなどを確認できる
  • デザイナーはデザインデータの持ち方を気にせず、デザインに集中できる
  • ディレクターがデザインデータに気になった箇所や仕様に関する疑問を直接コメントできる
  • デザインの変更がリアルタイムで変わるので、コミュニケーションの待ち時間が発生しない
  • プロジェクト、ファイルごとに細かくデザインデータを分割できるためAtomicDesignと相性がよい && デザインデータを管理しやすい
  • ライブラリの参照データを選択して見れるため、コンポーネントを選びやすい

Figmaのまだまだな点

  • 英字フォントだと日本語が表示されない
  • プロジェクト(ファイル)をまたいでコンポーネントをコピーできない(うまくやらないと再設定がしんどい)
  • プラグインがない
  • レイヤーでの操作がたまにこちらの期待している動作をしないことがある(sketchに慣れているせいもある)

特に英字フォントだと日本語が表示されないiOSの場合辛くて、SF Pro Textで日本語が打てないためHiragino Kaku Gothic Stdにして英数字もそれで許容する、みたいなことしないといけません。
合成フォントで解決するか、英数字だけの部分はSF Pro使うなど解決方法はいくつかありますが、僕はしばらく様子見でアップデートに期待ということにしました。
本当に辛くなったら合成フォントでカバーします。

移行した感想

実は最初、Figmaに移るつもりは全くありませんでした。
sketchに慣れていましたし、Figmaに移行するコストもでかいし、、、みたいに思っていたのですが、「あれ、考えが保守的になってるのでは??新しい技術を採用してスピードを上げ、成長する機会を無意識に失ってないか?」など冷静に振り返ってみて、メリット・デメリットを洗い出したあとに移行の決断をしました。

安全地帯から飛び出てトライするのは、やはり勇気がいることだと思います。
今回は大胆に挑戦してよかったと思っていますが、運用でなにか知見を得られたらまたブログにまとめてみます。

ではでは👋

 

2018年の上半期を振り返る

f:id:kenshir0f:20180709005211p:plain

雑に2018年の前半戦でやってきたことを振り返ってみた。
初めての取り組みが多くて成長を感じている(気がする)

ブログを運用し始めた

kenshir0f.hatenablog.com

去年の11月にメモを雑に上げていたが、本格的に書き始めたのは今年の4月から。 これからも学んだことを知見公開としてちょっとずつでもいいからやっていく。

ポートフォリオサイトを公開した

kenshir0f.hatenablog.com

かなり雑に作ってすぐに公開できるのFirebaseのすごいところ。
個人で使う分にはほんとに良いと思う。 このブログもポートフォリオに移行したいが、焦らずにやっていこう。

一眼レフ始めた

kenshir0f.hatenablog.com

まだ仕事では使っていないが、ポートフォリオサイトに載せる写真でもよいので継続的に撮っていきたい。

フルデザインしたアプリを初めて公開した

ゼロから全部デザインしてリリースしたのは初めてなので、めちゃくちゃ緊張した。

今の所評価も高くてほんと嬉しい。。まだまだこれからなのでどんどん改善していきます!

デザインガイドラインを作った

これも初めて。開発しやすいガイドラインというのは今もよく分かっていないので、調査した上でどんどん良くしていきたい。

f:id:kenshir0f:20180708233157p:plain

デザインシステムを作った

これも初めてだ。
新規事業でこんなにもチャレンジさせてくれる環境ないので本当によいチームに恵まれていると思う。
これもまだまだ中身がないのでガンガンやっていく。

f:id:kenshir0f:20180708233412p:plain

登壇した

これも初(ry
下期はすでに発表1つしていて、あと2つ出ることも決まっている。
やっていくぞー。

下期の目標

上期はいろんなことを試してみて、人生で最も成長したなーと実感した半年間だった。
下期にトライすることはざっくりこんな感じ。

  • 新しいデザイナーの育成(というとおこがましいので一緒に相互作用で成長していく体制を作る)
  • 開発メンバーが働きやすい環境の整備
  • Figmaの運用
  • 分析の数字からデザインの改善とユーザーさんの体験をもっとよくする取り組み
  • ポートフォリオサイトの充実
  • 管理画面とアプリ本体の実装
  • デザインシステムの公開

こうやってみると夢があるなー。成長しか感じない気がする。。。
さーこれからだ、下期も引き続きやっていくぞ!!!!

ポートフォリオサイトをFirebase + Next.jsでシュッと作った

f:id:kenshir0f:20180617202552j:plain ちょろっと前にこんな話があったので、簡単にポートフォリオサイトを構築した。

業務でFirebaseを使うため、慣れつつ新しい技術を使ってみたいという思いで手を出してみた感じです。

ポートフォリオはこちら

触りたかった技術

  • Firebase
  • Next.js
  • React
  • Typescript
  • Storybook
  • (AtomicDesign)

デザイン

シュッと公開したかったので中身はほぼなしの一枚ページをsketchで作りました。
細かいところは後で直す予定。

f:id:kenshir0f:20180617200950p:plain

構成

最近は業務でAtomicDesignの思想を取り入れてるので、コンポーネント単位で区切るのを意識して実装しました。
今回のページ構成はこんな感じ。めちゃくちゃシンプル。 f:id:kenshir0f:20180617201826p:plain

Firebase

個人のポートフォリオでFirebaseを選んだ理由として

  • 無料でhttpsの設定が出来る
  • デプロイが簡単
  • (業務で使ってるので慣れたい)

という感じ。
httpsは自動で行ってくれるので何もしなくて良くて最高。
デプロイもfirebase deployと入力するだけなのでちょっとした修正もすぐ反映できます。
ただデプロイ時間がめちゃくちゃ長いのはなんとかしてほしい。。。

Next.js

Next.jsはpagesディレクトリにindex.tsxを入れとくと/につながり、hoge.tsxを入れると/hogeにルーティングしてくれる非常に便利なやつです。
いちいちページを作るたびにルーティングの設定をしなくて済むので気軽に作れます。
今回はindex.tsx_error.tsxを用意しました。後者は404ページのデザインを適用させています。

React

モダンなのとAtomicDesignと相性がいいので使ってみた。
現状のペライチだと恩恵が少ないが、今後拡張していく予定なので真価はこれから発揮されるであろう。

Typescript

単純に型定義をしっかりしてプログラミングしたかったので採用した。 それ以外の理由は特になし。

Storybook

AtomicDesignの参考書に導入方法が乗っていたのでそのまま使ってみた。
Typescriptに変換するところだけ注意すれば、コンポーネント単位でデザインをテストできるので便利。

(AtomicDesign)

前のブログで書いたとおり、デザインと実装の変更に強い仕組みなので採用。
今回は実装の部分で練習がてらいろいろ試してみた。

その他細かいところ

metaタグと共通のcss

共通で使いたい要素はutilsというフォルダに分けてimportしています。
こうするとHeadタグにタイトルやogpの設定ができるのでページごとで分けられて便利。
cssも共通のカラーを定義したファイルを置いてimportしているので変更があっても一箇所で済むのはよい。

SpeedTest

デプロイ後に https://gtmetrix.com/ でサイトのスピードテストをチェックした。
画像の圧縮で改善ポイントが見つかったのでそのとおりに従った。
キャッシュするともっと良いらしいがやり方が分からなかったので後で改善する予定。

f:id:kenshir0f:20180617201636p:plain

終わりに

とにかくスピードを優先して実装したのでこれからちょっとずつ直していきます。
今後はブログもhatenaから自前のものに移していきたい。。。やっていくぞ!!!

Atomic Design本を写経して感じたこと

f:id:kenshir0f:20180505232824j:plain

Bonfire Design #3で一緒に登壇した五藤さん(@ygoto3_)が書いた「Atomic Design - 堅牢で使いやすいUIを効率よく設計する」を読みました。基本はAtomicDesignに関する話がメインですが、現在の開発状況に至るまでの過程や仕組みから話が展開されるので非常に分かりやすかったのと、少し前のweb開発体制を知らない僕にとっては視野が広がり読んでて純粋に楽しかったです。

デザイナー視点で読んだ感想

エンジニアが書いていることもあって、「エンジニアリング的思考」をコンポーネント単位で解説している点が非常に参考になりました。デザイナーはデザインの観点だけでなく実装のしやすさも考慮に入れてコンポーネントを作るのですが、「どういう単位で」「どういう命名規則で」「どうやって管理するのか」などはエンジニアとコミュニケーションを取って進めていくことが多いと思うので、そういったエンジニアリングの観点からの言及があるのはありがたいです。

写経した感想

本書にはサンプルプロジェクトが載っていてReactを使ってコンポーネントを作る過程を体験することができます。僕自身Reactはほとんど触ったことなかったのですが、実装まで入ってサービスを作っていきたいので写経してみました。全部終わってませんが、コンポーネント作成を一通り終えた時点で感じたことは「デザイナーこそ写経すべき」と強く思いました。

主な理由は2つ。

  1. エンジニアがコンポーネントをどうやって作っているか体験できるため、デザインデータを渡す時に何を配慮すればよいかが自然と見えてくる
  2. (実装まで触る人は)デザイナーがコンポーネント管理まで入ることでエンジニアの負担を減らせる

特に実装まで入るデザイナーはReactの思想とAtomicDesignは強力な組み合わせだと実感できるので、「なんとなくよさそう」から「デザイナー、エンジニアにとって確実に有益」に考えがシフトすると思います。またコンポーネント開発フローを体験することでいざ、チームに導入しようした時の判断材料も見えてくると思います。 最近はSketchを使ってデザインデータを作ることが主流なのもあり、Symbolを上手く使ってAtoms, Moleculesと組み合わせて作ることはデザイン製作のスピードを上げるのにも非常に役立つと思います。

個人的には4-3のプレゼンテーショナルコンポーネントとコンテナーコンポーネントの表示と見た目のロジックの話は目から鱗でした。エンジニアにとっては当たり前?なのかもしれませんが、メンテナンスしやすい仕組みづくりに感動した感じですね。僕もデザインデータを管理しやすいように意識して制作していますが、「管理しやすいデザインデータの仕組み化」はデザイナーにとって課題なので参考にできる部分がありそうに感じました。

写経してハマったポイント

サンプルコードは解説が丁寧で非常に分かりやすかったのですが、React(というかJavascript?)がほとんど未経験だったからか、途中から急にサンプルコードが難しく感じました。というのも構文に関する説明はほとんどないため、試しに触ってみるか〜と軽い気持ちでやって予想してたよりも(理解のために何度もコードを読んだため)時間がかかりました。

特にハマった点を振り返りのためにざっくりまとめます。

アロー関数

hoge = function(x){
  x > 0 ? x : 0;
}

const hoge = (x) => { x > 0 ? x : 0 }

のように書ける。手前の括弧は引数だと読んでるうちに気づいたのですが、次のコードを見て不安になりました。

参考: http://ushumpei.hatenablog.com/entry/2016/09/06/235336

二重のアロー関数

const fuga = x => y => x + y;

これを見たときは???となりましたが、どうやら下のコードと同じ模様

const hoge = (x, y) => x + y;

引数が複数ある場合はこう書けるらしい。

参考: https://stackoverflow.com/questions/32782922/what-do-multiple-arrow-functions-mean-in-javascript

export default の意味

jsファイル冒頭に書くimportで

import InfoTxt from ... import { InfoTxt } from ...

の二種類があり、どうやら

  • export default InfoTxtと書いてあれば中括弧はいらない
  • export const InfoTxt = () => ...と書いたら中括弧は必須

らしい。エラーメッセージにも出てこなくて、ここのエラーでめちゃくちゃハマった。。。

まとめ

AtomicDesginの思想・考え方だけでなく、サンプルを使って実際に手を動かすところまで体験できるのが非常にためになりました。時間が経つに連れ開発環境は変わってくるとため、サンプル付きのものは出版されてすぐ取り組むことに価値があると思います。ただ、すぐに開発に組み込むためというよりも、仕組みをきちんと理解し数年先で活かせるよう一回身体に入れてみるという意味合いでトライしてみましたが、エンジニアの視点を少し理解できた気がします。AtomicDesignを体系的に学んでみたい方は読んでみてはどうでしょうか。

個人ワークだとAbstractが高いのでPlantを使って無料でsketchファイルを共有する

f:id:kenshir0f:20180428230341p:plain
sketchのデータ管理をDropboxだったりgithubだったり試行錯誤しながら運用していたのですが、Plantという「sketchバージョン管理ツール」がお手軽だったのでまとめてみました。

知人とデザインデータを共有して作業したかったので、サクッと導入できてすぐ稼働できたのが個人的にはよかったです。(まだベータ版)
Abstractとの違いも含めてツラツラと書いてみます。

Plantとは?

複数人でひとつのsketchファイルを共有してデザインする時に、同時にsketchを開いていても差分を簡単に反映して作業しできるツールです。

f:id:kenshir0f:20180428221131p:plain

具体的な特徴としては

  • 複数人でも無料プランで始められる(5人までいける)
  • pluginを入れるだけで簡単に始められる
  • sketchだけで完結できる
  • コンフリクトの差分が視覚的で分かりやすい

ざっくり使い方

pluginをインストールすると出るツールバーでだいたいの操作ができます。 f:id:kenshir0f:20180428222349p:plain

アップロードが簡単

手元で加えた変更を共有したいときは[↑]のボタンを押すとメンバーにデザインを共有できます。
メッセージで更新内容を伝えられるので共有される側は簡単に理解しやすい。

f:id:kenshir0f:20180428222036p:plain

手元に変更を反映させるのも簡単

メンバーの誰かがデザインをアップロードするとツールバーの[↓]にバッジがつき、クリックするだけでメンバーのデザインを手元に反映できます。
f:id:kenshir0f:20180428224237p:plain

メンバーが作ったデザインが手元のデータと変更箇所が被ってなければ、手元のデザインを残してそのまま編集を続けることができます。

f:id:kenshir0f:20180428224414p:plain

ただ反映させる時プレビューが出ないので、何を変更したかはやり取りする必要がありそう。。。 まだベータ版なので今後に期待。

コンフリクトした場合は?

メンバーが変更したデザインが手元のデザインと被っていた場合は反映することができません。

f:id:kenshir0f:20180428224936p:plain

そのときは反映したいアートボードを選択(もしくは修正)して、採用しない方を削除することで解決できます。

選択前

f:id:kenshir0f:20180428225058p:plain

選択後

f:id:kenshir0f:20180428224944p:plain

これが分かりやすくてめちゃくちゃ便利だなーと感じました。

abstractとの比較

同じバージョン管理ツールとして有名なのがAbstractですが、Plantはとにかく無料で使えるのが素晴らしいです。
Abstractは機能がしっかりしている分設定などの導入コストがかかりますが、Plantはそこら辺がなくパッと初めてすぐに共有できます。

つまづいたところ

最初にProjectを作るときは 「Plugins > Plant > New Project」からしか作れないため
他のアプリケーションと比べ分かりづらいなと感じました。

f:id:kenshir0f:20180428225624p:plain

(pluginに全部収めたいという気持ちがひしひしと伝わってくる...)

まとめ

お金をかけずに個人ワークでサッと共有するにはかなりよいと感じました。
業務でも十分使えると思ったので、sketchのバージョン管理で悩んでいる方は試してみてはいかがでしょうか。

Bonfire Design #3 「小さく始める新規事業のデザインシステムについて」登壇してきました。

先日Yahoo!さん主催のbonfire design #3というイベントに登壇してきました。

デザインシステムとは、ブランドからUIコンポーネントまで体系的にデザインを統一するための仕組みを見える化したものになります。

立ち上げから関わっている新規事業のデザイン全体を体系的にまとめる取り組みについてざっくりと喋りました。

登壇資料

発表してきた感想

他の登壇者ではサイバーエージェントさんやレバレジーズさん、Yahoo!Japanさんなど、既にあるサービスにデザインシステムを導入する話が多い印象でした。 中でもサイバーさんのAtomic Designの話は僕自身よく理解できていないところもあったので非常に参考になりました。

逆にゼロから実際に作り始めている事例は僕だけだったからか、発表後は色んな方から具体的にどう進めたらいいかなど相談に乗ることが多かったです。 ちなみに、聞きに来ている人の8~9割の方の会社ではデザインシステムをまだ導入していないということでした。(デザインシステムやっている人!の挙手で確認していた感じ)

ちょっとびっくりしたギャップ

弊社ではサービスのほぼ全てに関する議論をgithub上でするのでコミュニケーションの仕方で問題を感じたことはなかったですが、 僕が話していた他社さんではディレクターとデザイナーとエンジニアでコミュニケーションツールが違ったりしていて議論がしづらいという話が多かった印象です。

当たり前になりすぎていて気づかなかったですが、githubにログを残すの今のところは最適解な気がしています。

グラレコが可愛かった。