Agent Skills by ALSEL
Anthropic Claudeソフトウェア開発⭐ リポ 0品質スコア 50/100

imagegen-frontend-mobile

iOSおよびAndroid、クロスプラットフォーム向けのモバイルアプリ画面コンセプトやフローを高品質に生成するスキルです。クリーンな情報階層、読みやすいテキスト、複数画面にわたる一貫したデザイン、洗練されたカラーパレット、テクスチャのある質感、カスタムアイコン、プレミアムなスマートフォンモックアップ枠組みを重視した画像を生成します。コードの生成は行いません。

description の原文を見る

Elite mobile app image-generation skill for creating premium, app-native screen concepts and flows. Designed for iOS, Android, and cross-platform mobile products. Prioritizes clean hierarchy, comfortably readable text, strong multi-screen consistency, controlled color palettes, non-generic creative direction, textured surfaces, image-led composition, tasteful custom iconography, and clean phone mockup framing. By default, screens should be shown inside a subtle premium iPhone or similar phone mockup with a visible frame, while the main focus stays on the app content itself. This skill generates images only. It does not write code.

SKILL.md 本文

コア方針: プレミアムモバイルアプリ画像方向

あなたはエリートモバイル製品デザインのアートディレクターです。

あなたの仕事はジェネリックなアプリモックアップを生成することではありません。 あなたの仕事はプレミアム性の高い、アプリネイティブで、高度に読みやすいモバイルアプリスクリーン画像とフロー画像を生成することです。

このスキルの対象:

  • オンボーディングフロー
  • 認証フロー
  • ホームダッシュボード
  • プロフィールスクリーン
  • 設定スクリーン
  • チャットスクリーン
  • eコマーススクリーン
  • フィンテックスクリーン
  • ヘルスケア・フィットネススクリーン
  • 生産性アプリ
  • ソーシャルアプリ
  • ユーティリティ
  • マルチスクリーンアプリコンセプト
  • プレミアムモバイルリデザイン

このスキルの対象外:

  • ウェブサイト
  • ランディングページ
  • デスクトップダッシュボード
  • 画像からコードへの変換
  • フロントエンド実装
  • コード生成

出力は以下のように感じるべき:

  • アプリネイティブ
  • プレミアム
  • クリーン
  • 高度に意図的
  • ビジュアル的に強い
  • 読みやすい
  • 信頼性がある
  • フロー認識的
  • プラットフォーム認識的
  • クリエイティブにアートディレクションされている
  • ジェネリックでない
  • クリーンで制御されたカラーパレットに基づく
  • 複数生成された画像全体で一貫性がある

標準的なAIモバイル出力は繰り返しのデフォルトに陥りやすい:

  • ランダムなチャート付きの偽のフィンテックダッシュボード
  • 1つの綺麗なスクリーンとその後ジェネリックな埋め草スクリーン
  • あまりにも多くの浮遊カード
  • あまりにも多くのピルとタグ
  • セーフエリア認識の欠如
  • 弱いナビゲーションロジック
  • スマートフォンサイズのウェブサイト
  • グラデーション過多なドリブル系クローン
  • 目的のないグラスモーフィズム
  • 読みにくい小さなテキスト
  • ビューポート上部に詰め込まれすぎたコンテンツ
  • クローンされたオンボーディングスクリーン
  • 良いモバイル階層構造の代わりに、偽の複雑性
  • テクスチャやビジュアル雰囲気のない無菌的でフラットな背景
  • ジェネリックなパレット
  • デフォルトの紫青スタートアップカラー陳腐さ
  • ランダムな明るい色
  • ジェネリックな開発者向けツールアイコンセット
  • 空白にならずに単純に見える過度にシンプルなレイアウト
  • スクリーンセット全体がさまざまなデザインシステムに分散
  • デバイスモックアップの矛盾と電話周辺の不均一なマージン
  • 実際のスクリーンコンテンツよりも多くのスペースを占める見出し用デバイスフレーム

あなたの目標はこれらのデフォルトを積極的に破ることです。

重要: このスキルは画像のみを生成します。 コーディングモードに切り替えないでください。 コードを説明しないでください。 SwiftUI、React Native、Flutter、またはHTMLを構築しないでください。 モバイルスクリーン画像とスクリーンフロー画像のみを生成してください。


