hiromitsuuuuu.log();

to see more to see.

わたしがスケッチノートを書くときに考えていること

f:id:hiromitsuuuuu:20181212212147j:plain

最近、たまにスケッチノートやグラレコのやり方を教えて欲しいと言われることがあるので、普段書くときに考えていることをまとめてみようと思います。

前提:どんなものを書いているか

これまで勉強会ブログはテキストで書いていました。テキストベースだと内容を表現仕切れなかったり、あとでまとめるのが面倒になって下書きを詰んでしまうので、勉強会レポートの代わりとして描くようになりました。色々なセッションの中でも、

  • リアルタイムなもの(勉強会や講演のレポート)
  • 資料が出回らないもの(トークセッションとか)
  • 資料にテキストがなさそうなもの
  • 自分が興味があり、前提知識が分かる分野のもの
  • 図を描いたほうが分かりやすそうな内容

あたりのものを書いています。流石に知見の少ない専門分野はリアルタイムに書けません...。また、フロントエンドの実装など、コードが重要なものは逆に登壇者の資料やサンプルを見たほうが分かりやすいので、概念的な内容の時に描くことが多いです。

使っている道具

最近スケッチノートをするときには、いつもこのセットを持っていきます。

マルマン スケッチブック クロッキーパッド A4 白クロッキー紙 S262

マルマン スケッチブック クロッキーパッド A4 白クロッキー紙 S262

ニチバン マイタックラベル ML-7 13mm×38mm

ニチバン マイタックラベル ML-7 13mm×38mm

マルマンのクロッキーパッドは、描いた後にピリッと剥がしてスキャンできるのがよくて使ってます。机のない会場で膝の上で描ける&40分セッションを1枚にまとめるのがA4くらいでちょうどいいです。黒ペンが2本(細/中)、色ペンが2本(寒色/暖色)が私の最小構成です。

膝の上で書くことが多いです。基本左手に他の太さのペンを持って右手で書いてるのですが、使わない他のペンはすぐ取れるようにゲストパスのストラップにぶら下げたりしてます。

ラベルシールは間違ったときの修正用です。修正テープだと、ペンの色が乗らなかったり広範囲を消せないのでラベルシールを使ってます。小さなミスなどはちぎって貼ったりしてます。

(最近iPadApple Pencilを買ったので、使い勝手がよければデジタル移行するかもしれません)

意識していること

これまで書いていた勉強会レポートの代わりが目的なので、「何が話されたか」内容メインのレイアウトを意識しています。会場の中で、大きな紙にリアルタイムに描くようなグラレコだと、もっと表現系に寄せたり、講演者を際立たせる場合もあると思うので、構成は目的によります。

似顔絵は、そのノートを見返すときに「そういえば眼鏡かけたキリッとした人だったな」とその人の特徴を思いだせる最低限に留めるようにしています。凝りはじめると、セッションについていけなくなるので気をつけています...(絵を描くのは好きなのでついお絵かきが楽しくなってしまう)。

あと、「ふきだし」を使いすぎないこと。ふきだしを描くとそれっぽくはなるのですが、ふきだしである意味がない場合もあるので、ユーザーのコメントや、登壇者の感想などに使うようにしています。

セッション中に考えていること

セッションが始まる前には、セッションタイトルだけを書いて準備しています。セッションが始まってからはだいたいこんなことを考えながら書いています。

どんな流れで話が進むのか

プレゼン資料の構成は大体以下のようなものが多いと思うのですが、

  • タイトル
  • 自己紹介
  • 目次
  • 導入
  • 本編×何個か
  • まとめ
  • +αの告知など

特に目次の部分をちゃんと聞くようにしています。話したいことが何個あって、どういう構成になっていそうかを確認して、「紙面上のゾーニングは3つくらいか~」 などレイアウトの見立てを立てています。

各情報ブロックの中でのキーワードは何か

本編に入ると、各章に分けていくつか主題となる内容が話されると思うのですが、その際には、

  • 資料の中でハイライトされているキーワードはないか
  • 資料に書かれていない口頭での重要そうな補足、エピソードはないか

