これまで主にウェブ環境でパブリッシング業務を行ってきました。レスポンシブウェブ制作の経験はありましたが、モバイル環境で本格的にUIを構成し、動作を実装したのは今回が初めてでした。最初は、モバイルも結局はウェブ技術を基盤としているため、従来の方法と大きくは変わらないだろうと考えていました。しかし、実際に作業を進める中で、モバイルは単に画面サイズが小さいウェブではないということを、さまざまな面で実感しました。
モバイル環境では、レイアウト構造だけでなく、ユーザーの入力方法、画面の高さの計算方法、スクロールの処理方法、アクセシビリティへの対応方法など、さまざまな要素を同時に考慮する必要がありました。特に、ウェブで自然に使用していた方法がモバイルではそのまま適用できないケースが多く、新しい基準を継続的に学んでいく過程でもありました。
モバイルで最初に実感した違いは、ユーザーの入力方法でした。ウェブ環境ではマウスを基本とするため、hover状態を活用したインタラクションが非常に一般的です。
.button:hover{
background-color: #f5f5f5;
}hover状態は、ユーザーが要素の上にマウスを置いたときに視覚的なフィードバックを提供する方法で、デスクトップUIでは重要なインタラクション要素の一つです。しかし、モバイル環境にはマウス自体が存在せず、すべての入力がタッチを基盤として行われます。そのため、hover状態はモバイルでは実質的に動作しないか、限定的にしか動作しません。したがってモバイルでは、hover中心のインタラクションではなく、active状態や選択状態を中心にUIを構成する方法が一般的です。
.button:active{
background-color: #f5f5f5;
}この違いを通じて、同じUIであっても入力方法によって状態設計がまったく異なる可能性があることを確認できました。単にスタイルを変更するだけでなく、ユーザーの行動そのものを基準にUIの状態を再定義する必要があるという点が重要でした。
チェックボックスとラジオボタンでも、同様の違いを経験できました。ウェブ環境では小さなコントロール要素を直接クリックする方法でも十分に利用できますが、モバイルではタッチの正確性が重要な要素になります。モバイルでは指で操作するため、クリック可能な領域が十分でないと、使いやすさが急激に低下する可能性があります。特にチェックボックスのように小さなUI要素だけをクリック可能にしている場合、誤操作の可能性が高まります。この問題を解決するために、チェックボックスとラベルを一つのクリック領域として構成する方法が使われます。
<FormControlLabel
control={<Checkbox />}
label="자동 로그인"
/>この構造により、チェックボックスだけでなくテキスト領域も同時に選択できるようになり、タッチ領域を拡張する効果があります。その結果、ユーザーはより広い領域を通じて同じ操作を実行でき、UIの正確性と使いやすさが同時に向上します。
モバイルUIを扱う中で、Bottom Sheet構造も重要なパターンの一つでした。Bottom Sheetは画面下部から上方向に現れるパネルUIで、モバイル環境でよく使用されるインターフェースです。
ウェブでは一般的に中央に表示されるModalを多く使用しますが、モバイルでは画面下部が指で最もアクセスしやすい領域とされています。そのため、オプション選択、フィルター、入力フォーム、ファイルアップロードなどの機能は、Bottom Sheet形式で提供されることが多くあります。
また、Bottom Sheetは画面全体を遷移させずに機能を提供できるため、ユーザーが現在のコンテキストを維持したまま追加の操作を行えるというメリットがあります。これはモバイルUXにおいて非常に重要な要素となります。
<班長ノートプロジェクトで使用しているBottom Sheetの画像>
レイアウトの実装過程では、Safe Areaの概念も重要な要素となりました。近年のモバイル端末では画面全体を使用する形式が一般的であり、それに伴って上部と下部に物理的なUI領域が存在します。
上部にはカメラやセンサーが配置されたノッチ（Notch）領域があり、下部にはホームジェスチャー用のホームインジケーター（Home Indicator）が存在します。これらの領域は、コンテンツが直接入り込んではならない領域に分類されます。
したがって、モバイルUIではSafe Areaを考慮した余白処理が必須となります。
.mobile-layout{
padding-top: var(--safe-area-top);
}Safe Areaを考慮しない場合、コンテンツが端末のUIと重なって可読性が低下したり、一部の内容が隠れたりする問題が発生する可能性があります。特にiOS環境では、この影響がより明確に現れます。
画面の高さを処理する方法も、ウェブとモバイルにおける重要な違いの一つでした。
ウェブでは一般的に、次のような方法で画面全体の高さを構成します。
html,
body,
#root{
height: 100%; // 또는 height: 100vh;
}height: 100%は親要素の高さを基準に計算される方法で、100vhはビューポート（Viewport）の高さを基準に計算されます。ビューポートとは、ユーザーが現在見ている画面領域を意味します。つまり、実際に画面に表示されている領域の基準となります。しかしモバイル環境では、アドレスバーや下部バーなどが動的に表示されたり消えたりするため、実際に使用可能な画面の高さが継続的に変化します。そのため、100vhが実際の画面と正確に一致しない問題が発生する可能性があります。この問題を解決するため、現在はdvh（Dynamic Viewport Height）単位を使用する方法が一般的です。
html,
body,
#root{
height: 100dvh;
}dvhはブラウザUIの変化まで反映し、実際に使用可能な画面の高さを基準に計算されるため、モバイル環境でより安定したレイアウトを構成できます。特にスクロールを含むレイアウトでは、レイアウトの揺れを抑えるうえで重要な役割を果たします。
スクロールの動作も、モバイル環境では重要な要素の一つでした。
.mobile-content{
overflow-y: auto;
-webkit-overflow-scrolling: touch;
overscroll-behavior: contain;
}特に-webkit-overflow-scrolling: touchは、iOS環境で慣性スクロールを適用するためのプロパティです。この設定を適用すると、ユーザーが素早くスクロールした後に手を離しても、自然にスクロールが続く効果が生まれます。ネイティブアプリで感じられるスクロール体験に近い動作を、ウェブ環境でも実現するための重要な設定です。モバイルUXではスクロールの滑らかさがユーザー体験に直接影響するため、単なるスタイルプロパティ以上の意味を持ちます。
フォントの単位も、モバイル環境を考慮して構造的に変更した部分です。初期段階では、デザイントークンで定義されているとおり、コードでもフォントをpx単位で定義していました。
$fz-10: 10px;
$fz-11: 11px;
$fz-12: 12px;
…pxは直感的で使いやすい単位ですが、絶対単位です。モバイル環境ではアクセシビリティ設定に応じてユーザーの文字サイズが変更される可能性があるため、相対単位を使用するほうが適しています。
プロジェクトでは、デザイントークンに定義されたさまざまなフォントサイズを一貫してremに変換して使用できるよう、ユーティリティ関数を構成しました。
// rem 변환 함수 정의(Base size: 16px 기준)
@function rem($px) {
@return math.div($px, 16px) * 1rem;
}
$fz-10: rem(10px);
$fz-11: rem(11px);
$fz-12: rem(12px);
$fz-13: rem(13px);
…単なる単位変換ではなく、デザイントークンベースのスタイルシステムで一貫性を維持するための構造的なアプローチです。
メリットは次のとおりです。
第一に、デザイントークンをpx基準で維持しながら、実際のコードではrem単位に統一して使用できます。
第二に、単位変換のロジックを一つの関数に集約することで、保守性が向上します。
第三に、誤って間違った単位計算を直接記述してしまう問題を減らせます。
第四に、今後アクセシビリティ設定や基準フォントが変更された場合にも、柔軟に対応できます。
レイアウトの構成方法にも重要な変化がありました。
ウェブでは、カードやリスト要素の高さを固定値に設定するケースが多くあります。
.card{
height: 120px;
}しかしモバイル環境では、ユーザー設定によってフォントサイズやコンテンツの長さが変わる可能性があります。固定された高さは、テキストが切れたりレイアウトが崩れたりする原因になります。したがってモバイルでは、高さを固定する代わりに、paddingとコンテンツの流れを基盤として自然に拡張される構造のほうが適しています。
.card{
padding: 16px;
}この方法は、さまざまな画面サイズやコンテンツの変化により柔軟に対応でき、保守性の面でも安定した構造を提供します。
今回のモバイルパブリッシング経験を通じて最も強く感じたのは、モバイル環境は単なるウェブの縮小版ではないということでした。入力方法、レイアウト構造、画面の高さの計算方法、スクロール動作、アクセシビリティへの対応方法など、複数の要素を同時に考慮する必要があり、それぞれの要素がユーザー体験に直接影響することを確認できました。
これからもさまざまなデバイス環境を考慮し、より安定して一貫性のあるUIを実装できるよう、経験を広げていきたいと考えています。
KKAMJJING