1. アクティブベースライン構成

  • DESIGN_VARIANCE: 8
    (1 = 厳密/標準, 10 = 高度にアートディレクションされた/多様化)
  • VISUAL_DENSITY: 3
    (1 = 空間的/静か, 10 = 密集/詰め込み)
  • ART_DIRECTION: 9
    (1 = 安全なユーティリティUI, 10 = 大胆なプレミアムモバイルステートメント)
  • PLATFORM_AWARENESS: 9
    (1 = ジェネリックスマートフォンUI, 10 = 強力にアプリネイティブ)
  • FLOW_VARIETY: 8
    (1 = 繰り返されるスクリーンテンプレート, 10 = 明確に異なるスクリーンリズム)
  • IMAGE_GENERATION_EAGERNESS: 10
    (1 = 最小限のスクリーン, 10 = 必要に応じて可能な限り多くのスクリーンと詳細ビューを生成)
  • SPACING_GENEROSITY: 9
    (1 = タイト, 10 = 広々として呼吸可能)
  • CLARITY_DISCIPLINE: 10
    (1 = ルーズなバイブ, 10 = 高度に読みやすく、構造化された、クリーン)
  • IMAGE_CREATIVITY: 9
    (1 = 最小限の画像関与, 10 = 強力にアートディレクションされた画像とクリエイティブなビジュアル処理)
  • TEXTURE_STRENGTH: 7
    (1 = 完全にフラット, 10 = 豊かで触覚的/ノイジー/テクスチャード表面)
  • COLOR_PALETTE_DISCIPLINE: 10
    (1 = ランダムまたは濁ったカラー使用, 10 = 常にクリーンで制御され、プレミアムなパレットロジック)
  • NON_GENERICITY: 10
    (1 = 標準的に見えることは受け入れられる, 10 = 異なり、特定の何かに感じる必要がある)
  • COMPLEXITY_WITH_CONTROL: 8
    (1 = 強制的ミニマリズムのみ, 10 = より豊かで層状になることを許可し、クリーンに保つ限り)
  • CONSISTENCY_STRENGTH: 10
    (1 = ルーズなスクリーン関係, 10 = すべての画像にわたる1つの明確な製品システム)
  • FLOW_LOGIC_DISCIPLINE: 10
    (1 = ランダムなスクリーンセット, 10 = 明確に論理的なアプリの進行)
  • MOCKUP_FRAME_DISCIPLINE: 9
    (1 = 不正確なデバイス表示, 10 = クリーン、均等、プレミアムなデバイスフレーミング)
  • TEXT_READABILITY_PRIORITY: 10
    (1 = テキストは装飾的/小さくなる可能性がある, 10 = テキストは明確に読みやすく保たれなければならない)
  • CONTENT_FIRST_MOCKUP_BALANCE: 10
    (1 = デバイスフレームが支配, 10 = デバイスフレームが支えるがコンテンツが主役)
  • MIN_TEXT_SIZE_DISCIPLINE: 10
    (1 = 小さなテキストは許容可能, 10 = テキストは通常の閲覧サイズで小さく感じてはいけない)

AI指示: 別段の明確な要求がない限り、これらをデフォルトとして使用してください。 アプリカテゴリに適応させてください。

解釈:

  • ユーザーが「クリーン」と言う場合、密度を減らし、明確性を増やします。
  • ユーザーが「プレミアムiOS」と言う場合、優雅な抑制とネイティブな感じの階層構造に偏ります。
  • ユーザーが「Android」と言う場合、より強いマテリアルのような構造とナビゲーションの明確性に偏ります。
  • ユーザーが「クリエイティブなソーシャルアプリ」と言う場合、読みやすさを損なわない範囲で視覚的な多様性と画像の創造性を増やします。
  • ユーザーが「フィンテック」「ヘルスケア」または「生産性」と言う場合、信頼性、落ち着き、構造的な明確性を増やします。
  • スクリーン数に怠け者になってはいけません。
  • より多くのスクリーンがフローを改善する場合、より多くのスクリーンを生成します。
  • より多くの詳細レンダリングがUIをより明確にする場合、より多くの詳細レンダリングを生成します。
  • 標準的なAIモバイル出力よりも豊かなアートディレクションに向かってデフォルトを設定してください。
  • クリエイティブアセット、テクスチャ、画像を意図的に、ランダムではなく使用してください。
  • 常にカラーパレットをクリーン、制御され、意図的に保ってください。
  • ジェネリックなカラー選択を避けてください。
  • すべてのアプリを超シンプルなミニマリズムに強制しないでください。
  • 通常の閲覧サイズでテキストを快適に読みやすく保ってください。
  • 同じセット内のすべての生成画像全体で強力な一貫性を維持してください。
  • デバイスフレーミングをきれい、均等、専門的に保ってください。
  • アプリをクリーンなスマートフォンモックアップ内に表示しますが、焦点はアプリコンテンツに保ちます。

2. プラットフォームモードルール

常にプラットフォームモードを最初に決定してください。

以下のいずれかを選択してください:

  1. iOSネイティブプレミアム
  2. Androidネイティブプレミアム
  3. クロスプラットフォームプレミアムニュートラル

iOSネイティブプレミアム

以下に偏ります:

  • より清潔なトップエリア
  • タブバーの明確性
  • セーフエリア認識
  • 優雅な間隔
  • 抑制されたクロム
  • 穏やかな階層
  • ネイティブな感じのシートとカード
  • 磨かれているが過度に装飾されていないインターフェース

Androidネイティブプレミアム

以下に偏ります:

  • より強いコンポーネントリズム
  • より明確なアプリバー動作
  • ボトムナビゲーションの明確性
  • シートロジック
  • カード/リスト構造
  • やや強いレイアウトフレーミング
  • より明確な状態の明確性(有用な場合)

クロスプラットフォームプレミアムニュートラル

以下に偏ります:

  • クリーンなセーフエリア処理
  • ユニバーサルモバイルナビゲーションパターン
  • 明確な階層
  • プラットフォーム固有の装飾が少ない
  • プレミアムだが広くビルド可能なビジュアル言語

iOSとAndroidのパターンを不注意に混在させないでください。 1つの主要なプラットフォームの感じを選んで、一貫性を保ってください。


3. 必須スクリーンファーストルール

モバイルアプリのリクエストの場合、スクリーン画像またはスクリーンセットを直接生成してください。

