タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
フロントエンド開発は一般的に複雑性との戦いです。放ったらかしにしておくとますます複雑になり、変更するのが難しくなります。これまでにも、このような複雑さをどうにかして制御しようとして、Atomic Designをはじめとした様々な設計手法（デザインパターン）が考えられてきました。 しかし、React / Next.js を使ってチーム開発を行う際に、現状のデザインパターンでの運用では「どうもうまくいかないな」と思う場面に多々遭遇しました。そのような経験を踏まえて、「コンポーネントをどのように設計するか」「どのようにディレクトリを分けるか」を徹底的に考え、新しいデザインパターン「Tree Design」にまとめました。 Tree Design はまだまだ仮説段階です。今後弊社チームで運用していく中でブラッシュアップする予定です。しかし、他のフロントエンド開発チームがデザインパターンを再考する際
はじめに HTML+CSSコーディング専用の粒度分類を紹介します。 この仕組みは、デザインやワイヤーフレームなどの視覚情報を分解することに焦点をあて、分解した対象を部品化する流れも併せてガイド化した汎用手法です。 世の中には、コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト… といった様々な種別のサイト、Webページがありますが、これらの「完成予想図（視覚情報）」を同じ方法で分解して、コーディング用の部品にできます。 粒度と言えばAtomic Designが有名ですが、この「HTML Parts」も粒度そのものの考え方についてはAtomic Designの踏襲です。その上で「思考の入り方・捉え方」や「名称と定義」をコーディング側に寄せることで、CSS設計やコーディング業務を標準化しやすくしています。 ※この記事は標準化ノウハウ公開の一環とし
Atomic Design は難しい Webフロントエンド開発をしている人で Atomic Design を用いた経験がある方に会った時は、必ず 『Atomic Designどうですか？』と聞くようにしています。 大体の方はちょっと苦笑いをしながら『やっぱり難しいですねぇ』とか『試行錯誤しながらで...』みたいなことを教えてくれます。 私もメインの開発をする際に Atomic Design という枠組みを用いています。そして、同様に色々と悩んだのですが、このあたりについて納得がいく解釈ができたと思っています。 そこで、私の思う Atomic Design の難しさや、そう思う原因、どうやってそれを解消するかという点について、https://atomicdesign.bradfrost.com/ を適宜参照しながら共有したいなと思います。 そもそも Atomic Design 何やねん。な方
自社サービス『ツクリンク』はリリースから7年が経ちました。 直近でAtomic Designをベースにしたデザインシステムの作成と、CSS設計の変更をしたので紹介します📛 CSSの変遷現在の設計の話をする前にこれまでのCSSを紹介。 Ver１ 初回リリース時 昔懐かしいCSSです。Sassも使わずベタ書き。 #main .articles p { } #main .articles .header { }実は今でも一部で生きています。反省してます。探さないでください。 Ver２ リニューアル リニューアルをしたタイミングでCSS設計にはMindBEMdingを採用、SCSSを使い格段に書きやすくなりました。ファイルはBlockごとに分け、クラスの衝突を防いでいました。 # _block.scss .block { &__element { &--modifier {} } } # ディレ
はじめに この記事は、業務でフロントエンドのディレクトリ設計思想を変更した際の作業をまとめた記事です📕 それなりの規模のプロジェクトでの移行作業のため、通期のリリースサイクルに影響が出にくいようにリファクタリングを進めてきました。そこでの進め方や感想も含めてお伝えできればと思います。 前提 6年ほど運用しているReact Nativeのプロジェクトでの移行作業のお話です。 従来のディレクトリ設計思想はAtomic Designを採用していました。しかし、organismsのコンポーネントが300個近くにも及び、プロジェクトの規模が大きくなるにつれて様々な課題が浮き彫りになりました。これを機に設計思想の移行を決めました。 Layer型のAtomic DesignからFeature型のディレクトリ構造に移行していこうと思います😌 参考: ソフトウェアアーキテクチャの基礎 なぜ移行したか な
はじめに HTML+CSSコーディング専用の粒度分類を紹介します。 この仕組みは、デザインやワイヤーフレームなどの視覚情報を分解することに焦点をあて、分解した対象を部品化する流れも併せてガイド化した汎用手法です。 世の中には、コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト… といった様々な種別のサイト、Webページがありますが、これらの「完成予想図（視覚情報）」を同じ方法で分解して、コーディング用の部品にできます。 粒度と言えばAtomic Designが有名ですが、この「HTML Parts」も粒度そのものの考え方についてはAtomic Designの踏襲です。その上で「思考の入り方・捉え方」や「名称と定義」をコーディング側に寄せることで、CSS設計やコーディング業務を標準化しやすくしています。 ※この記事は標準化ノウハウ公開の一環とし
Atomic Design、どうですか？ フロントエンドをやってる系の人たちはぶっちゃけしっくりきてないとおもいます。 僕を含めて、当初より「これ微妙やね（まぁ流行ってるし適当ではあるから使っておくか）」という見解の人はチラホラみかけました。 それもそのはずです。 朧げな記憶ではありますが、Atomic Designはそもそもプログラマーのために作られたメソッド……ではありません。 デザイナーの方が考案した、デザインシステム構築のためのフレームワークです（そうだよね？）。 Sketchでデザインコンポーネントを作成する際に（たしかSketchだったはず。懐かしいですね）、Sketch上のコンポーネントの再利用性を高めて使いやすくするためのものだったのです（だったはずです）。 それが「増えまくったReactコンポーネントをいい感じにフォルダわけしてえなあ」という需要と噛み合って流行ったと認識
今回はUIと少しUXのお話ですこんにちは。フューチャーでUXの専門家をさせていただいている平川といいます。 フューチャー技術ブログでは、【Figma】を使ってチームでUI/UX設計するといいこと の記事を書いた久保さんと同じチームに所属しています。 PJでは最高の顧客業務を目標に、業務、UX、UIの設計と、アプリ開発をさせていただいています。 今回はPJの現場でUXとUIのデザインを通して、Atomic Designの導入はどのような結果を生んだのか、Atomic Design導入に際しての課題や取り組み方のコツなんかをお伝えできればと思います。 Atomic DesignAtomic Designは、Webページやアプリケーションを作成する際に、UIの最小要素（原子）からの組み合わせで構築していく考え方です。Atomic Designの提唱者はHTMLタグを元素周期表に見立ててそれを原子
2022.07.20 開発×テスト LT会 - vol.3 #devtestlt
食べログFE（フロントエンド）チームの金野と申します。 以前の記事で、jQuery+Backbone.jsからReact/TypeScriptへのリプレースを進めていることをご紹介しました。 リプレースした部分では、Atomic Designを採用しています。 今回の記事では、採用した理由や食べログでの分類方針についてご紹介します。 Atomic Designを導入した目的Atomic Designを導入したねらいは以下になります。 ・コンポーネントの責務がより明確になる ・見た目の粒度だけでなく、ロジックの責務も明確にできる ・「ドメインが入るか／入らないか」。「抽象的か／そうでないか」の区別が明確になる ・世間的にも浸透している概念のため、デザイナー・エンジニア間の共通言語を作れる 食べログではもともとUIコンポーネントをFLOCSSの考え方に従ってレイヤー分けしていましたが、以下の課
かれこれ４、５年くらいAtomic designに触れてきて、こんなに使いづらいのになんで使ってるんんだっけ？ってなったので、脳死と妥協のAtomic designを辞めたいというモチベを高め、重い腰を上げて考えてみました。 前提 今回の趣旨はあくまでも共通コンポーネントにフォーカスしています。なのでpages(人によってはscreens,containersと命名しているかも)は考慮しません。 また、atomic designのデザインサイドの思想そのものについては言及しません。あくまでもディレクトリ構成の運用上の課題にフォーカスします。 ディレクトリを分ける意味とは そもそも、components/配下をフラットに並べずにグルーピングする目的は何でしょうか。 使いたいものが明確な場合はディレクトリ構成はあまり寄与しません。「あのButtonコンポーネントを使いたい」であれば、ディレクト
PLAIDでエンジニアをしている @kei-tamiya です。 本記事は PLAID Advent Calendar 2019 の 20日目になります。 社外で個人的に開発しているプロジェクトでAtomic Designを採用しており、ある程度知見が溜まったので、1つの運用例としてご紹介したいと思います。 前提 どんなプロジェクト？ もともとVue.jsを用いて動いているアプリケーションを1からリファクタするプロジェクト 別リポジトリに、Nuxt.js, Typescript, Vue Apolloを使用して開発 フロントエンドエンジニア3〜4人、デザイナー1人 全員リモートで、週1で30〜60minぐらいミーティングできる GraphQLのAPIサーバーはおよそある状態 主に大きなページごと（Userに関するページなど）をエンジニア1人が担当して開発する もともと課題に感じていたこと・
Web サイトを構築するにあたって、よく参照されるコンポーネントの分類手法として、Atomic Design と Presetational and Container Components があります。 Atomic Design … UI の粒度と具体性によって 5 レベルに分類するPresentational and Container Components … 「表示」と「振る舞い」の役割で分類するここでは、それぞれに関して概要をざっと眺めた上で、Next.js プロジェクトにどんな形で適用していけばいいかを考えてみます。 Atomic Design とはWeb デザインにおける UI コンポーネントの分割粒度の考え方として、Brad Frost 氏の Atomic Design があります。 Atomic Design - Brad Frost 氏のブログ記事Atomic Des
がんばらない
はじめに VALU Advent Calendar 2019 11日目 (!) の記事です! VALU ではデザインに Atomic design (アトミックデザイン) を採用しています。 本記事では，VALU のデザイナーが作成した素敵な Sketch シンボルを差分なく反映し，かつ変更に耐えうる SwiftUI を運用するための方法をご紹介しようと思います。 昨年の VALU Advent Calendar にて，Sketchと1対1を目指すAtomic designなStoryboardの作り方 を投稿しました。本記事はそれを SwiftUI で行ったものです。まだご覧になっていない方は先にご覧ください。 Highlights SwiftUI を利用することで，「ファイル数増加」「子View更新時の伝播」「親ViewのConstraints破棄」など，UIKit (昨年の実装) で
2019年7月31日、Vue.jsに関する知見を共有する勉強会「Roppongi.vue #2」が開催されました。Vue.jsをさまざまな角度から掘り下げるライトニングトークには4人が登場。「Atomic Designと刺さらない現場」に登壇したのは、果物リン氏です。登壇資料はこちら Atomic Designと刺さらない現場 果物リン氏：前回もRoppongi vueでしゃべらさせていただきました果物リンです。 今回は実質懇親会LT的なノリだと思いますが、「Atomic Designと刺さらない現場」というタイトルでしゃべりたいと思います。今回の内容はちょっと若干過激なんじゃないかなと思うんですけど、まあ、お気持ちなのでというところで。 みなさん、Atomic Design使っていますか？ 使ったことがあるよという方、手を挙げてもらっていいですか？ （会場挙手） おっ、半分はいかないかな
Brad Frostが提唱したAtomic Designはすでに多くの場面で採用されていますが、もともとがUIデザイン手法であるため、フロントエンドアプリケーション開発におけるコンポーネントの分類に直接的に適用できないものも出てきます。 そこで、最近採用している"Applicational Atomic Design"について具体的なコードとともに紹介していきます。 Reactを前提として説明していきますが、VueにはもちろんAngularを用いたプロジェクトに対しても、同様の手法を適用することができるでしょう。 紹介する方法論をnext.jsに適用したアプリケーションのソースコードは、GitHubに公開しています。 "Applicational Atomic Design"とは? Atomic Designに基づきつつ、アプリケーションの振る舞いやドメインモデルとの関わりを視点に加え、フ
はじめに OHEYAGOの開発をしている田渕です！ OHEYAGOはtoCサイトなので、UI・UXを重要視しており、チームとしてデザイナーを2人抱えております。 デザイナーは他業務との兼任ですが、それに対してエンジニアは3人なので、デザイナーの割合がとても多いチームです。 エンジニアとデザイナーで共通認識を持ち、開発効率を向上させるために、デザインシステムとしてAtomic Designを採用していました。 しかし、運用がうまく行かず、ある問題が露わになってきたため、Atomic Designをやめようとしている最中です。 そこで、上手く行かなかった知見の共有として、どういった問題が出てきて、どのようなデザインシステムに舵を切ろうとしているのかを紹介します！ 最初にAtomic Designを採用した理由 当時のチームには、Reactでの開発経験が多い人がおらず、コンポーネント設計も手探り
フロントエンドのテックリードのみゅーとん(@_mew_ton)です。 弊社では新しいプロジェクトを立ち上げの際に、Nuxt3を採用することにしました。 また、従来までのプロジェクトの反省点として、 Atomic Design を考慮して実装することにしました。 ただ、Atomic Design について調査していくと、Atomic Design の考え方をそのままディレクトリに落とし込んでいくのはどうやら悪手のようで、Google サジェストからも、いくつか失敗のケースが散見されました。 そこで、Nuxt3 のディレクトリ構成にマッチするような Atomic Design の構成を考えてみたので紹介します。 Atomic Design とは Atomic Design とは、パーツ単位でUIデザインを設計する手法です。 Atomic Design 自体は 5年以上前から提唱されている設計方
DROBE では React のコンポーネント設計に Atomic Design を取り入れていますが、特にデザインにおける設計と React における実装という目的の違いから、実装していると微妙に概念が取り入れ辛く、しばしば方針に迷う事があります
この記事は2020年10月3日にWCAN 2020 Design Special 〜デザイン力の基本とブランドづくりの一歩〜で行うLTのスライドと原稿です。 投稿時点ではまだイベントは始まっていませんが、先んじて公開します。 以下が実際の内容です。 それでは「実装まで視野に入れるならAtomic Designを辞めましょう」と題して私のLTを始めます。 みなさんこんにちは。Increments株式会社でデザイナーをしている綿貫佳祐と言います。 Incremetnsではこれらのサービスを展開しております。 普段の業務からこれら3つ、インターフェースだけでなくフロントエンドまである程度担当していまして、両方の視点から見た話をしていきます。 最初にお断りしておきますと、現在Atomic Designを使っている方々を否定するつもりはありません。 ただ、主観ですがAtomic Designは「汎用
![[LTスライド&原稿]実装まで視野に入れるならAtomic Designを辞めましょう - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/30d660c2db36b5e1ced579d741f3983eeba15e84/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCTFQlRTMlODIlQjklRTMlODMlQTklRTMlODIlQTQlRTMlODMlODklMjYlRTUlOEUlOUYlRTclQTglQkYlNUQlRTUlQUUlOUYlRTglQTMlODUlRTMlODElQkUlRTMlODElQTclRTglQTYlOTYlRTklODclOEUlRTMlODElQUIlRTUlODUlQTUlRTMlODIlOEMlRTMlODIlOEIlRTMlODElQUElRTMlODIlODlBdG9taWMlMjBEZXNpZ24lRTMlODIlOTIlRTglQkUlOUUlRTMlODIlODElRTMlODElQkUlRTMlODElOTclRTMlODIlODclRTMlODElODYmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTBmOTkwMjg0ZWUwZWFmZjJmNzFlNTZhNzIyYmI4YTdm%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB4cnhveGN4b3gmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTM1ZTU2NWZhNTc3MDRmZTExYzYzNWYxYzE5OGU0MGQ4%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gUWlpdGHmoKrlvI_kvJrnpL4%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D3f424a24c53e3c99e7616d2c0797c239)
タイトルは記事の内容を読み込ませ、chatGPTに作成してもらいました。 強いタイトルですが、Reactの初学者向けにAtomic Designとは何なのか、それに則ってコンポーネントを分割するにはどのようにするのかを解説しています。 後半では実際にAtomic DesignでTodoアプリを作成していますので試してみてください。 （有識者はアドバイスなどがありましたらどうぞよろしくお願いします） Atomic Designを理解する React開発者にとってのAtomic Design Atomic Designとは Atomic Designの5つのレベル Atomic Designのメリットとデメリット React/TypeScriptで作るTodoアプリ React開発者にとってのAtomic Design Reactの開発者がAtomic Designを使う理由は、コンポーネント
はじめに Flutter は宣言的 UI フレームワークを採用しており、階層的に UI を実装することが可能となっています。 Flutter を始めとして SwiftUI や React Native などの台頭により、近年では宣言的 UI でのネイティブアプリ開発がトレンドとなっていますが、その原型と言えるものは HTML の言語仕様として Web フロント開発では既に定着していました。 その Web フロント開発において注目されているコンポーネント設計手法があります。それが Atomic Design です。 この記事では、Flutter による宣言的 UI 実装と Atomic Design によるコンポーネント設計を組み合わせ、堅牢かつ再利用性の高い Widget 及び画面を実装することを目指します。
#デザイン #CSS 前提として、私は大規模に Atomic Design で構築されたコードベースを運用したことがない。 どちらかというと初めて見たときから一貫して食わず嫌いし続けているタイプである。 自分はそれなりに規模のある #フロントエンド を扱ってきたと思うし、 #デザインシステム の類も作ったことがある（今もやっている）のだが、なぜ Atomic Design に良さを感じないのかを思いつき次第まとめていく。 （余談だが自分の務めている会社はデザイナにも Atomic Design を好む人がいないのでこの辺で揉めたことがない。むしろ「やっぱ無理でしょ」「だよねー」ぐらいに意見があっていると思っている） ------ 人間に /components より細かい分類は無理 実際世の中でよく批判されてる部分（ どこまでが atom? molecules? みたいなので揉める ） 開
Atomic Designでコーディングしてたら規約ができたので、それを使って更にコーディングしてみた。Vue.jsAtomicDesign Atomic Designとは？ 知っている方は、こちらまで読み飛ばして下さい。 Atomic Designには階層と、それぞれの役割がある 原典によると、 Atoms(原子) Molecules(分子) Organisms(生体) Templates(テンプレート) Pages(ページ) の５つの階層がある。それぞれ説明すると、 Atoms 原子 現実世界における原子 ＝ それ以上分割できない ユーザーインタフェースにおける原子 ＝ 分割すると機能しないから、それ以上分割できない これをみて、「分割できるかどうか」＝「粒度」を追い求めてしまうことが多いが、それはあまり意味がない。 大事なのは粒度ではなく、Atomにするメリットを享受できるかどうかに
こんにちは！BrunchMadeの@はせがわです。 この度、株式会社BrunchMadeに創業メンバーとしてジョインしました🙌 今回はそのBrunchMadeのホームページ制作にあたって、学んできたことを共有していきます。 設計：Atomic Design 言語：Typescript フレームワーク：Next.js UIライブラリ：Mui（Material-UI） はじめに フロントエンド開発している方はほとんど聞いたことあるであろう「Atomic Design」。 そもそもAtomic Designはデザインシステムを作成するための方法論ということもあり、UI設計の答えではありません。そのため、実際のフロントエンド開発に取り入れようとすると意外と手こずることが多いのではないのでしょうか？ また、記事・サイトなどを検索しても説明は載っているが、具体的なコードが少ない。Organismsの
言葉は感情の近似値である。その感情と言葉の誤差を最小化しよう ～コミュニケーションにおけるアナログ/デジタル変換の課題に立ち向かう～
①デザインの効率が格段に上がる Atomic Design では画面要素を細かくコンポーネント化しています。ですので、一度作成したコンポーネントを配置するだけで、画面に表示することができました。特に効率が格段に上がった場面として、画面開発中にUIが追加された際に、すでに作成済みのコンポーネントを再利用することで、新たなパーツをすぐに作成※することができたという場面がありました。 ※すでに作成済のボタンコンポーネントとテキストコンポーネントを組み合わせて、ボタンテキストコンポーネントをデザインできたこと ②ページデザインに統一感が生まれる 今回複数人で複数の画面開発を行いました。全員が同じ画面を実装したわけではないため、画面によって必要なコンポーネントは異なります。しかし、画面の実装方法が定まっていたため、誰が実装しても画面の統一感を保つことができました。実際に、手順に沿って開発するだけで初
デザイナーはアプリケーション全体をデザインしてから細かい部分を調整して行きます。先ずは生命体を作り、それを原子までに分割して調整しているような作業です。一方、プログラマーはデザインされた画面から再利用できる部品を作り、それらを組み合わせることで動くアプリケーションを構築して行きます。原子を組み合わせて、生命体を作っていくような作業です。全体から細かい部分に精度を上げながら設計して行き、また細かい部分から作り始め、徐々に全体に組み合わせて行く、一連の流れのようなプロセスと捉えることができます。 本記事では上記のプロセスの例として、デザイナーがワイヤーフレームを作り、画面の各要素を分割します。次にプログラマーは各要素を部品として作り始めるます。見た目を左右するビジュアルデザインに対してはスタイルを簡単に変更できるようにして、デザインの変更を適用しやすくなります。このようなプロセスを実現するには
こんにちは。ひらやま（@rhirayamaaan）です。 この記事は、GLOBIS Advent Calendar 2020 に参加している記事です。 さて、Atomic Design という言葉が巷で話題になってからだいぶ日は経ちますが、私の「Atomic Designってデザイナーには難しくない！？という話」という記事の LGTM 数も現時点（2020/12/08 時点）でゆるやかに増加傾向にあり、まだまだ Atomic Design を考えている人たちは多いのではないかと思います。 そんな中で、昨今「OOUI」という言葉をよく耳にするようになりました。 ソシオメディアの上野さんが「オブジェクト指向UIデザイン」という本を刊行されたことで、より一層この言葉が世に広がったように思えます。 オブジェクト指向というものを UI デザインの領域に持ってくることで、エンジニアがオブジェクト指向で
こんにちは！ クレイのasachunです。 ここ1年ほど DocBase はフロントエンドのフルリプレイスを行っており、てんやわんやの日々を送っておりました。 フロントエンドの改修にあたり、Figma + Atomic Design でUIコンポーネント集を制作しました。今回はその作業の経緯、どのように進めていったか、よかったことや大変だったことを書いていきたいと思います！ この記事の前提として必要そうなので、私のスキルはこちら↓ HTML(Haml, Slim), CSS(Sass) でのマークアップ経験7年ほど Photoshop, Illustrator, XD, Figma は一通り使える メインのデザイナーとして1からデザインカンプを作った経験はなし ここ数年は DocBase のUIデザインをちょこちょこやっています Webとは関係ないけど似顔絵が得意です ガッツリ実装はできな
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![敢えて言おう、「非常口」のないソーシャルメディアは（Blueskyであろうと）カスであると | p2ptk[.]org](https://cdn-ak-scissors.b.st-hatena.com/image/square/b4f1cb66270004e470f1bbc8ed28a45b7a7e69c4/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fp2ptk.org%2Fwp-content%2Fuploads%2F2024%2F12%2Ffire-exits.jpg)
