寄付窓口はこちら

try! Swift デザイナーをSwiftのコードベースに巻き込む10の方法" #tryswiftconf Day3-8

Helen Holmes

誰でも正しいサポートがあればプログラミングを学べると考えているデザイナーです。技術を全ての人に対して適切なコミュニティにすることの提唱者です。Women Who Code DC’s chapterの設立に協力し、アメリカ全土で学生ハッカソンのメンターをしています。現在、Mozillaで開発ツールを誰にとってもより良くする仕事をしています。

twitter.com

デザイナーが開発者と蜜に連携することは多くのメリットがあります。アプリケーションの設計を飛躍的に改善するために行った技術的な判断をデザイナーに伝えることで、、デザイナーをコードベースに巻き込む方法について解説します。

speakerdeck.com

f:id:niwatako:20160304153917j:plain

こんなタイトルを考えていました。

こちらで

f:id:niwatako:20160304153936j:plain

私はデザイナです。FireFoxでお仕事をしています。

Webデベロッパの皆さんがほぼ毎日使うツールを開発しています。

f:id:niwatako:20160304154009j:plain

デザイナがいれば力が発揮できると思うプロダクトは多い。でもデザイナがプロダクトを理解する必要がある。

FireFox、1時間かけてビルドして複雑なバグトラッキングシステムを起動します。でもプログラムが恐ろしかったりする。

皆さんコード離れていますがAfterEffectやMicrosoftWordは皆さんどうでしょう、怖くなりますよね?

FireFoxはデザイナをコードベースに入れていくことがいいことだとわかっています。

みなさんはどうでしょう。コードベースにデザイナが必要だと思うでしょうか。

チームから質問が出たら?

メリットとデメリットを見ていきましょう。

メリット

基本的なレベルで考えると以内より板方がいい。デザイナの仕事は微ユアルを考える、UXを考える。美しいアプリを作りたければ手伝ってくれます。

デザイナをコードベースに参加させると、エンジニアが自分の仕事のために考える時間が出来ます。エンジニアがUX考えるのは難しい。

エンジニアにアセットやヘルプを他のチームからするよりも、自分のチームに居る方がいい。エンジニアの問題を理解するデザイナがチームに入れば、自分たちが何を作っているのか理解できるようになります。

実生活のシナリオのデザインが可能になります。

デメリット

時間がかかる。デザイナを入れようと思ってもデザイナのために構造の変更やメンターシップに時間がかかります。利点はバラバラだなと感じるかもしれません。チームは動き方が違います。リソースも違います。

良いデザインを理解するのはHowのところ、どうやってデザイナをコードベースに参加させるかを考えたほうが良いと思います。

デザイナを連れ込む方法で生産性を高めましょう

f:id:niwatako:20160304153936j:plain

まず興味がある人を連れてくる必要があります。ベテランから初心者まで、どのレベルであれデザイナをコードベースに導入するメリットを得たいのであれば、意欲があるひとを連れてくることです。

そしてもうひとつ、チームの土壌、メンターシップを作る。すごく熱意のあるデザイナでもチームにメンターシップの土壌ができていなければ、質問やコードレビューに答えられなくなってしまいます。

デザイナは豊富な経験者から初心者まで居る。Xcodeはそれだけで怖かったりする。

f:id:niwatako:20160304154650j:plain

それからStoryboardを使いましょうということです。ベストかどうかは置いておいて、

f:id:niwatako:20160304154711j:plain

Storyboardを使えば、UX全体が見渡せるようになり、デザイナをコードベースに呼び込む方法になります。

f:id:niwatako:20160304154733j:plain

4つ目は、オートレイアウトを使いましょう。デベロッパの皆様はレイアウトをプログラム的にすることを好まれますが、Autolayoutを使えるなら使うことを考えて欲しいと思います。制限を簡単に加えて、デザインの変更や実装が出来ます。

5つ目、IBDesignableを設定しましょう。いろんなビジャルチェンジをビルド無く行えます。

比較的簡単に取り込めるので、ボーダーの幅などを変えたい時に非常に有益です。