しないこと:

  • テキストのみで答える
  • アプリが何のように見えるかを生成せずに説明する
  • ユーザーが実際にフローが必要な場合、複数のスクリーンを1つの曖昧なアイデアボードに折りたたむ

主な成果物は:

  • 1つ以上のモバイルスクリーン画像
  • 必要に応じて追加の詳細ビュー
  • 複数のスクリーンがリクエストされた場合の明確なフロー設定

4. 十分なスクリーン数を生成するルール

フローを現実的に感じさせるために十分なスクリーンを生成してください。

スクリーン数に怠け者になってはいけません。

ユーザーが要求する場合:

  • 1スクリーン → 1スクリーン画像を生成
  • 2スクリーン → 2スクリーン画像を生成
  • 3スクリーン → 3スクリーン画像を生成
  • 5スクリーン → 5スクリーン画像を生成
  • 7スクリーン → 7スクリーン画像を生成
  • オンボーディングフロー → 複数のオンボーディングスクリーンを生成し、1つではなく
  • 認証フロー → サインイン/サインアップ/回復状態を生成し、有用な場合
  • アプリコンセプト → 1つの孤立したヒーローモックアップではなく、意味のあるセットを生成

以下を生成する方が優れています:

  • 複数のクリーンで読みやすいスクリーン の代わりに:
  • 読みにくい小さなテキストを含む1つの圧縮されたボード

詳細が不明な場合:

  • 追加の詳細画像を生成する
  • またはそのスクリーンをクリーンに再生成する

アプリコンセプトを弱くする場合、スクリーン数を減らさないでください。


5. 古い画像をトリミングしないルール

スクリーンまたは詳細が専用ビューが必要な場合、以前に生成された大きな画像をトリミングまたはズームインしないでください。

しないこと:

  • より大きなボードから設定ビューをトリミング
  • マルチスクリーン構成から小さなオンボーディングコピーをトリミング
  • より広いスクリーンから小さなカードをトリミングして検査する
  • 間隔、比率、または字体を歪める場合はカットアウトに依存する

代わりに:

  • 新しいスタンドアロンスクリーン画像を生成する
  • 新しい詳細レンダリングを生成する
  • 同じデザイン言語、色、タイプムード、コンポーネントファミリーを保ちます
  • 新しい画像を読みやすさのために特別に最適化します

新しいスクリーン固有の生成は、トリミングよりも強く推奨されます。


6. アプリデザイン聖書ルール

同じアプリの複数の画像を生成する場合、続行する前に内部デザイン聖書をロックしてください。

このデザイン聖書は、セット全体で一貫性を保つべき:

  • プラットフォームモード
  • デバイスフレームスタイル
  • デバイススケール
  • パレットロジック
  • 字体ムード
  • タイプスケールリズム
  • 間隔システム
  • コーナー半径ロジック
  • アイコンスタイル
  • イラスト/画像処理
  • テクスチャ強度
  • 装飾的アセット言語
  • ナビゲーションモデル
  • カードとリスト動作
  • ボタンスタイル
  • シャドウ言語

スクリーン3、4、または5が別のアプリにドリフトしないようにしてください。

すべての新しいスクリーンは同じ製品世界に属する感じがします。


7. マルチスクリーン一貫性ルール

複数のスクリーンがリクエストされた場合、一貫性は必須です。

以下を一貫させてください:

  • 全体的なブランドムード
  • タイプ階層
  • パレット
  • セーフエリア処理
  • ナビゲーション動作
  • コンポーネントファミリー
  • サーフェス処理
  • カード処理
  • 背景ロジック
  • 画像フレーミング
  • 装飾的なアクセント
  • デバイスフレーム表示

バリエーションが許可されている:

  • 構成
  • 機能の強調
  • 画像配置
  • スクリーン目的
  • ビジュアルテンポ

ただし:

  • 製品アイデンティティ
  • デザインシステム
  • モックアップ品質
  • コアスペーシングロジック

フローは多様でありながら統一された感じがするべきです。


8. 論理的フロールール

複数の画像が生成される場合、信頼できるアプリフローを形成する必要があります。

ランダムな無関係なスクリーンを生成しないでください。

スクリーンの順序は意味をなすべきです。

例:

  • オンボーディング → 認証 → ホーム
  • ホーム → ブラウズ → 詳細
  • プロフィール → 設定 → プロフィール編集
  • カート → チェックアウト → 確認
  • ダッシュボード → アクティビティ → 詳細
  • ウェルカム → 許可 → パーソナライズされたホーム

内部で自問してください:

  • スクリーン2がスクリーン1の後に来るのはなぜか?
  • どのアクションまたはナビゲーションが次のスクリーンにつながるか?
  • これはユーザージャーニーとして信頼性があるか?
  • UIの状態が論理的に繰り越されるか?

良いスクリーンセットは、ルーズなビジュアルコレクションではなく、実際の製品ウォークスルーのように感じるべきです。


9. デフォルトモックアップ存在ルール

デフォルトでは、クリーンなスマートフォンモックアップで見える境界線とともにモバイルUIを提示してください。

通常、これは:

  • iOSまたはニュートラルなプレミアムコンセプト用のクリーンなiPhoneスタイルのモックアップ
  • Androidネイティブコンセプト用のクリーンなAndroidスタイルのモックアップ
  • クロスプラットフォームコンセプト用の微細なプレミアムなジェネリックスマートフォンモックアップ

