Recommended
More Related Content
Similar to エンジニアのためのSketch入門 vol1
Similar to エンジニアのためのSketch入門 vol1 (20)
Recently uploaded
Recently uploaded (9)
エンジニアのためのSketch入門 vol1
- 8. どうしてこんなことが 起きるのか • 1. 目的（解決すべき問題）が明らかになっていない • 3. 必要なコミュニケーションが不足している＆依存 • 2. 考え方のプロセスの違いの配慮不足 8
- 9. 1.目的（解決すべき問題）が 明らかになっていない 「いい感じによろしく」 ＝ 半ば丸投げ 誰に・・・ログインしていたユーザーに 何を・・・通知を なぜ・・・ログアウトしたかどうかがわからない 9
- 10. 解決したい問題を言語化する ログインしていたユーザー が ログアウトした ことがわかる 通知にすること。 →次にすること: 通知を共通化・統一をする 10
- 12. ディテール？オブジェク ト？ コードが書けると、部品から作ってレゴブロックのように積み上げ るという Atomic Design 的な考え方は当然と思えるかもしれませんが、 デザイナーはどちらかと言うと全体から考える傾向にあります。大 まかな構成、つまりレイアウトを考えてから少しずつ中にあるパーツを作り 込んでいきます。 タイポグラフィ、ボタンといった最小単位の部品を作っ てから、大きな構造を積み上げていくという考え方とはまったく逆の思考に なります。 「部品を作りましょう」と指示しても手を動かせないデザイナ ーがいたとしても、それは才能がないからではなく、逆立ちして作れと言わ れているように聞こえるからだと思います。この思考のすれ違いが、エンジ ニアとデザイナーとの間に溝を作っているのではないでしょうか。これを放 置したまま、ツールに頼ったとしても、それは小手先の解決にしかなりませ ん。 協働のためのデザイン思考の再構築 (http://www.yasuhisa.com/could/article/ddd-ooux-job/) より
- 13. 3. 必要なコミュニケーションが 不足している＆依存 結論: 共通の題材があれば良い → 3分くらいで作って共有 → あっさり解決 考え方のプロセスが違っても、 共通の題材があれば収束する 13
- 16. SKETCHの良さ • なんとなく触って、なんとなく出来る • 慣れてくるとしっかり作れる • プラグインが豊富 16
- 21. 基本の使い方の話 1. ページ 2. アートボード 3. レイヤー 4. シェイプ 5. シンボル 21
- 22. 作ってみよう 22
- 24. まとめ・振り返り 24
Editor's Notes
- みなさんこんばんは。 本日はお集まり頂き、ありがとうございます。 まさかこんなに反響があると思っていませんでした。 元々は、内輪で勉強会をしようという趣旨のものでした。 勉強会自体は、参加することもあるのですが、実は主催・登壇するのは初めてでして、 期待に添えるか、満足していただける内容にできるのか非常に不安で、緊張しています。 初回では、ご期待に添えないかもしれないですが、どうか、暖かくお付き合いいただければと思います。 それでは、本日はよろしくお願いします。はじめましょう。
- さて、登壇する私ですが、川口と言います。 GoodMoneygerという会社で、Web系のエンジニアをやっています。 いろいろ経緯があって、デザインも多少やるようになりました。
- さて、エンジニアのためのSketch勉強会ですが、これには狙いがあります。 簡単にいうと、良いプロダクトを育てましょうということです。 良いプロダクトというのは、「誰に」「何を」を非常に考え抜いて、余計な要素を省いた持続可能な仕組みを持った製品だと私は思っています。 価値ともいいます。
- 大事なのは、この担当者が悪いというわけではないということです。 実装上の都合にも問題はありましたが、
- 今回の例はすごく軽微なズレだったのですがこういったちょっとした認識のズレが大きな手戻りになった経験はきっとありますよね？ 考えられる問題は3つあります。
- まず今回の通知の例だと、解決すべき問題という問題設定自体が非常に雑だったのですね。 ログアウト後に出現するフラッシュメッセージが出ないというのが問題で、いい感じによろしくという半ば丸投げでした。
- 言語化するとこうなります。 ログインしていたユーザーがログアウトしたことがわかるようにすること。 当然、わかるようにするためには、この通知というのが重要な何かを伝えているとユーザーが学ぶ必要がある。 そうなると、世界観を統一していく必要があるし、できれば見たことがあるという状態を作るのが望ましいはず。
- アトミックデザインだとか、デザイン思考だとか、考え方のプロセスは多様性があってもいいはず。得意とする人が得意とする領域でやればいい。どちらかという話ではなく。 そのためには、やはり共通の題材・たたき台があると認識のズレや齟齬に気付きやすい。
- で、開発しているとですね。 この手の問題がたくさん起きるわけですね。場合によっては些細なことから揉めたり、俺の仕事じゃねーと言い始めたり、果たして、ユーザーへデリバリーする前に揉めてしまうのが 「良いプロダクト」につながるのか？という話です。私は遠いと思いました。
- この課題を解決するにあたりで昔触ったのが、Sketchだったというわけ。 昔は買いきりで、安くて、学習コストが低いものが良かった。 パッと作れて
- これは、信じましょうという話と実際の話ですが、こうらしいです。 今回は基本ルールまで言い切れないので基本ルールの話は省略してます。