先日、自分が主催したDXEL.1 エンジニアとデザイナーが「いい関係」を築くためにという勉強会で自身も「そのUI、実は簡単じゃないんです」というタイトルで登壇をしました。この記事では登壇資料の補足、時間の都合上割愛した他の事例の紹介、この問題にどう立ち向かうべきかについて書きたいと思います。

資料の補足

■「戻る」ボタン
このスライドの反響でもありましたが、確かに「そもそも戻るをタップした時にアラートを出すような設計がおかしい」という話もあります。参考までに、Human Interface GuidelineのModalityの章、Navigationの章を見てみましょう。
Modalityの章では次のようなことが書かれています。

・そのタスクが完了するまで他のことができない状態にしたい時に使いましょう
・モーダルは最小限の利用に留めましょう

Navigationの章では次のようなことが書かれています。

・ナビゲーション自身を意識することなくユーザが目的達成できるように構成しましょう
・ユーザは常に今自分がどこにいるか、次に向かうにはどうすればいいかを知っている状態にすべき
・可能な限り、標準のナビゲーションコンポーネントを使いましょう

今回資料で例に出していたのは入力系の画面なので「そのタスクが完了するまで他のことができない状態にしたい」に該当しそうです。なのでモーダルにするというのも一つの有力な対応案になると思います（実際、私のケースでもモーダル対応で解決させました）。

ここらへんのナビゲーションに関しては、この資料も参考になりそうです。
・iOS ヒューマンインターフェースの原則
・もう迷わない!モーダルとプッシュどっちがいいの？

■ハイパーリンク
資料中ではUILabelを使った例を紹介しましたが、UITextViewというやつでも実装することができます。が、やはり面倒だなぁという印象です。

・UITextViewにタップ可能なリンクを挿入する
・UITextView を使ってテキストの一部をハイパーリンク化する

■アコーディオンメニュー
Speaderdeckにあげてしまうとgifアニメーションが機能しなくなってしまうので、一応動きのあるやつをここに置いているので参考までに。
https://github.com/akatsuki174/AccordionMenuSample

その他事例

■section headerが画面上部に固定されないようにしたい
特に何も考えないで実装するとこんなかんじになります。

これをヘッダーが流れるように変更するのは、ちょっと面倒です。何かの設定値1つでその切替ができるようにはなっていないんです。でも（デザインにもよりますが）いろいろ変えればできる範囲です。

■チェックボックス、ラジオボタンを付けたい
webでよく見かけるチェックボックスやラジオボタン。iOSにはこれにあたる部品はないので、自分で頑張って作るか、代用品を使うことになると思います。

チェックボックスの場合は、オン状態 / オフ状態の画像を用意して、タップされた瞬間に切り替えるという手法になると思います。が、iOSにはUISwitchというオンオフを切り替えられる部品が存在しています。なので基本的にはこちらを使うべきだと思います。

ラジオボタンの場合もやるとしたら画像で対応することになるのかなぁと思います。が、こちらに関してもiOSにはUISegmentedControlという複数の選択肢の中から1つを選ぶための部品がありますし、UIPickerを選択するというのも一つの手だと思うので、そちらを検討するのも良いと思います。

■スナックバーを出したい
Androidではスナックバー部品が用意されているのでよく見かけますが、iOSでは用意されていません。なのでやるとしたら普通のviewを用意してフェードイン/アウトの処理を付けたり、タッチアクションを付けたりする必要があります。実装的には難しくないのですがiOSの世界にはないものなので、一度本当にその表現が適切なのか考える必要はありそうです。
※Google PhotoはiOS版でもスナックバーのようなものを取り入れています。

ちなみにスナックバーでは直前の動作を戻すボタンが置かれることが多いと思いますが、直前の動作を戻すのもそれなりに手間がかかります。スナックバーがない場合は、例えば削除操作が行われた時は元データを直接消してしまえばいいのですが、動作を戻せるとなると削除すると同時に削除したアイテムを一時的に覚えておき、戻す処理が行われたら再びそのアイテムを追加するなどの処理が必要になってきます。

うまくやっていくためには

いろいろ書きましたが、決して「大変なものはやらないべき」「デザイナーは開発側の事情を全部把握しろ」ということが言いたいわけではありません。エンジニアもデザイナーもそれぞれ異なった専門知識がありますし、相手方の知識を得ようとするにはそれ相応の時間がかかります。だからといって「自分は◯◯だから△△の領域のことは△△に全部任せればいい」というのも違うと思います。それでは「デザイナーが無茶なUI出してくる」「エンジニアがいつも文句付けてくる」という対立関係ができてしまいます。

なので、ありきたりではありますがコミュニケーションが大事になってくると思います。デザイナー→エンジニアの会話で「ここはこうゆう理由で、どうしてもこんなかんじにさせたいからこのUIにしたい」、エンジニア→デザイナーの会話で「ここはこうゆう理由でかなり工数がかかるから削りたい」というように、理由を言うだけでも違うと思います。理由がわかれば、例えば「このUIは厳しいけど、こんなUIだったら同じ目的が達成できて、あまりコストかけずにできるよ」と言うこともできます。

また、お互いの作業過程を共有するのもいいと思います。エンジニアとデザイナーが1対1でペアプロをして、どのようなコンポーネントがあってどうやってそれを組み立てていくのかを学んだり、デザイナーがUIを作る時にどのように資料収集して、どのように組み立てていくのかを学ぶとお互いの気持ちを少し理解できると思います。

エンジニアとデザイナーの関係というのはなかなか難しいものですが、お互いの歩み寄りによってより良いものになっていくはずです。なので今後もDXELではお互いを理解できるようなイベントをやっていきたいと思っています。