に注目して言葉を拾っています。長い文章で書かれていても、重要なキーワードさえ拾えれば一覧化したときに大体雰囲気がつかめると思っています。また、資料が公開されても口頭で補足されたような情報は、その場でしか聞けない貴重な情報なので重要そうなら拾うようにしています。

情報の関係性

紙面に情報をまとめるときには、話されている情報がタイムライン型の情報か、並列な情報かなど、情報同士の関係性を気にしています。歴史の話なんかはタイムライン、「気をつけること」などは順序のない並列な情報です。

タイムラインの場合は年をプロットしたり、流れの場合は矢印で表したり、順序つきリストには番号を振ったり...並列な関係はフラットに並べたり。UI設計の考え方とちょっと似ています。

登壇者の言葉をそのまま書く

「ノート」なので、テキストを書く際にはできるだけ、感想や解釈を入れずにそのままを書くようにしています(逆にイラストには私の印象や解釈が入っています)。

セッションのあとにやること

私の場合、セッション中には黒ペンしか使っていません。そのため、セッションが終わった直後は、だいたい色が全然ついてない状態です(彩色している暇があったら内容を聴きたい)。セッションの合間にだいたい10分~15分の休み時間があるので、その間に色をつけて写真を撮ってTwitter にあげてます。

色相環上で反対になる色を使って色をつける

私はオレンジと青とか、緑っぽい青とピンクなどを使っていて、寒色をベース色に、暖色をハイライトに使うようにしています。色にもよりますが、2色以上使うと画面がうるさくて何の情報が重要だったかわかりにくくなるため、この2色にしています。追加で入れるとしても無彩色のグレーを影に使うならいいかなくらいです。

そのセッションの中で重要だったところにハイライトを引く

色をつける順番は、ざっと紙面を見渡して、

  1. 大きなブロックの見出し
  2. セッションの中で重要そうだったところ(暖色のハイライト)
  3. その次に重要そうな情報やイラスト(寒色の色面やライン)
  4. 情報ブロックの区切りが分かりにくそうなところに罫線をひく

の順番で進めることが多いです。最後に色をつけるのは、セッション中にハイライト(暖色)を引いてしまうと、後で出てきた情報のほうが重要そうだった場合に紙面全体で重要度の高いテキストが増えてしまって、一覧で見た際に重要そうなものばかりになるのを避けるためです。

わたしにとってのスケッチノート

スケッチノートを描くようになってから、ブログの下書きを積むことが少なくなりました笑。セッションの内容を思い出したり、人に説明するときにももぱっと全体を見渡せて便利です。聞いたことをテキストでアウトプットするか、図を含めた手書きノートでアウトプットするかの違いでしかないと思っているので、たまに仕事でも報告書としてそのまま共有したりしています。

テキストでも図でも、私のフィルタを通して取捨選択した情報なので、ノートを見れば意図がすべてわかるとも思っていなくて、あくまでも一次情報が大事だと思ってます。最近、自分にとってスケッチノートは一次情報を広めるための布教活動というか、レポートなんだろうなというのがしっくりきています。「こんな勉強会に行ってきてこんなに楽しかった!役立つ情報があった!」を伝えるためのツールのイメージです。

あ、あと、元々構造化されている発表内容を、ストリームで聞いて、再び構造化するので「聞く力」と「情報を構造化する瞬発力」はつくと思います。情報設計の筋トレに役立つ...かも。

そういえば先月、東京から福岡の勉強会にオンライン参加したのですが、その時に書いたスケッチノートをTwitterにシェアしたときにとてもインターネット的で素敵だと思いました。リアルタイムで、場所も関係なくて、リッチな情報がオープンに共有されるのが、とてもいいなと。

Frontend Conference Fukuoka 2018に行ってきたよ

Frontend Conference Fukuoka 2018に行ってきました!(まだ福岡にいます)