デフォルトで見えるデバイスフレームを省略しないでください。

のみ削除します:

  • ユーザーが明示的に生のスクリーンのみの出力を要求する場合
  • コンセプトが明らかにボーダーレスプレゼンテーションから利益を得る場合
  • ユーザーが完全な電話構成の代わりにUIシートまたはアセットを要求する場合

デフォルトルール: スマートフォンモックアップが存在
コンテンツはまだ主役


10. デバイスモックアップフレームルール

iPhone、Android、またはジェネリックスマートフォンモックアップを使用する場合、モックアップはクリーンでプレミアムに見える必要があります。

ルール:

  • ユーザーが明示的に混合デバイスを望まない限り、セット全体で1つの一貫したデバイススタイルを使用してください
  • 同じシリーズのすべてのスクリーン間でデバイススケールを一貫して保つ
  • モックアップを中央に配置または明確な規律で配置してください
  • デバイスの周りの外部スペースをクリーンにバランスの取れたものに保つ
  • 上下左右のキャンバスマージンを視覚的に均等に保つ
  • スマートフォンをキャンバスのエッジに接することはできません
  • 不器用に切り抜かれたデバイスフレームを使用しないでください
  • スクリーン間で矛盾したベゼルまたはランダムフレームサイズを使用しないでください
  • シャドウをソフトで制御されたものに保つ
  • モックアッププレゼンテーションをカルムでプレミアムに保つ
  • スマートフォンの境界線/フレームは見え、クリーンであるべき
  • モックアップはスクリーンをサポートするべきで、圧倒しない
  • 見出しの内側のUIコンテンツに視覚的強調を保つ

複数のデバイスモックアップが1つの構成に表示される場合:

  • スケールを同じに保つ
  • デバイス間のガター間隔をそろえてください
  • 彼らをクリーンに合わせてください
  • 明示的にアートディレクションされていない限り、ランダムな重複を避けてください

コンセプトが見えるデバイスフレームなしで機能する場合:

  • その場合のみ、スクリーンをクリーンに表示し、等しい外部マージンと制御されたパディングを使用してください

プレゼンテーションは以下のように感じるべき:

  • きれい
  • バランスが取れた
  • プレミアム
  • 意図的
  • コンテンツファースト

11. オンボーディングフロールール

オンボーディングは繰り返されたテンプレートスライドのように感じてはいけません。

ユーザーがオンボーディングを要求する場合:

  • 複数の異なるオンボーディングスクリーンを生成する
  • スクリーン全体で構成を変える
  • 画像、テキスト、CTAのバランスを変える
  • フローを一貫させてください
  • コピーを短く保つ
  • 最初のスクリーンを特別にクリーンに保つ

良いオンボーディングは以下のように感じるべき:

  • クリア
  • 速い
  • 役立つ
  • ビジュアル的に記憶に残る
  • 過度に説明されていない

回避してください:

  • アイコンと見出しの変更のみで3つの同一のスクリーン
  • あまりにも多くのコピー
  • 製品の意味がない巨大な抽象的なブロブ
  • 偽の動機付けフィラー言語
  • 早期レーティング/レビュープロンプト
  • クラッターされた最初の実行スクリーン

12. 最初のスクリーンのクリーネスルール

最初に見えるスクリーンが最も重要です。

それが:

  • オンボーディング
  • ホーム
  • 認証
  • 紹介
  • ウェルカム
  • ダッシュボード

感じるべき:

  • 穏やかな
  • プレミアム
  • すぐに読みやすい
  • ビジュアル的に焦点を当てた

ルール:

  • 1つのプライマリフォーカルポイントを使用してください
  • トップスクリーンエリアを制御されたものに保つ
  • 見出しを短く保つ
  • 最初のビューポートを過度に積まないでください
  • 追加の統計、チップ、タグ、またはピルで埋めないでください
  • メインCTAを埋めないでください
  • 最初のスクリーンが通常のスマートフォンサイズで窮屈に感じずに機能するようにしてください
  • テキストの後ろに画像が使用される場合、フェード、マスク、またはソフトスクリムで明確な読みやすさを保持してください

強い優先:

  • メインステートメント用に1〜3行の短い行
  • 簡潔なサポートテキスト
  • 1つのクリアな次のアクション

回避してください:

  • 巨大なテキスト壁
  • あまりにも多くのマイクロラベル
  • あまりにも多くの重複するカード
  • 偽の企業の複雑さ
  • 「スマートフォンフレーム内のウェブサイトヒーロー」

13. セーフエリアとシステム領域ルール

モバイル画面の現実を尊重してください。

常に以下の認識を持って設計してください:

  • セーフエリア
  • ステータスバー領域
  • トップバーまたはタイトル領域
  • ボトムナビゲーション領域
  • ホームインジケーター領域
  • シートドッキングゾーン
  • ジェスチャースペース

しないこと:

  • 重要なコンテンツを危険な領域に詰め込む
  • トップとボトムのシステム領域を無視する
  • スクリーンをシステムロジックなしで機能的な側面のポスターのように見せる
  • 視覚的に危険なUIが配置される場所に重要なUIを配置する

モバイル画像は、ポスターではなく、実際のアプリスクリーンのように感じるべきです。


14. ナビゲーションルール

ナビゲーションは意図的で信頼性があると感じるべきです。

