ワイヤーフレームのような感じかもしれません。ここまでやっておいてなんですが、手戻りを減らす意味でも手書きワイヤーフレームを先作った方がよいかもと思いました。生体、原子、分子をいじり直すことがしばしばあります。これは慣れだこれは慣れだ。手戻りしなければいいけど...。ブラッシュアップ、内容を入れます。我ながら面白みのないデザインになってしまいました...画面の全体の色味ががようやく現れるのでやはりまだ慣れが必要な感じがしますね。感想まだ自分が慣れていないのもあって、ちょっと難しいなーという印象です。ベースにしてデザインしているとイメージしながら作ると作りやすいかもしれません。ウェブデザインとしてだとつまらない感じになるかもしれません(スキルの問題な気もする)。デザインに特化したものと考えても良いかもしれません。作るのには効率的かもしれません。フルスクラッチでやるよりかはプロジェクトを変遷しながら醸していくのがいいのかもしれません。デザインガイドラインを基礎原理=分子・原子単位として、生体・テンプレートを定義していくという考え方がやりやすいフローなのかもしれません。手法と、普通のデザイン手法をミックインすると、フルスクラッチからでもいい感じになるかもしれません。フレームワークとの比較、スタイルガイドを原子から定義していくという手順を踏むことで、抜け漏れチェックとして使うことができ、実装チームとの合意が取りやすくなるような気がします。この手法で開発したアプリのメイキング記事を時々見かるようになってきましたが、多くはページのカンプを原子・分子段階から【想像して】開発するようです。これはなかなか難しいような気もしますが、慣れたら非常に効率的なのかもしれません。ベースで作成できないこともあるので、プランナーやエンジニアがプロトタイプレベルで作ることができる仕組み作りの福音になるかもしれません。依存度を減らし、デザイナーチーム内でも一人プレーを防止することができるかもしれません。懸念・実際に運用された時を考える単調な作業が続くのでデザイン作業に飽きがきやすいかもしれません。ベースは普段のスタイルでやるとよいのでしょうか。サービスが運用されていったときに、等価な原子の別原子(button2とか)ができる悪夢が見えます・・・。通常の方法より発生は抑えられるかもしれません。エンジニアが原子分子段階で組み立てたデザインは、レイアウト段階ではないので、プロダクションでは結局デザイナーが指摘してなおすなど、二度手間がおきてしまう可能性があるかもしれません。ケアするポイントにプライオリティをつけるのがいいのかもしれません。推進するオフィシャル的なサイト&システムを制作する上のツールです。実際に導入するときはここのツールを指針にするのが良さそうです。クラス定義が特徴的です。理解は深まるかもしれません。視点を持ってサービスデザインプロセスの改善に挑戦してみるのもよいのかもしれません。