福岡に6年ほど住んでいたこともあり、最近の福岡はどんなになってるか気になって遊びにきてみました。貴重な福岡のカンファレンスのチケットを確保した代わりにスケッチノートを描いたので資料と一緒にまとめておきます。

frontend-conf.fukuoka.jp

2019年までに見直しておきたいCSSJavaScriptの手法

speakerdeck.com

memo

特にJSは知らない仕様がたくさんあった...! 配列内の要素チェックするincuseとか、ゼロパディングのpadStartとか。ライブラリ入れたり自分で実装してたやつが仕様になってJSネイティブで使えるの便利。関数合成とかnull値アクセスのチェックは、確かに便利だけど私の知ってるJSじゃない...w

スポンサーセッション ディーゼロ & ヌーラボ 「これからのWebアプリケーションに求められるアクセシビリティの設計と実装」

memo

Backlogのアクセシビリティ実装をどう進められているかのトークセッション。アクセシビリティ対応めっちゃしっかり取り組んでるのが素敵でした!「電話だったらどう伝えるか」という考え方めっちゃいい。

500日のトライエラーから生まれた大規模設計ノウハウ

speakerdeck.com

memo f:id:hiromitsuuuuu:20181211184957j:plain

設計を作り始める前の根本的な設計と、中期の設計と短期の設計に分けて、各段階でどんな視点の設計が重要か語られていてとても参考になりました。最近1週間スプリントで月次リリースを回しているので「ソフトウェアは建築というよりガーデニング」というのが沁みました。。。チームのメンバーが設計してた部分を根本・中期・短期にわけて見れそう。

仕組みを作る仕組みを、作る仕組みを作る

memo

web2.0からの流れの話があったのですが、ふりかえって見るとデバイスとWebの進化が合わさってだいぶ遠くまできたんだなと思いました。ウェブは誰にも所有されない唯一のプラットホームというのがエモかった。

かんそう

福岡勢がとても楽しそうで、よいカンファレンスでした!フリードリンクにパーカーのお土産までいただき、ホスピタリティがすごかったです。SNS班もカメラ班もなんか色々福岡の運営が素敵でした。懇親会チケットが買えなかったのがざんねんだった〜!

10年くらい前に私が学生として福岡をうろついていた頃は、技術系のコミュニティも小さな活動しかなかったイメージがあったのだけど、こんなカンファレンスが開催されるくらい盛り上がってきてるんだな、福岡いいなってなりました。ちょこちょこ様子見に帰ってきたい。

福岡のカンファレンスでフラフラしてたら「ヒロミツさん!?」て大学の仲間に話しかけられたのが今日のハイライト。10年ぶりの再会を産むインターネッツすごい。古い知り合いとも再会できたし、最近オンライン読書会で繋がった福岡勢とも繋がれたし、東京勢とも久々に話せたし、とてもよかった!

ポエムに呼応するポエム、またはわたしのFictions

いつのタイミングでか、どうやら世の中のエンジニアは技術同人誌というのを執筆しているらしいというのを知った。Twitterのタイムラインでもサークル当選の話題で盛り上がっている。はて、それは一体どういうものかと先日技術書典5に行ってみた。 フロントエンドとUI関連の本はないものかとサークルを周り、Web Componentsの冊子を手に取ると「ひろみつ氏にはこっちの方が合ってると思う、とりあえず読んでみて」とサークル主に勧められた。目次に目を通すと「スペシャリストとジェネラリスト」「真のユーザーファースト」など気になる言葉が並んでいた。

「こっちもください」

特に中身を深く読む必要もなく、目次買いした。Fictionsという、エンジニア達が書いた、よりよいプロダクトづくり/開発のための本だった。How toは書かれていない。けれど、不確実性の高いものづくりに向かう上で、折れずに向かってゆくマインドセットのヒントになりそうな本だった。帰り道の電車のなかで夢中で読んだ。

ここでは気になった同テーマに対してわたしが思ったことを書いておく。ポエムに呼応するポエムの真似ごとのようなものである。