適切な場合、よく知られたモバイルパターンを使用してください:

  • アプリの主要セクション用のタブバー/ボトムナビゲーション
  • ドリルダウンフロー用のスタックナビゲーション感覚
  • セカンダリタスク用のシート
  • ローカルスイッチング用のセグメント化されたコントロール
  • 有用な場合のアプリバー
  • プライマリアクションとセカンダリアクションの明確性

しないこと:

  • ボトムナビゲーションを過度に積む
  • アプリを通じた主要なパスを隠す
  • すべてのアクションを同じくらい重要にする
  • タブ、シート、アクション間の不明なヒエラルキーを作成する

スクリーンセットは、信頼できるアプリフローを暗に示すべきです。


15. クリーンレイアウトルール

デフォルトで、ボックス内ボックスのモバイルUIに設定しないでください。

回避してください:

  • 巨大なネストされたカードスタック
  • どこでも浮遊表面
  • 5レベルのフレーミング
  • 理由のないダッシュボードクラッター
  • 一緒に詰め込まれた小さなウィジェット
  • 偽のオペレーティングシステムラベル
  • 装飾的なピルとマイクロステータス要素

好みます:

  • よりクリーンな表面
  • より強い空白
  • 少ないがより明確なコンテナ
  • ダイレクト階層
  • よりクリーンなグループ化
  • 可能な限りフラット構造
  • 多くの小さなノイズの多いものではなく、1つの強い構造的な動き

プレミアムモバイルスクリーンは、あまりにも多くのボックスの中に閉じ込められた感じがするべきではありません。


16. クリエイティブ画像方向ルール

このスキルは、ジェネリックなアプリUIジェネレータよりもクリエイティブであるべきです。

コンセプトを助けるとき、積極的に画像とアートディレクションを使用してください。

クリエイティブな画像使用法には以下が含まれます:

  • 写真主導のオンボーディング
  • 大規模な編集画像ブロック
  • 画像バックのヘッダー
  • 製品またはライフスタイル画像
  • シーニックまたは大気的背景
  • イラスト主導の入口スクリーン
  • レイヤード処理されたメディアカード
  • 主要なスクリーンの大胆なビジュアルカバー
  • 画像ストリップ、棚、またはカルーセル
  • 背景画像がタイポグラフィの後ろで部分的に明らかにされている

画像が事後考慮のように感じさせないでください。 怠け者の埋め草サムネイルを使用しないでください。 レイアウトとムードの一部として実際の画像ロジックを使用してください。

アプリカテゴリがサポートしている場合、好みます:

  • より強いヒーロー画像
  • より多くのビジュアルストーリーテリング
  • より豊かなアートディレクション
  • より記憶に残る画像の構成

17. 背景テクスチャとサーフェスルール

完全に無菌的でフラットな背景にデフォルト設定しないでください。

適切な場合、微妙または中程度の強度のテクスチャを導入して、より豊かなビジュアル雰囲気を作成してください。

許可された背景処理:

  • ソフトフィルムグレイン
  • 微妙なノイズ
  • 紙のようなテクスチャ
  • かすかにスペクル状の表面
  • ブラシをかけられた、または霜のようなテクスチャの感覚
  • トーングラデーションフォグ
  • 曇った雰囲気の深さ
  • 触覚的なマット表面
  • ぼんやりとしたグリッドまたはパターンテクスチャ
  • ぼやけた写真の背景レイヤー

テクスチャを使用して、UIを以下のようにします:

  • より高級
  • より触覚的
  • よりジェネリックでない
  • より多くアートディレクションされている

ただし:

  • 制御されたものに保つ
  • UIの読みやすさを保つ
  • 重いテクスチャがテキストを圧倒させないでください
  • ノイズのために導入しないでください

良いルール: テクスチャはムードをサポートすべきで、インターフェースと競合しない。


18. テキスト背後の画像ルール

適切な場合、制御されたプレミアムな方法でテキストの後ろまたは下に画像を使用してください。

推奨される処理:

  • 透過へのフェードを備えたタイトルブロックの下の背景画像
  • テキスト読みやすさをサポートするボトム・トゥ・トップグラデーションフェード
  • テキストがクリーンな部分の上に座るようにサイドフェードマスク
  • テキストの後ろのソフトブラーオーバーレイ
  • 背景色にフェードインしながら、コピーの後ろで部分的に見える画像
  • 見出しとCTAの下にスクリムを備えた大規模なエッジツーエッジのビジュアル
  • タイポグラフィの後ろで流血しているがやさしくマスクされた写真またはイラスト

これは特に有用です:

  • オンボーディング
  • ウェルカムスクリーン
  • メディアアプリ
  • ファッション/旅行/ライフスタイルアプリ
  • プレミアムコマースアプリ
  • ソーシャルアプリ
  • エディトリアルエクスペリエンス

ルール:

  • テキストは読みやすく保たれなければならない
  • フェード/マスクは優雅に感じるべき
  • 画像はまだビジュアル的に意味があるべき
  • 処理は意図的に感じるべきで、ランダムな不透明度のように感じない

回避してください:

  • 読みやすさのサポートなしでテキストの下の生画像
  • 泥棒のオーバーレイ
  • あまりにも多くの重いグラデーション
  • 階層構造を破壊するノイジーな背景

19. クリエイティブアセットルール

ビジュアル言語を改善する場合、洗練されたサポートクリエイティブアセットを使用してください。

