最近、SPAの画面のプロトタイピングをすることがあります。デザイナーとコニュニケーションをとりながら作業を進めるのですが、それなりの頻度でミス・コミュニケーションが発生しました。
振り返ると事前にすり合わせをしておけば、手戻りを小さくできたポイントもあり、今後のために事前に擦り合わせしておいたほうが良いところと、事前に知っておいた方が良さそうなことをまとめておきます。
前提
前提として重要なコンテキストとなりそうな情報を記載します。
-
プロトタイプの作成対象
プロトタイプの作成対象は、エンタープライズ向けのSaaSの業務システムになります。 -
アプリケーションの情報
アプリケーションはVue2で作られており、UIフレームワークとしてVuetifyを利用しています。 -
どのような視点でまとめているか？
フロントエンドエンジニアの視点で、Webデザイナーとフロントエンドエンジニアがお互いに気に留めておいた方がいいことをまとめています。
このような視点を持つWebデザイナーの方は強い人とも考えています。
すり合わせした方が良かったこと
以下、すり合わせすべきだったことを記載します。
画面プロトタイプ作成時のインプット資料のすり合わせ
画面プロトタイプ作成の前に必要なドキュメントが不足しているケースがありました。（途中で気づいて作成）。
Figma、XD以外にスプレッドシートや仕様を記載したドキュメントが必要な場合があります。
組織によって、作成担当がデザイナーなのかエンジニアなのか分かれる場合がありそうで、事前にパターン化できるところはした方がスムーズに制作が進むと思います。
-
画面名と画面URLと画面の役割を一覧化した資料
言葉だけだと、どの画面の話をしているのかわからないという問題が起こりました。 -
簡易的なER図、CRUD、DFD
新規機能を作成するケースで、データモデルの認識合わせが必要なケースがありました。
その際に作成したのは、ER図ですが、CRUD、DFDが必要になるケースもありそうです。
デザイナーの方もシステム開発の要件定義、基本設計工程のドキュメントの作成経験があると望ましい気がします。
inputタグのインタラクションの把握と重要なポイントの指示
以下、MDNのドキュメントになります。
input:入力欄（フォーム入力）要素 - HTML: HyperText Markup Language | MDN
Figma、XDでのプロトタイプ作成時にマークアップの指定がないと、思わぬタグで実装が行われ、デフォルトのinputタグでは実現できている挙動が失われることがあります。
HTMLのinpuタグのデフォルトの挙動を把握して、重要な部分については文書化して指示、要望を出した方が思わぬ実装間違いが発生する可能性を低くできます。
個人的に以下の事象を経験しました。
-
ボタンなのか？リンクなのか？
ボタンであるのか？リンクであるのか？それぞれ挙動が異なるため、実装時にポリシーを決めた方が良さそうです。
また、どちらでの実装もされないケース（クリックできるdivができる…）もありタグの指示もした方が良い気がします。
リンクとボタンを｢押せる｣だけでデザインしない -
チェックボックスなのか？トグルスイッチなのか？ どちらも似たような機能は実装できるので、一般的にどのような使い分けをするのか把握をしておかないと認識齟齬の原因となります。
トグルスイッチのガイドライン – U-Site
Vuetify（というかMaterial-UI）には、Toggle Buttonのコンポーネントがあり、Toggle Buttonを比較的簡単に実装できます。
Button toggle component — Vuetify
UIフレームワークの提供機能で実現できるか？
UIフレームワークの提供機能の範囲を超えると、インタラクションの実装に時間を擁し、一部実現できないという可能性もあります。
デザイナーもフレームワークの実現範囲についての理解は必要に思います。
フレームワークで実現できない機能を新規作成する場合は、マークアップレベルでどのようなタグを利用するかの擦り合わせを実施したほうが、トラブルが少ないかと思います。
画面遷移の挙動と、画面認識の共通理解
Vue.jsを利用している場合、画面遷移（制御）の仕方として以下のような方法があります。
1. MPAのようなaタグによるページ遷移
2. vue-routerのhistoryモードを利用したページ遷移
3. vue-routerのhashモードを利用したページ遷移
4. vue-routerのmomoryモードを利用したページ遷移
5. vue-routerを利用しないv-if、v-showなどを利用した画面制御
画面遷移の仕方で戻る、進むの挙動やリクエスト送信内容が異なります。どのように画面遷移させたいかを明文化すると思わぬ挙動を避けられます。
バリデーションライブラリの把握
UIフレームワークと同様ですが、バリデーションライブラリによりチェックタイミングや、メッセージの見せ方等で実現できることが異なります。Webデザイナーはどのようなライブラリを使っているのかを把握しておく、エンジニアは制約を理解しておくと、思ったものと違うものができる確率は下がります。また、当たり前ですがForm作成時は動作確認をしっかりやっておく必要があります。
拡大表示時に画面操作が行えるか？
これは自戒です。幅、高さを固定するようなレイアウトだと画面拡大表示時にボタンが操作できないといった致命的な問題が発生します。freeeのアクセシビリティー・ガイドラインが参考になりましたが、事前に動作確認する条件は擦り合わせしておくべきでした。
拡大表示時のアクセシビリティー — freeeアクセシビリティー・ガイドライン Ver. 202306.1 ドキュメント
画面が崩れているけど使えると、画面が崩れて使えないがあり、個人基準では、200%に拡大しても画面が崩れているけど使えるは担保しておきたいなと思います。
スコープ付きCSSを記述できる
これは、デザイナーの方も知っておいたほうがいいのでは？という機能です。
SFC CSS 機能 | Vue.js
Vueのコンポーネントに閉じたCSSを記述でき、外部へ影響を与えません。
使いすぎは厳禁な気はしますが、あるコンポーネントだけCSSの内容を変えたいというケースも対応できるようになりました。
参考
- Different History modes | Vue Router
- Scoped CSSにおけるCSS設計手法 - ICS MEDIA
- Navigation API による「JS での画面遷移」と SPA の改善 | blog.jxck.io
作成対象のプロトタイプの方向性で、もっと色々出てきそうですが、2、3か月の作業で印象に残ったものは以上になります。
コメント