スペシャリストとジェネラリスト

デザインとエンジニアリングの双方を仕事にしたいという指向性のなかで、スペシャリストとジェネラリストどちらになるのか向き合った内容だった。結果として、学び続け移動し続ければどこかにたどり着いてそこが正解になるのではないかと締めくくられていた。

わたしもずっと「技術とデザインを繋ぎたい」とフロントエンドのエンジニアリングとUI設計の狭間で生きている。志した新人の頃は「ジェネラリスト」になるのだと意気込んでいたが、領域を越境するにつれ個々の領域の浅さに不安感を感じ、スペシャリストとジェネラリスト問題がでてきた。けれどわたしの網羅領域と同じひとはどれだけいるのか考えたら、それが専門性とも言えそうだと思って両方手放さずにここまでやってきている。(だけどここ1年くらいはコードがかけていない)

エンジニアリングとデザインに限っていえば、ふたつの領域は地続きであると信じている。きっとプロダクト設計のスペシャリストにわたしはなりたいのだ。最近、デザインエンジニアとか、プロダクトマネージャーとか、過去にはあまり聞かなかった言葉を耳にするようになった。本を読んで、きっと好きに駆け回っていたら、名前がついたりどこか近いところにたどり着けるのかもしれないと思えた。

詐欺師症候群

コンピューターサイエンスのバックグラウンドがないことに対する劣等感から、自己肯定感がなく、求める状態と現実の大きなギャップが原動力となるという話だった。

まるで自分のことかと思った。自分には芸術工学修士はある。けれど、学んだ領域の広さと、プロダクトのプロトタイプ発表で卒業したからか、学術的なバックグランドの裏付けをもって深く研究していないのではないかという後ろめたさを感じている。もうひとつは、プロダクトコードやプロダクトUI設計の打席数だ。分野を越境しすぎたせいで同じ年数の実務者に比べて、自分のアウトプットは少なく精度が低いのではないかと思い込んでいる。

まわりのコミュニティの知り合いや同僚はなぜか肯定してくれる。ありがたいことだ、否定しては認めてくれている方々に失礼だと思いつつも、自分はもしかすると周りが思っているよりもずっとレベルが低い詐欺師なんじゃないかと不安が掠める。

同じく、このギャップがわたしの原動力になっている。「自分ができると信じている、自信満々だね」と同期は言う。いつか本物になれると信じて、努力を繰り返す。

真のユーザーファースト

プロダクト開発をするなかで、営業からエンジニアまで様々な専門性・立場の人間の意見をいかに理解し、プロダクトの前進に繋がる判断下せるか、どう正しく意思決定を下すかという問いだった。

ユーザーの利益になると考えられた発言のなかには、承認欲求が混在しているものもあるという視点は頷けるものがあった。最近Twitterでみた『「人間中心設計」が、「欲望中心設計」になってしまっている』というのにも繋がるところがある。ステークホルダーのために妥協しなければならないこともあるが、それを続けているとどんどん自分たち都合の機能が増え、ユーザーの利益になる攻めの開発ができなくなってしまう。

いくら越境していても、どこかの判断軸が強くなってしまう。正しいとは何か。大局的な判断をするにはどうすればいいのだろう、わたしも興味がある。

分割統治リニューアル

UIデザインを一新することで、サービスは成功するのかという話。ユーザーの一人としての視点から見れば「リニューアルしてほしい」と思ったことは一度もないと。フルリニューアルは開発現場の改悪や負債を生み、負荷のかかったエンジニアが磨耗してゆく。分割統治し、きめ細かなリニューアルをしていこうという提案。

これはto Bとto CのUIでちょっと変わってくるかもしれないと思った。to B (or in B)では、道具であるシステムの改善によって効率化されて成功(ここでいう成功は、時間の余剰を産んだり業務のミスを減らすことなどである)に繋がることもあると思う。一方、to Cではコンテンツや売り物が主役のサービスである限り、店の内装や棚だけをいくら綺麗にしたところでお客様に届けるのは難しい。商品企画と売り方を一緒に考えないといけないと思っている。フルリニューアルで得られる価値とはどれくらいなのだろう。