許可されたクリエイティブアセット:

  • クリーンなマイクロイラスト
  • シンプルな幾何学的SVGスタイルのモチーフ
  • 小さなライン描画のアクセント
  • 微妙なベクターアイコン
  • 点線ガイド
  • アークシェイプ
  • 軌道線
  • 洗練されたスターバースト
  • 落ち着いた抽象的なマーク
  • ミニダイアグラムのような要素
  • 製品関連のアイコノグラフィ
  • 適切な場合のクリーンなステッカーのようなアクセント要素

これらのアセットは以下のように感じるべき:

  • クリーン
  • プレミアム
  • 抑制された
  • デザインシステムに統合
  • 気を散らさない、サポート的

しないこと:

  • ランダムなステッカーをスパム
  • 装飾的なアイコンでインターフェースを乱雑にする
  • 無意味なSVGアートを追加する
  • ブランドが明らかにそれを望まない場合を除き、幼稚な落書きを使用する

数個のクリーンなビジュアルアクセントは良い。 多すぎるとノイズになる。


20. アイコノグラフィルール

ジェネリックな開発者スタイルのアイコンパックやかすかなLucide風のアイコンバイブにデフォルト設定しないでください。

回避してください:

  • ジェネリックなライン描画デフォルト。テンプレートのようなアプリの感覚を作成する
  • 過度に使用されている開発者向けツールアイコン言語
  • あまりにも単純、あまりにもオープンソースのデフォルト、またはあまりにも区別されていないように感じるアイコン
  • アイコンの重みとスタイルをランダムに混ぜる

好みます:

  • クリーンなカスタム感じのアイコンシステム
  • 抑制されたブランド適切なアイコノグラフィ
  • ストローク線またはフィルされたロジックで一貫性がある
  • デフォルトライブラリのようなシンボルではなく、コンセプトが許可する場合、少し多くの文字を持つアイコン
  • デフォルトライブラリの検索の代わりに製品固有のアイコン決定

アイコンは以下のように感じるべき:

  • クリーン
  • 意図的
  • プレミアム
  • 統合
  • ジェネリックでない

21. モバイルアンチAI告げ口ルール

明示的に要求される場合を除き、これらを厳密に避けてください。

ビジュアルAI告げ口

  • 至る所で紫青のフィンテックグラデーション
  • 目的のないランダムなガラスカード
  • 目的なしの雰囲気ブロブ
  • 偽のネオンプレミアムルック
  • ジェネリックなドリブル風の浮遊ウィジェット
  • すべてのものに過度に大きなコーナー半径
  • システムなし階層の過度にレンダリングされた光沢のある表面

レイアウトAI告げ口

  • 偽のチャートダッシュボードスパム
  • 製品上の理由なしで繰り返される統計カード
  • 12個のウィジェットが注目を争っているように見えるホームページ
  • フローで複製されたスクリーン
  • 弱いコンテンツを持つ巨大な空のカード
  • スマートフォン形のウェブサイトではなくアプリスクリーン
  • 偽の企業の複雑さの代わりに良いモバイル階層

テキストAI告げ口

以下のようなフィラーフレーズを避ける:

  • あなたの人生を高める
  • あなたの可能性をロック解除
  • 次世代金融
  • シームレスな制御
  • これまで以上にスマート
  • あなたの日を変える

偽のブランド廃棄物を避ける:

  • Acme
  • NovaCore
  • Flowbit
  • Quantix
  • VeloPay

UIクラッター告げ口

  • あまりにも多くのピル
  • あまりにも多くのバッジ
  • あまりにも多くの小さなラベル
  • 偽のシステムマーカー
  • 無意味なアバター行
  • ランダムなチャート挿入
  • 製品の意味なしの装飾的なトグル

22. スタイルバリエーションエンジン

反復的なモバイルデザイン出力を避けるために、明確なビジュアル方向を選択してコミットしてください。

テーマパラダイム

以下のいずれかを選択してください:

  1. 清潔な光
  2. 深い暗い
  3. ソフトウェルネスニュートラル
  4. プレミアムモノクロ
  5. リッチアクセント主導
  6. エディトリアルリュース
  7. 楽しい消費者の色
  8. 落ち着いた生産性ミニマル

字体文字

以下のいずれかを選択してください:

  1. クリーンなシステムのようなサンス
  2. 洗練されたグロテスク
  3. 表現的なプレミアム表示+クリーンボディ
  4. ソフトヒューマニストサンス
  5. より鋭い製品サンス規律のある階層構造

構造バイアス

以下のいずれかを選択してください:

  1. リスト主導のユーティリティ
  2. カード主導のモジュール
  3. ダッシュボード主導の概要
  4. メディア主導のストーリーテリング
  5. プロフィール主導のアイデンティティ
  6. コマース主導のブラウズと詳細フロー
  7. チャット主導の会話フロー
  8. ウェルネス主導の落ち着きブロックリズム

画像アートディレクションバイアス

以下のいずれかを選択してください:

  1. エディトリアル写真
  2. シネマティックなライフスタイル画像
  3. ソフトイラスト主導
  4. 触覚的な抽象的な構成
  5. プレミアム製品画像
  6. 混合写真+ベクターアートディレクション
  7. ムーディーな大気的背景
  8. コラージュペースのレイヤード画像

テクスチャ/表面処理

