オリジナルのデザイン地図を作ってみた！〜OpenMapTilesとMaputnikを活用した地図スタイル〜
2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー
Speaker Deck This deck requires a password Password
徐々に日本でもメジャーなデザインツールとなっている「Figma」。前回の記事『FigmaのSmart Animateを活用したプロトタイプ入門』では、簡単にアニメーションを実現できる「Smart Animate」機能を紹介しました。 本記事ではデザイン制作とその後のコーディング作業を強力にサポートしてくれる「Auto Layout」について詳しく紹介します。「Auto Layout」はデザインを効率よく進められるだけでなく、デザイン段階でHTML・CSSコーディングの参考になる情報を追加できます。 デザイン段階での使い方はもちろん、Figmaでデザインを受け取ったエンジニアがどう考えて実装していくべきかまで紹介します。デザイナーはもちろん、Figmaで作られたデザインファイルを受け取る可能性があるエンジニアの方も是非ご覧ください。 Auto Layoutとは 「Auto Layout」とは
私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか？ 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた
エンジニアリンググループ 新規プロダクト支援チーム所属の荒谷(@_a_akira)です。 あまり知られていないかもしれませんが弊社では、2019年末から既に6つの新規アプリをFlutterで実装しリリースしています。 先日リリースされたデジカルスマート診療(以降デジスマアプリ)という医療機関向けに予約やキャッシュレス決済を導入・利用できるアプリもFlutterで作成しています。 digikar-smart.jp このサービスの立ち上げからリリースまでの開発期間は約3ヶ月で開発側の人数もPdM1人、アシスタントPdM1人、デザイナー1人、バックエンド2人、WEB フロント(クリニック向け管理画面)1人、アプリ(患者向け, Flutter)1人の構成で開発しています。 このあたりの開発体制については先日記事が上がっているので興味のある方はそちらを見てみてください。 www.m3tech.blo
どんなコース？Googleのエキスパートが授業をしてくれる、UXデザイナー養成オンラインコースです。UXデザイナーになるためのグーグル認定のトレーニングを受講でき、1日1時間ぐらい受講して、だいたい6ヶ月で満了できる。 トータルで以下の7コースを、半年かけて履修する。 1. UXデザインの基礎 2. UXデザインプロセスをはじめる 3. ワイヤーフレームと低精度プロトタイピング 4. UXリサーチと初期コンセプトのテスト 5. Figmaでの高精度のデザインとプロトタイピング 6. Adobe XDによるレスポンシブWEBデザイン 7. ソーシャルグッドのためのUXデザインと、就職の準備 とると何がおきるの？グーグル認定の証明書がもらえます。いろいろな会社を受けるときに、履歴書にかけるみたい。 印刷された履歴書、CV、またはその他の文書で、LinkedInプロフィールの修了証セクションにあ
はじめに こんにちは！ 社会人2年目を頑張っております、エンジニアの@b0ntenmaruです。 今年2月までリファクタリング専門チームにてcrowdworks.jpの技術的負債を返却するために奮闘しておりましたが、そこから現在まではユーザーの皆様に安心安全なサービスを提供するためにクラウドワークス 安心安全宣言のための施策を行っています。 リファクタリング専門チームについては以下をご覧ください。 engineer.crowdworks.jp qiita.com 施策による機能開発を行う際に直面した課題 施策では主にフロントエンドの機能追加をすることになったのですが、技術的負債によりスピードを維持しながら開発を続けることは困難な状態でした。 crowdworks.jpを取り巻くフロントエンドの技術スタックはざっくり書くと下記3つに分類できます。それぞれで発生している問題を簡潔にまとめます。
ブランディングデザイン会社neccoでデザインの仕事をしながら、7月からAfter Effectsの練習を始めました。 最初は全然使い方がわからず、「難しそうだしやめとこうかな、やっぱりデザインに専念した方がいいのかな」と思うこともありましたが、1ヶ月間練習を続けるうちにどんどん楽しくなってきました。 ▼はじめの頃に作ったもの モーショングラフィックス使いたい 案件のためにAfter Effect練習中🌱 楽しい〜！もっと上手になりたい☺️✨ pic.twitter.com/AzvZ1U1Pue — fuyuna🌷necco Designer (@fuyuna_design) July 5, 2020
Flows are just as important to good interfaces as individual screens are. Customers don’t land on screens from out of nowhere. Specific sequences of actions lead customers through your app as they try to accomplish their tasks. But as important as they are, flows are hard to communicate during the design process. Drawing out every state of a flow is too time-consuming. And drawings become instantl
ページコントロール（ドット）、ページトップの「送信」、プラス（＋）アイコン、並べ替えアイコンの4つは、テストでユーザビリティ上の問題を引き起こすことの多いiOSデザインパターンである。 4 iOS Rules to Break by Aurora Bedford, Raluca Budiu, Kara Pernice, and Amy Schade on July 9, 2015 日本語版2015年8月31日公開 巨大ソフトウェア会社（たとえば、AppleやMicrosoft、Google）はユーザーとデザイナー双方のためにデザインガイドラインを作成している。 おかげで、デザイナーや開発者側は、恵まれた条件のもとで、きちんとしたものになることが期待できるインタフェースの作成を始められるようになり、まったく新しいUI要素を考案する（そしてテストする）必要がない。 一方、ユーザー側も、すべての
こんにちは、id:hakobe932 です。 はてなでは有志が不定期の放課後勉強会を開催しています。今回は、ソウトウェア設計に興味のあるエンジニアがあつまって開催したドメイン駆動設計( = DDD)についての勉強会について紹介します。 実践ドメイン駆動設計を輪読 議論を中心にした形式 勉強会の成果 既存のソフトウェアの設計の整理と理解 ソフトウェア設計技術の習得 新しいプロジェクトの設計への活用 まとめ YAPCでも聞けます 最高に品質の良いソフトウェアをつくりたい! 実践ドメイン駆動設計を輪読 今年の3月に発売された、実践ドメイン駆動設計を輪読する形式で勉強会を行いました。 実践ドメイン駆動設計 (Object Oriented Selection) 作者: ヴァーン・ヴァーノン,高木正弘出版社/メーカー: 翔泳社発売日: 2015/03/17メディア: 大型本この商品を含むブログ (2
Pornographic Defamatory Illegal/Unlawful Spam Other Violations Thanks for flagging this SlideShare! Oops! An error has occurred.
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた． 今年のYAPCで，そのコマンドラインツールをつくるときにどういうことを意識して作っているのか？どのような流れで開発しているのか？といったことを語る機会をもらえた． 具体的な内容については，是非トークを聴きに来てもらうとして， スライドをつくるにあったって過去に読んだ資料や，よく参考にしている記事を集め直したので，その一部を参考資料としてまとめておく． UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本．古いが全然色あせてない． コマンドラインツールの作り方を書いた本ではないが，これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う．何度も読んで考え方を染み付かせた． 小さい
「Hooked ハマるしかけ 使われつづけるサービスを生み出す[心理学]×[デザイン]の新ルール」を読んだ。 サービスが「使われ続ける」ためには、顧客の「習慣」をいかにして作るかが重要だ。そこで「習慣が作られる過程」を以下の4つのフェーズで考えている。 トリガー アクション リワード インベストメント トリガー・アクション・リワードで行動が強化されるって話は心理学を学んだ人ならよく知っている話。スキナー箱の実験とかパブロフの犬とかを聞いたことがある人も多いのではないかな？ 僕もそこまでは知っていたのだけども、この本を読んで盲点に気づいた。これらの実験には当たり前だけどビジネスの視点はない。 ビジネス視点、つまり、自分が作ったサービスをユーザーに使ってもらおうと考えた時には、トリガーのコストが問題になる。トリガーは無償ではない。広告を打つのにもお金がかかる。そこで、ユーザが自分自身をトリガー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