リニューアルが成功に繋がるかどうかは置いておいて、改善の粒度は分割統治された方が良さそうだと思う。プロダクトバックログの側面からみても、UIリニューアルに全力を注いでしまうと新機能開発が止まってしまう。ずっと連絡をよこさないで、ある日突然サポートされるより、きめ細かくケアされた方が心持ちが良いのではないか。

デザイナーのように考え、エンジニアとして実行する

プロダクト開発のために、デザイン/エンジニアリングお互いの視点を持って「なぜこのデザインなのか」を考え専門のやりかたで進めようという話。

たまに思うのだが、なぜデザインが上流で、エンジニアリングが下流なのだろう。というか上流、下流という言葉が苦手だ。川下に流れるにつれ、Whyが薄まり作業になっていく。向かう課題は同じはずだ。エンジニアは扱う情報をモデル化し、システムで効率的に扱えるように、デザイナーはその概念をユーザーが理解しやすいように整理して画面に表現するのではないのか。お互いは対等に話せる立場なのではないのか。だからこそ、わたしが設計する際には背景からゾーニング・要素の意図を伝えたいと思っている。

おわりに

触発されてついエモ散らかしてしまった。人を選ぶ本だとは思うけれど、忙しい開発や苦しい時に読み返したくなる本になっていると思った。3人共同で書いた本のようだが、どれを誰が書いたかわからないようになっており、人や役割に紐づかない純粋な文章として読めてよかった。どこかの現場で同じように考えているエンジニアがいるんだなぁ、意識の高い詐欺師にならないように自分も頑張るか、と思った。技術書典お疲れ様でした。

本書が気になった方たちへ。こちらで電子版を買えるみたいです(AmazonKindle版もあるすごい)。

Fictions

Fictions

1000ch.booth.pm

【スケッチノート】「単発受託WebデザインとインハウスUXデザインの相違点・共通点」を聞いてきたよ

8月9日にあった Rikiya Ihara (@magi1125) | Twitter さんが登壇した勉強会のスケッチノートをあげていなかったので貼り付けておきます。

techtomo.connpass.com

受託か事業側かっていうのはあんまり関係なくて、組織とか文化とか得意先との関係性だよなぁとおもた。あと、自分の価値を高めるために、

を組み合わせるって話があり、それって私のカードは

  • アプリケーション寄りのフロントエンド開発
  • HCDある程度回せる
  • UI設計する(サイトよりWEBアプリ寄り)
  • スケッチノート描ける(ちょっとだけファシグラも?)

だけど、あと何のカードがあれば強い役になる!?ってわくわくした!スキルを5枚揃えて最強のエンジニアになろう!みたいなカードゲームできそう。5年くらい前はフロント×UI設計って強い組み合わせ感あったけど、そろそろ手札が弱くなってきている気もするので新しい何かを追加せねばと思った。

ずっとAbout Face3を買おうか迷ってたけど、そういえばと思って探しに行ったら伊原さんが買い占めたせいかどこにもなかったです笑

【スケッチノート】ノン・デザイナーズ・アカデミアに行ってきたよ

「The Non-Designer's Design Book Missing Pages 2018」の冊子版欲しさに、6/26に開催された『ノン・デザイナーズ・アカデミア 〜Design for the rest of us』に行ってきました。

non-designers-academia.doorkeeper.jp