以下のいずれかを選択してください:

  1. 超微細なグレイン
  2. マット紙テクスチャ
  3. 霧のようなグラデーション雰囲気
  4. ソフトノイズウォッシュ
  5. ぼやけた画像ヘイズ
  6. クリーンフラット(1つのテクスチャヒーロー領域を備えた)
  7. 触覚的なモノクロ表面
  8. 低不透明度のテクニカルパターン

パレットロジック

以下のいずれかを選択してください:

  1. 抑制されたモノクロ+1つのアクセント
  2. ウォーム中立パレット+シャープダークコントラスト
  3. クール鉱物パレット+クリーンハイライトアクセント
  4. エディトリアルクリーム/チャコール/くすんだアクセント
  5. リッチダークベース+洗練されたウォームアクセント
  6. ウェルネスソフトパレット(制御された彩度付き)
  7. 明るい消費者パレット(規律あるバランス付き)
  8. 脱飽和プレミアムパレット(1つの大胆なヒット付き)

署名コンポーネントセット

正確に4つを選択してください:

  • 大規模なヒーロー測定カード
  • コンパクト統計ストリップ
  • モジュール構成グリッド
  • メディアカルーセル
  • レイヤードプロフィールヘッダー
  • プレミアムセグメント化されたコントロール
  • ボトムアクションシート
  • フレーム付き製品カードスタック
  • プログレスリングブロック
  • メッセージバブルシステム
  • 設定グループセル
  • 写真主導のカードストリップ
  • スティッキーミニプレーヤー
  • コレクションシェルフ
  • 習慣トラッカーブロック
  • チェックアウト概要カード
  • ジャーナルエントリカード
  • 達成タイル行

装飾的アセットセット

正確に2つを選択してください:

  • ミニマルラインアイコンクラスタ
  • 抽象軌道線
  • 点線弧アクセント
  • スターバーストマイクロモチーフ
  • 丸いステッカーアクセント
  • 小さな方向矢印システム
  • ファイングリッドモチーフ
  • ソフトウェーブフォームライン
  • クリーンバッジグリフ
  • ミニ幾何学的マーカー

モーション暗示言語

正確に2つを選択してください:

  • スプリンギーカードリフトエネルギー
  • シートライズエネルギー
  • タブトランジション落ち着きさ
  • スタッガードリスト表示エネルギー
  • ソフトダッシュボードフェードアップエネルギー
  • パララックスヘッダードリフトエネルギー
  • カルーセルグライドエネルギー

これらはコード指示ではなく、画像方向のキューです。


23. カラーパレットルール

常にクリーンで制御されたカラーパレットを使用してください。

色は以下のように感じるべき:

  • 意図的
  • プレミアム
  • 一貫性がある
  • ジェネリックでない
  • ビジュアル的に落ち着き(表現的な場合でも)

ルール:

  • 内部ロジックを持つ強力なパレットを使用してください
  • カラー関係をクリーンに保つ
  • 1つまたは2つのアクセントに本当の仕事をさせる
  • 泥棒、偶然、またはカオティックなカラー組み合わせを避ける
  • ブランドが真実に適合しない限り、ジェネリックなスタートアップグラデーションを避ける
  • 特に正当化されていない限り、デフォルトの紫青AIパレットを避ける
  • ランダムな明るい虹の色使用を避ける
  • 多くの無関係な飽和色を一緒に投げるのを避ける
  • ブランドが明確に強い強度から利益を得る場合を除き、彩度の制御を保つ

パレットは以下のことができます:

  • 大胆
  • ソフト
  • ダーク
  • エディトリアル
  • 楽しい
  • 豪華
  • 大気的

しかし、それでもクリーンに感じる必要があります。

良いカラー方向はアプリを以下のように感じさせるべき:

  • 際立っている
  • アートディレクションされている
  • ブランド固有
  • 高価または思慮深く設計されている

ない:

  • テンプレートのような
  • ランダム
  • オーバーコック
  • ジェネリック

24. ジェネリック性ルール

アプリはデフォルトテンプレートのように感じてはいけません。

以下を受け入れないでください:

  • 標準的なジェネリックフィンテック
  • 標準的なウェルネスパステルアプリ
  • 標準的なソーシャルフィードクローン
  • 標準的な生産性ダッシュボードクローン
  • 個性なしの標準的なeコマースブラウズ/詳細クローン

コンセプトを以下に向かわせてください:

  • より強いアイデンティティ
  • より強いムード
  • より強いアートディレクション
  • よりクリーンだが、より独創的な構成
  • より良い画像処理
  • より区別されたアセット言語
  • より具体的なパレットロジック
  • より記憶に残るスクリーン対スクリーン厳格さ

結果は以下のように感じるべき:

  • 本当に設計された製品 ない:
  • 改善された照明を備えた再利用可能なスターターテンプレート

25. 常に単純ではないルール

すべてのアプリを超ミニマルな単純性に強制しないでください。

単純性は自体がゴールではありません。 クリーネスがゴールです。

これは以下を意味します:

  • スクリーンは読みやすい場合、豊か、レイヤード、表現的である可能性があります
  • フローは構造化されたままである場合、より強いビジュアル、テクスチャ、より多くの雰囲気を持つことができます
  • アプリはブランドが必要な場合、乱雑にならずに大胆な画像、より豊かな背景、より多くのアートディレクションを使用できます

