読者です 読者をやめる 読者になる 読者になる

UI Live ! in Kanazawa に参加してきた

90c0ba03fdaf930c0a4048bb06.doorkeeper.jp

まとまらないまとめ

  • こんな会が北陸で行われるのは良い
  • DeNADMM.comの人、それ以外の人ともいろいろ話せて良かった
  • デザイナの考えもいろいろ知れて良かった

インハウスデザイナーの新規事業開発での動き方

speakerdeck.com

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に情報を詰め込み過ぎない。

「使いやすい」だけではユーザー体験が上げられないサービスでのデザイン手法

speakerdeck.com

Material Designスタイルでプレゼン。

グラフィック→WEB/INTERACTIVE→サービス

iPhone出て早9年 当時は、専門的なデザイナがおらず、エンジニアだけで作っていた。 今では、UIデザイナの地位が確立され、ガイドラインが作られた。

1→2的なグロースハック系は、「使いやすい」というのが役立つ。 0→1的な新規事業では、雰囲気みたいなものが大事。

UI/UXの記事を鵜呑みにして適用しても、うまくいかない。

さんぽジスタを作るときに、「使いやすい」ではただの歩数計になってしまう。

今日の歩数:達成感・やる気を起こさせる。 キャラ:「何が変か」を具体的に調整していく。 背景:画像検索で世界観を知る。

自分で使ってみて、つまらなかったので、コンテンツ追加。ブラッシュアップ。

質疑応答

  • 自分で使って、客観的に見る。
    • 何か変えてみて、また使ってみる。
    • 社内でターゲットになるような人に使ってみてもらう。
  • DeNAは、思ってることを言いやすい環境。
    • 自分の作ったものに責任を持つ。
  • ターゲットユーザがチーム内にいない場合
    • まず、インセプションデッキを作った。
    • ある程度仮設を立て、作り、ユーザの動きをアナリティクスで見て、拡張していく。

これからの「フロントエンド開発」の話〜(デザイナー所属の)フロントエンドエンジニアでも知っておきたいこと〜

www.slideshare.net

認証会員基盤のエンジニア フロントエンドのチームリーダー

金沢すきま旅というのを作った。

エンジニア目線な話

UXセミナーのストーリーボードを見て衝撃を受けた。

エンジニアは、細かく検証し、問題があればすぐ修正したい。

Dockerをローカル開発環境として使う。 継続的インテグレーションの流れを、デザイナにも知っておいて欲しい。

質疑応答

  • Dockerを布教中
    • ハンズオンを開催し、体験してもらう
    • GUIもあるおかげか、デザイナ側も抵抗感が少なそう
  • ストーリーボードの何が衝撃を受けたのか
    • いままでは、完成されたワイヤーから関わっていた
    • そのワイヤーに至る理由が見えるので、理解できる

フロントエンドエンジニアが、機能開発の企画オーナーとなってリードした話

speakerdeck.com

エブリスタに関わっている。 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系に引っ張ってきたい。
  • 渋谷とかの大きな会社合同で説明会みたいなのをしては?地方の学生はまとめてあると助かる。