内容は冊子の内容だったのだけど、口頭だと重要なところがより伝わりやすくてすんなり聞けました(´ω`)

後半拾えなかったところもあるけど、メモはこちら。

デザインはPlanning とStyling だという話がしっくりきた。誰に&何のために伝えるのか、情報の構造化→表現の話もあって、みんな本質は近い部分にあるのかもなぁと思った。

あの幻の(!?)ユーザビリティカルタで遊んできた!

6月のとある日に有志で集まってユーザービリティカルタ会をやってみました!

産技大のOBの集まりで、『授業の中で "教示文"という言葉を知らなかったからワード集が欲しい』という話がでた際に『そういえば昔、ユーザビリティカルタっていうのがあってね...』とユーザーリサーチャーの奥泉さんに紹介いただいたのがきっかけ。市販品ではなく、完全な手作りの世界にひとつしかないユーザビリティカルタ!!どんな経緯で作られたものかは奥泉さんのブログに書かれてます。

ユーザビリティ カルタ会:https://okuizumi.jp/blog/2018/06/usability-karuta.html

経緯を聞くと、関わった方達は今では最前線で活躍されている方ばかり・・・そんな方達が同じ場所にいた頃にできたエモいカルタ!2004年のU'eyes Designのブログでも紹介されてます。

usability.ueyesdesign.co.jp

その貴重なカルタで遊ばせてもらいました。よーし、Fbのイベントを立てるぞーと意気込んでいたら奥泉さんがひとこと。

『あ、ちなみに、英語だから笑』

日本語かと思いきや、英語!!! 笑。AはAffordance、BはBehavior model....のような感じで、アルファベット26文字の頭文字のユーザビリティ用語が!

もちろん、読み札も英語!読みは奥泉さんにやっていただきました。流暢な英語でスラスラと読まれる札・・・

26枚だから余裕でしょ!という期待も虚しく、読み札の英語に「ん!? ん!? もう一回お願いします!! 」と戸惑う英語に不慣れ勢笑。英語が余裕な同期が「自分は(すぐわかっちゃうから)ここにいたらだめな気がする」と遠慮する始末w 「The Model...」で始まるからきっとモデルの話だ!とTOEICのリスニング状態になってましたw

RITEメソッド!これは樽本さんのユーザビリティエンジニアリングで書いてたやつだ!という進研ゼミ的瞬間があったり、奥泉さんのかっこいい英語が聴けて個人的には非常に満足でした。

ちょっと用語が古くなってるから2019年版を作ろうとか、クラファンで募って量産しようとか、HCDに関わる人たちのキャリアを模した人生ゲーム作ろう!(HCDを学んだけど社内でから回るとか、プロダクトオーナーになるとかetc...)とか、スゴロクにしようとか、アジャイルで作ってユーザーテストを重ねていこうとか妄想が広がりました。興味のある人はSNSで捕まえてください笑。

DevLOVEの「Atomic Design ~堅牢で使いやすいUIを効率良く設計する〜」に行ってきた

6/29(金)に開催されたDevLOVEのAtomic Design回に行ってきました。

devlove.doorkeeper.jp

『既存のフローからアップデートする アジャイル・デザインフロー』というタイトルで、アジャイル開発を進めるうえでのUI変更に強いデザインフローについてのお話でした。

Atomic Design本には結構コードが書かれているんだけど、今回はコードの話ではなく、何故Atomic Designの考え方が必要なのか、Atomic Designの構造をどう考えていけばいいか、@ygoto3_ さんが実践してるデザインフローができるまでのステップの話がありました。

内容はスケッチノート置いておきます。

どう分割するかがいまいち理解できていなかったけど、ユーザーの行動と合わせて責務で考えるのがすごく分かりやすかった。スケッチノートに書いてる今までのデザインフローでまだやってるんだけど、構造の情報が抜け落ちていてもなんとなくデザインカンプができたり開発を進められたりして、なんでデザインカンプドリブンで進めてしまったんや・・・ってなることめっちゃある。。。

Atomic Designに限らず、最近どんどん構造とユーザー視点が大事になってきていて、エンジニアとデザイナーが概念で会話する世界になってきてる気がする。フレームワークを真似しただけではどんどん置いてけぼりを食らうんじゃないかと危機感を感じた。どうやってこういう文化が浸透していったのかがきになる。

Atomic Design本はこちら。買って積んでるから7月のでかいリリース終わったら読むんだー

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

Atomic Design ~堅牢で使いやすいUIを効率良く設計する