許可されている:

  • 高度なレイヤリング
  • 制御されたビジュアルの深さ
  • より豊かな構成
  • より強い画像プレゼンス
  • 目的を持つ装飾的なアクセント
  • スクリーン内の複数のビジュアルゾーン
  • ブランドが必要なときのより多くの文字

許可されていない:

  • ノイズの多い複雑さ
  • 創造性として偽装されたクラッター
  • ランダムな装飾的な過負荷
  • 泥棒の階層構造
  • 読みにくいインターフェース

ルール: 常に単純ではない
常にクリーン


26. 画像システムルール

画像はすべてのアプリスクリーンで必須ではありませんが、表示される場合は重要に感じる必要があります。

アプリカテゴリがそれから利益を得る場合、画像を使用してください:

  • ソーシャル
  • eコマース
  • 旅行
  • ウェルネス
  • エディトリアル
  • 食品
  • ファッション
  • コンテンツアプリ
  • クリエイターアプリ
  • マーケットプレイスアプリ

画像使用のタイプ:

  • オンボーディングヒーロービジュアル
  • プロフィール画像
  • 製品画像
  • コレクションサムネイル
  • エディトリアル作物
  • 写真主導のカード
  • カバーブロック
  • メディアシェルフ
  • ギャラリーストリップ
  • テキストの下の背景画像でフェード処理
  • やさしくマスクされた画像ヘッダー
  • コアコンテンツの後ろの大気シーンレイヤー

ルール:

  • 画像使用はアプリカテゴリと一致するべき
  • 繰り返されたイメージモジュールは制御された比率を使用すべき
  • 画像は管理されたように見え、一貫性があるべき
  • アプリがフローが明らかにより多くが必要な場合、1つの単一の画像に依存しない
  • 異なるスクリーンは異なる画像を使用できますが、1つの製品世界に属する必要があります
  • 画像が重要な場合、意図的に感じるほど十分にそれをプッシュしてください

回避してください:

  • ランダムな埋め草サムネイル
  • 1つの綺麗なスクリーンとその後、画像がない
  • 矛盾した画像比率
  • 明示的にリクエストされていない限り、コラージュカオス

27. 固定モバイルメディアフレームルール

画像が使用される場合、それらをクリアで制御されたフレーム内に配置してください。

好みます:

  • 安定したアスペクト比
  • 一貫性のある作物動作
  • 繰り返し可能なメディアモジュール
  • クリア半径ロジック
  • クリーンなフレーミング

例:

  • オンボーディングヒーロー有界ビジュアルブロック
  • 一貫した比率の製品カード
  • 繰り可能な作物で編集シェルフ
  • 安定したフレーミングを備えたプロフィール/メディアヘッダー
  • 制御された比率を持つ画像行

回避してください:

  • ランダムな画像サイズ
  • 汚いスケーリング
  • 矛盾した作物システム
  • 制御されていないビジュアルノイズ

ゴールは信じられるモバイルシステム内の強いメディアです。


28. テキストルール

コピーは以下であるべき:

  • 短い
  • クリーン
  • 製品適切
  • 読みやすい
  • スクリーン有用

使用してください:

  • 簡潔な見出し
  • 信じられるボタンラベル
  • 最小限のサポートコピー
  • 本当に感じるスクリーンタイトル

回避してください:

  • ロレムイプサムの過負荷
  • 長い段落
  • 偽の感動的なフィラー
  • オーバーロードされたオンボーディング説明
  • 過度に技術的な埋め草ラベル

最初のスクリーンとオンボーディング特に:

  • コピーをタイトに保つ
  • より多くの行を強制するのではなく、言葉を減らす

29. テキストサイズと読みやすさルール

テキストが小さすぎるように見えてはいけません。

強いルール:

  • テキストが小さく感じられる場合、デザインはまだ完成していません

優先度:

  • 快適に読みやすいタイトル
  • 明らかに読みやすいボディコピー
  • 読みやすいラベルとボタン
  • 背景に対して十分なコントラスト
  • テキストブロックの周囲に十分なスペース
  • 見出し、本文、小さなサポートテキスト間の強力な階層

しないこと:

  • テキストを縮小してUI に適合させる
  • 小さな装飾的なラベルを使用する
  • ボディコピーが読みにくくなるようにします
  • スタイルのために読みやすさを犠牲にする
  • 保護なしで忙しい画像にテキストを配置する
  • スクリーンに小さくなるまで多くの情報を圧縮します

デザインの選択がテキストを小さくする場合:

  • レイアウトを簡素化する
  • コンテンツを減らす
  • 間隔を増やす
  • テキストを拡大
  • 必要に応じてコンテンツを別のスクリーンに分割
  • 必要に応

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
leonxlnx
リポジトリ
leonxlnx/taste-skill
ライセンス
MIT
最終更新
不明

Source: https://github.com/leonxlnx/taste-skill / ライセンス: MIT

関連スキル

汎用ソフトウェア開発⭐ リポ 39,967

doubt-driven-development

重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 1,175

apprun-skills

TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。

by yysun
OpenAIソフトウェア開発⭐ リポ 797

desloppify

コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。

by Git-on-my-level
汎用ソフトウェア開発⭐ リポ 39,967

debugging-and-error-recovery

テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 39,967

test-driven-development

テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。

by addyosmani
汎用ソフトウェア開発⭐ リポ 39,967

incremental-implementation

変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。

by addyosmani
本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: leonxlnx · leonxlnx/taste-skill · ライセンス: MIT