個人サービス開発のデザイン、と note.mu へのラブレター。
## 重要事項説明
この記事は下心15%と、久しぶりに対外発信したいと思った気持ち85%からできています。
## はじめに
SNSでは、@vsanna2 だったり、@vsanna という名前でひっそりと生活しています。インターネットサービスが好きなイチwebエンジニアです。
noteには個人サービスを開発して思うことをつらつらと書いてみようとおもっています。
個人で開発して楽しいこと、辛いこと、工夫していること、夢見ていること、いいこと・悪いこと、面倒なこと、などなど書いてみたい。続くといいな。
今回は2つの意味で「個人開発のデザイン」について考えていることをまとめたいとおもっています。
サービスにおけるデザイン、という話と、個人開発活動自体をどう設計するか、という話のふたつです。
その前に...
...
......
.........
## 個人開発でなにをしているの?
2年弱ほどちまちまと個人で Issus(イシューズ) というノートサービスを開発しています。
こんなかんじ。
最近書いた、ひとに説明するための資料がこちら。
詳細なコンセプトや、なぜいまノートサービスをやりたいのか、というのは別のイシューにまとめています。
(良ければ issusの提供価値を再整理 や なぜいまノートサービスなのか、を言葉にしてみる。 を読んで貰えるとうれしいです :) )
要約すると
1. 趣味や個人の研究にもっと時間を使うようになる(使えるようになる)未来がくるはず
2. そういった「個人をサポートするツール」を作りたい
3. 個人的にノートを書き溜める、ノートを書いて思考を整理するというアクションがとても好きなので
気づいたらノートサービスを作っていた。
だから、
- 課題
- ノートが散らばる
- 拡張子の異なるデータを纏められない
- ノートのつながりが見えない
- 一度書いたノートを活用できない
- 解決策
- 集約: 集中できる入力画面。すぐに投稿できる設計。フォーマットの多様性。
- 再構成: 縦横軸でノートをつなげ、ノートの再構成を促すマージ機能 / 削除提案機能
こんなことをしたいと考えて少しずつノートサービスを作っています。
...
......
..........
## 個人開発のデザイン。
さて、冒頭に戻って「個人開発のデザイン」について書いてみたいと思います。
おさらいですが、個人で開発するサービスにおけるデザイン、という話と、個人開発活動自体をどう設計するか、という話のふたつです。
### 個人で開発するサービスにおけるデザイン。
私はデザイナーに憧れがあるものの、その専門的な訓練は受けたことのないwebエンジニアです。
ただ幸いなことに、新卒時の先輩であるデザイナーの方から何度かレクチャーを受ける機会に恵まれました。そのときにデザインの大原則として こんなこと とか、こんなこと を学びました。
いわゆる 近接 / 整列 / 強弱 / 反復 というやつです。
とはいえ、仕事としてデザインをしたことはほぼなく、そのためデザインについてはあまり得意ではありません。
それでもせっかくユーザーに使ってもらうのならば気持ちのいい使い心地を体験してほしいと考えています。そのためにデザイン面でもできれば手を抜きたくはない。
その結果取り組んでいることを、精神論・具体的問わずかきあげてみるとこんな感じになりました。
- デザインの原則を学び、
- 他サイトを「目的意識を持って」まねてみて、
- 画面 / パーツごとに意図を明確にした上で強めたい箇所を極力絞り、
- 「このサービスではこういうデザインをしてよい」というルール作ってそれを極力守り、
- ひとからのフィードバックを必ずうけ、
- でも今詰めすぎずにいまのデザイン力を受け入れる。
中には「当たり前だよ」と思われるものもあると思いますが、どこかで個人開発をしている心の友のためにできる限り絞り出してみます。
#### デザインの基本を学ぶ
オススメの記事と書籍です。
- 近接 / 整列 / 強弱 / 反復 を学ぶ
- https://bulan.co/swings/design4principals/
- 『7日間でマスターする レイアウト基礎講座』
- 『レイアウト、基本の「き」』
- 『デザインの教室 手を動かして学ぶデザイントレーニング』
#### 他サイトを「目的意識を持って」まねる
- いろんなサービスに触れるには product hunt chrome extension がオススメ
- 踏み込んで学ぶには、そのデザインの意図を考えながら サービス / ツールをみる
- 例えば、今作りたい機能と類似したものを探すときは普段以上に目が良くなる(気がする)
- ex: 既読/未読 => Gmailを参考にしてみる。このときは普段Gmailを見るよりもいろいろ気づける
- そしていいなと思ったものは徹底的に真似する
- 徹底的にその1 = 手元でまるっと同じ見た目のパーツを作ってみる(結構楽しい)
- 徹底的にその2 = パーツを汎用化し、コンポーネントとしてmodifierを作ってみたりする(すごく楽しい)
- 近接 / 整列 / 強弱 / 反復 が体に染み込むように理解できてくるか。1pxのズレにこだわりたくなる気持ちが生まれてくるはず。
#### 画面 / パーツごとに意図を明確にした上で強めたい箇所を極力しぼる。
- 4原則のうち、「強弱」に着目して強める引き出しと、弱める引き出しを増やす
- (ユーザーには)これに気づいてほしい、これを考えてほしい、これをしてほしい、という「してほしいこと」は何かを画面単位・パーツ単位で考える
- それに集中してもらえるためのパーツを目立たせて、それ以外を控えめにしたい。
- でも以外にやろうとすると案外難しい(他のパーツとワチャワチャする)
- そうしたら...
- 強化: 大きくする / 他と離す / 色をつける / 動かす / とりあえず光らせとく / コントラストつける ...
- 弱化: 強化の逆 + 強い意志で(もしかしたら必要かもしれない、くらいのパーツまでも)削る
- 特に削ることが難しい...
- 目立たせない場所であれば、突飛なデザインはさけてできるだけ他サイトでも使われているデザインに寄せる
- 説明せずとも「こう使える」と思わせられる
- デザインで独自性をもたせたい、とは思っていないので巨人の肩に乗る
#### 「このサービスではこういうデザインをしてよい」というルール作ってそれを極力守る
- 画面を作るときに(ゆるく)ルールをつくる
- 利用できるパーツ(class)を制限する
- panel, list, button, label(tag)など汎用的なものは共通化する
- このあたり、bootstrapなどをみて必要そうなパーツを頭にいれておくとよい
- cssで利用できる値を制限する
- サイズ・レイアウト: 原則8pxの倍数をwidth, height, margin, paddingに用いる
- $base-scale: 8px を各所で使ってます
- 色: #xxxxxxを自由に使わず 、予め用意した色変数を使う
- 形: border-radiusの値も2パターン程度にとどめる
- duration: 固定数種類をつかう
- $default-duration: 0.2s
- $fast-duration: 0.4s ... の用な感じ
- とはいえ、無理しすぎないこと
- こうなりたいという姿はあっても、一人で全てはできないし、できる技術もない。
- そう思い始めると開発自体のモチベーションも下がるので、これはこれで味だなとたまには自分を許してあげる
#### ひとからのフィードバックをうける
- 加えた変更を公開する前でも後でもできる限り第三者の目から評価してもらうようにしています
- かならず新しい発見があり、改善点が積み上がっていくのでやって損はありません
- これまで聞いてよかった質問
- (既存ユーザーに対して)「いままでの機能使いにくくなってない?」
- (まだ使っていない知人に対して)「これどういう意味かわかる?◯◯してみてもらっていい?」
- もらった意見は全て大切にしつつ、次の工程を経て反映させています
- 一旦寝る
- 共通の原因で発生している意見は無いか考えてみる -> あればまとめる
#### でも、こんつめすぎずにいまのデザイン力を受け入れる。
- デザインで気をつけていることの最後に書いたことと重複しますが、こんつめすぎずに徐々に改善するしかないということを受け入れることをおすすめします
- これはスタートアップだとおそらくダメな考えなのかもしれませんが、個人開発は改善速度よりも継続、すなわちサービスが止まらないことのほうがユーザーに対してまず大事なあり方だと思っています。
- 途中打ち切りのSS小説にいままで何度泣かされてきたことか...
- なので、落ち込んでもあんまりくよくよしないと自身に言い聞かせるといいとおもいます。
...もっと書きたいことはありますが、まだきれいに言葉に落とし込むことが難しいようです。
また別のnoteに書いてみたいと思います。
さて、ここで書いたことは「見た目」の話が8割方でした。もっと大事なこととして、この手前に情報設計(IA)という作業があります。
画面 / パーツごとに意図を明確にした上で強めたい箇所を極力しぼる、においてそもそも何を強めるのかを判断する上で大事になる工程だと理解しています。
これについては IAレイヤーでデザインの会話ができる組織は、うまくいく。説。 がとても詳しいのでオススメします。この領域はもっとこれから体得していきたいと考えているのでよい訓練方法などあればぜひ教えてください。
## 長くなりすぎたので...
長くなりすぎたので、 個人開発活動自体をどう設計するか については記事の反応をみて別記事にまとめ直したいとおもいます。
- 個人開発の同期
- 個人開発のモチベーション
- 個人開発で腹の立つこと
- 個人開発の時間づくり
- 個人開発の費用感
- 個人開発のユーザーヒアリング
- 個人開発のマーケティング(知ってもらうこと +CSすること)
- 個人開発の開発環境
あたりを(もしかすると個別に)かければいいなと思っています。
ぜひ冒頭で紹介した Issus(イシューズ) もお試しいただけると嬉しいです。
ご意見やご感想などをいただけることが一番の個人開発者のエネルギー源ですので、どんな些細なことであっても伝えていただけると嬉しいです!
...またもしよろしければ twitter も(大したことつぶやいていないですが)フォローお待ちしております:)
...
......
.........
## さいごに: note.mu へのラブレター。
Issusは個人のためのサービスを志向していて、公開を前提とはしていません。
なのでIssusでためた内容をまとめ上げ、推敲し、誰かに見てもらいたいとおもったユーザーさんにはnote.muさんやはてなブログなど、適切な場で発信してもらうことを推奨しています。
note.muの開発スタイルとして、開発の過程を明らかにし、常にユーザーとコミュニケーションする姿にとても共感しています。コンテンツを愛し、それをいかに人の目に届けるかという姿勢がプロダクトに埋め込まれていることを実感しています。
ぜひ一度note.mu運営の方とお話ができたらすごく嬉しいと思っているのですが、そのような機会がいただければぜひお会いさせてください!
(最後の章が不適切であればいつでもご連絡ください :bow: )
長文に最後までお付き合いいただき、ありがとうございました
好きです