f:id:niwatako:20160304154907j:plain

できるだけ早く、もっと早く出来るようにするためのものになります。

6つ目は、Sketchに移行してもらいましょう。

f:id:niwatako:20160304154931j:plain

いろんなデザイナが愛して止まないものです。Adobeのプログラムの問題を回避できます。

f:id:niwatako:20160304155003j:plain

プラグインですが、SketchはExportがXcodeと連携しやすいようになっています。

f:id:niwatako:20160304155022j:plain

7つ目、何かをお願いされた時は、デザイナと一緒に協力して下さい。エンジニアが楽になる方法を要求するように、デザイナも要求します。

f:id:niwatako:20160304155107j:plain

エンジニアのリクエストに応えるのと同じように対応してあげて下さい。

8番目、デザイナを放っておかないで下さい。メンターをつけるということではありません。様子をチェックして困っていること、課題を聴くことが大切です

f:id:niwatako:20160304155143j:plain

コードに不慣れなデザイナは迷惑を掛けたくなくて静かにしている人も居ます。定期的にチェックして下さい。

9番目

デザイナをコードベースに入れるには、ドキュメンテーションにいつもより多めに時間を使って下さい。デザイナはインラインコメントから学ぶことが多いです。デザイナにも作業ログを付けてもらって、自分のメモを残してもらっても良いと思います。

最後に、デザイナはコードベースにビギナーであるという意識があります。デザイナもエンジニアがモックアップ作成にどれだけ大変かも理解してくれます。

成功できる学べる環境は穏やかでポジティブな環境が必要です。皆さんが実行できると思うタイミングでこういった活動を始めて下さい。

デザイナとエンジニアの関係が悪いとイライラします。これは不可能と毎回言われたり。

デザイナをチームの一員とすることでこういうことがなくなります。デザイナ自身も実装不可能だということが分かるようになります。

f:id:niwatako:20160304155526j:plain

FireFoxは良い経験になりました。みなさんも同じような形デメリットを享受していただきたいと思います。

QA

コードベースがデザイナにとってフレンドリーではないときどうしますか、あとコード住める?はどうでしょう

コードスメルがあるとデザイナーもわからない。誰もよくないコードは書きたくないと思う。誰にとってもクリーンなコードを描くことが大事だと思います。何かの理由があってハッキッシュになることはあると思うのでそういう場合はドキュメンテーションが助けになると思います。

デベロッパに対して例えばPhotoshoopでSketchを使ってもらうというのはどうでしょうか

iPhoneの場合などKeyコマンドがStoryboardにマッピングされる。Photothopは高い。大きな価格差があります。一般的には新しい物をトライするのは難しいですが、p時ティブにこんないいことが出来るんだよ、ということによってSketchを使ってもらえるようになるんじゃないかと思います。

Webデザイナとデベロッパでアニメーションでどのようにコラボレーションできるでしょうか

デザイナと一緒にアニメーションを見ると。言葉で記述するのはアニメーションでは難しい。その言葉は見ないかぎりどう動くかはわからない。スプリングだったと思いますがライブラリで、それを一緒にアニメーションで見る、それでその言葉がデザイナが持っているものはアニメーションでどのように表現されているかを見るのが良いと思います。

Swiftを直接やったほうが良いか、プロトタイプツールを使ったほうが良いか?

コードもプロトタイピングツールもどちらも使っています。私はコーディングだけが良いかと思う。プロトタイピングツールはコードを描くのと同じぐらい使いこなすのが難しいので。でも他のデザイナは意見が違うと思います。AutolayoutやIBDesignableがあれば視覚的フィードバックもあるのでそれだけでも違うと思います。コードからスタートしては如何でしょうか。

気に入った記事は はてなブックマーク

はてなブックマークアプリiOS開発チームから来ました! はてなブックマークにはSwift特集があります! 良い記事を見逃さないように、ご利用ください! http://b.hatena.ne.jp/hotentry/it/Swift

そして良いまとめ記事があったらはてなブックマークでブックマークしましょう! try! Swift の記事で盛り上がると嬉しいです!