UI Live ! in Kanazawa に参加してきた
90c0ba03fdaf930c0a4048bb06.doorkeeper.jp
まとまらないまとめ
インハウスデザイナーの新規事業開発での動き方
elmyとCuncableのデザイン。
クライアントワークスと、インハウスの違い。
クライアントワークス
- 作業分担されている。（ディレクタとかデザイナとか、エンジニアとか）
- デザイナはディレクタ→代理店→クライアント（窓口）→クライアント（社長）
- 鶴の一声でひっくり返る
- ゴールが、前提や関係者で変わる。
- UIデザイナ→サービスデザイナへの興味
インハウス
- コストをかけず、スピーディーに。
- 1チーム3人前後。意思決定スピートが早い。
- ビジネス・デザイナ・エンジニア
- 理解力・決断力が必要。
- 役割の制約を作らず、できるところまでやる。
- 最短のリリースを目指して全員が動く。
- ビジネスの人と同じアプリを使ってみる。
- iOS/Androidのガイドラインの違いを考慮。
- デザイナがXcodeを学習。（StoryBoardを使ってる）
- GAなどで定量分析、ユーザ心理を定性分析。
- PDCAを回し、壊すことを恐れない。
まとめ
- インハウスのいいところ
- スキルの幅が広がる
- 本質的なモノ作り
- ユーザの声をそのまま聞ける
- DeNAでは100名ほどのクリエイターがいる。切磋琢磨できる環境。
質疑応答
- クライアントワークでは、いろんなものを作れ、経験にはなる。
- Xcodeを使うにあたって、まずは心理的ハードルがあった。
- 毎日数時間とか、ちょっとずつやることで、ハードルが下がった。
- GUIで直せるのが良い。
- エンジニアがsketchを勉強したり、相互に歩み寄る姿勢が大事。
- 属人性は社内勉強会で、ワークショップしてみたり。
- ビジネスとは、同じアプリを使うことで、共通言語を増やす。
- 毎日30分とか話す。
- XXアプリのYYの画面、とかって言える。
- 読んだ記事、本を紹介し合い、互いの理解を深める。
- 新規事業でユーザの学習コストを減らすため、一般的なアプリを使い、そのデザインを盗む。
プリプリしないアプリ開発
www.slideshare.net
動画配信アプリなどの開発。
アプリのデザインは経験1年ぐらい。
人任せにするから、プリプリする。 そうなる前に、デザイナが出来ること。
- アプリ開発の流れ
- デザイナ・ディレクタ・システムエンジニア
- 画面イメージを決定する際に、システムの人間が関与する方が良い。
- イメージ決定する際に、デザイナからシステムさんにも承認を得る。
- パーツ書き出し
- デザイン：パーツ受け渡し用のスプレッドシートを作る（画面ごとにタブ）
- デザイン：画面イメージをそこに貼る
- システム：欲しいパーツを書いていく（ファイル名も決める）
- デザイン：パーツ書き出し
- デザイン：基本のトンマナはシート分け、画面イメージに追記していく
- システム：確認し、問題なければ終了
- アプリ実装で、デザインが確認してない。
- 毎日、作られた分を確認し続ける。
質疑応答
- 反省会を開き、そこで改めて相談することで、今回の解決策を思いついた。
- 次のアプリでは、今回の解決策を適用して、上手く行った。
- アプリの動きについては、文字ベースや口頭で伝えている。
- 文字だけでなく、質問・回答しやすい状況にする。
良いUIをエンジニアに作ってもらうために、デザイナーができること
www.slideshare.net
デザイン5年、フロントエンド1.5年
運用・改善をしていくサービスのUI、良いUIを作り続けることが、今回の対象。
デザイナもエンジニアも、担当領域が違うだけで、作るものは同じ。
デザイナの仕事は、PSDを作ることではない。
どう実装されているか、エンジニアが何を考え行動しているか、を知るべき。 デザイナが頑張るところなのか、エンジニアが頑張るところなのか。
UIデザイナが作るのは、サービス。 例：スタイルガイドを作るなど、エンジニアが使いやすいアウトプットを作る。
スタイルガイドの運用・保守はデザイナが行う＝サービス全体のデザイン。
- エンジニアに無理難題を求めない
- 要求を下げるのではなく、手を取り合うこと
- デザイナ語は使わない
- 抽象的な言葉ではなく、サンプルアプリを伝えたりする
- Photoshop仙人にはならない
- 便利なツールがいろいろ出てくる
- 例えばsketch
質疑応答
- 情報共有
- 自分の見つけたものを、必要なチャンネルに共有する。
- それを相互に行う。
- 1つのPSDに情報を詰め込み過ぎない。
「使いやすい」だけではユーザー体験が上げられないサービスでのデザイン手法
Material Designスタイルでプレゼン。
グラフィック→WEB/INTERACTIVE→サービス
iPhone出て早9年 当時は、専門的なデザイナがおらず、エンジニアだけで作っていた。 今では、UIデザイナの地位が確立され、ガイドラインが作られた。
1→2的なグロースハック系は、「使いやすい」というのが役立つ。 0→1的な新規事業では、雰囲気みたいなものが大事。
UI/UXの記事を鵜呑みにして適用しても、うまくいかない。
さんぽジスタを作るときに、「使いやすい」ではただの歩数計になってしまう。
今日の歩数：達成感・やる気を起こさせる。 キャラ：「何が変か」を具体的に調整していく。 背景：画像検索で世界観を知る。
自分で使ってみて、つまらなかったので、コンテンツ追加。ブラッシュアップ。
質疑応答
- 自分で使って、客観的に見る。
- 何か変えてみて、また使ってみる。
- 社内でターゲットになるような人に使ってみてもらう。
- DeNAは、思ってることを言いやすい環境。
- 自分の作ったものに責任を持つ。
- ターゲットユーザがチーム内にいない場合
- まず、インセプションデッキを作った。
- ある程度仮設を立て、作り、ユーザの動きをアナリティクスで見て、拡張していく。
これからの「フロントエンド開発」の話〜（デザイナー所属の）フロントエンドエンジニアでも知っておきたいこと〜
Ui live資料 from Ryota Iida
www.slideshare.net
認証会員基盤のエンジニア フロントエンドのチームリーダー
金沢すきま旅というのを作った。
エンジニア目線な話
UXセミナーのストーリーボードを見て衝撃を受けた。
エンジニアは、細かく検証し、問題があればすぐ修正したい。
Dockerをローカル開発環境として使う。 継続的インテグレーションの流れを、デザイナにも知っておいて欲しい。
質疑応答
- Dockerを布教中
- ハンズオンを開催し、体験してもらう
- GUIもあるおかげか、デザイナ側も抵抗感が少なそう
- ストーリーボードの何が衝撃を受けたのか
- いままでは、完成されたワイヤーから関わっていた
- そのワイヤーに至る理由が見えるので、理解できる
フロントエンドエンジニアが、機能開発の企画オーナーとなってリードした話
エブリスタに関わっている。 6年ぐらいあるサービス。
負債が多い状態で走り続けている状態だった。
使いづらいものを、抜本的に改善したいけど、既存文化や技術障壁を考慮する必要がある。
- 現状を分解する。
- 原因を探る。
- 「なぜ？」を問う
- →ガラケーのUIを引き継いでいた
- チームの共通認識とする
- 解決の方向性を定義する
- 他のアプリを参考にしたり
- 解決案を試作する
- プロトタイプ作ってみたり
チャンスを掴む働き方
- 状況を作る
- "何か"を期待して雇われている
- コアスキルを使い、チームが抱える課題・問題を解決する
- 重要なのは期待を超えること
- 圧倒的な能力を持っている必要はない
- チームの課題を、チームメンバーが感じられる状態にする
- 仲間に入っちゃう
- 呼ばれてないけど、MTGに入ってみる
- 他のメンバーが困ってそうな仕事を、会話してみる
- 信頼を得る→期待が生まれる
生存戦略
フロントエンドエンジニアのキャリアパス コアスキル以外のところも鍛えておく。 プライベートで何かを作ってみる。
質疑応答
- 出来無さそうな話が流れていたら
- 自分のできるところまで分解してみる。手伝えることはいろいろありそう。
- タスクのトレードオフ
- コアスキルの部分を終わらせるのが大前提
- 事前に素振りしておくことで、工数を減らして、時間を余らせる
- 上司に相談して、アサインを変える
- 優先度をつけて、今のタスクが本当に必要なのかを問う
- だれにリソース管理されている？
- 個人でタスクをアサインしている。
- 1日5hの作業をタスクとしてあてる。
- 見積もりミスのバッファに使ったり、改善に使ったり。
パネルディスカッション
3年前との違い
- 与えられた情報を鵜呑みにしていたけど、そこから疑問を持つようになった
- ユーザ体験だけでなく、ビジネス的な目線もついた
- コアスキルへの自信がついた
- 受け身だったけど、今は取りに行くぐらいになってる
- 井の中の蛙だったのを今は知っている
- 言ってみたら変わることを知った
会社間で聞きたいこと
- キャリアプラン
- デザイナ・フロントエンドエンジニアの不可侵領域
- 入ってきてほしくないと言われることが多い。作業に入る前に確認する。密にコミュニケーションをとる。
- 色を変えるとか、簡単なものはしてもらっている。
- デザインしてもらいたい。意見も欲しい。元々の理屈はあるけど、気づかない視点もある。
- サービスデザインは論理的に出来ている部分が多い。
- いちユーザとしての意見は欲しい。
- てきとーに作業はしてもらいたくない。
- 自分が責任を持てるところまで踏み込む。
- システムからの意見はうれしい。
- 知識としては、領域外のこともしていくべき。
- 領域外のことをすることで、作業効率が上がるかも
- もっと踏み込んでいって良さそう。
他職種とのコミュニケーションのコツ
- 単語の意味をちゃんと伝えて、その単語を使う
- 1回飲みに行くのが良かったり、話しかけてみたら意外とwelcomeだったり
- わからない話をそのまま流さず、質問する
- 相手のやりたいこと・時間がかかることを理解する。
- いろんな職種の人に話しかけに行く。
- 自分の影響範囲を知る。やりたいことの根回し手段を知る。
- 相手の郷に従う。相手のコミュニケーション文化に乗っかってみる。
- 相手の領域を経験することで、相手のことを知れる。
- 前提条件を合わせる。話し合うことで、お互いの認識を合わせる。
具体的なコミュニケーションツール
- Slackは常に入ってる。
- メールやLINEも使ったり。
- 静かだけど、Slackだと話していたりする。
- デザインの思考プロセスを、Slackに流している。アイコンも使ったり。
- esaを使って日報を書いている。もやもやを吐露していたり。
- コミュ症の翻訳をしたり。
- Skypeで文字ベースでやりとり。東京とはfacetimeで対面で喋ったり。
- Slackの絵文字。reactionとか。
- Prottを使って、プロダクトについて会話。絵があると、話が進みやすい。
- Slackで雑談部屋。英語専用の部屋。
- ホワイトボードに意見を貼るとそこから話が始まる。
懇親会
- リモートワークに関心は高いらしい。いろんな人に聞かれた。
- Dockerを本番運用しているところもあった。ただ、そこではユーザに直接開放する部分じゃないっぽい？
- いまだにObj-CでiOSの実装を始めることもあるっぽい。企業の体質に依るのかな。
- ポケモンgoの話題は誰にでも通じるぐらい。
- 飲み屋にポケストップあると回し放題（喋ってると忘れるけど）
- PSDの切り出しまでエンジニアがやるのは、やりすぎだと思うデザイナもいるらしい。
- Androidのソフトキーのために、縦横比が変わるってのを、あまり気にしてないデザイナもいる。普段iOSを使ってると気づかないだろうな。
- リスト系の画面だと、あんまり気にする必要無いし。
- デザイン系学部の人たちが、電博にいってしまう。それをIT系に引っ張ってきたい。
- 渋谷とかの大きな会社合同で説明会みたいなのをしては？地方の学生はまとめてあると助かる。
