分かったつもりが一番怖い「行間を読む」という特殊能力を見事に解剖した本。久々に鳥肌が立ちました「わかったつもり」もとやま📚著書『投資としての読書』 @ysk_motoyama 年300冊読んで最新オススメ本や仕事術を厳選発信｜ビジネス戦闘力を上げたい方フォロー下さい｜『投資としての読書』著者｜グロービス講師←PwC｜個人事業でコンサル｜GLOBIS MBAオールA修了｜Amazonアソシエイト参加中｜noteで仕事術発信（note.com/yusuke_motoyama） note.com/yusuke_motoyam…
死ぬまでに一度は行くべき温泉旅館 15選｜まさゆき｜旅人
日本全国を旅してるまさゆきです。 これまで登録者1300人の旅系YouTubeを運営したり、気づいたらGoogleマップに2000個以上のピンが立ってました。 今回は「死ぬまでに一度は行くべき温泉旅館15選」を紹介します。 次の旅先を選ぶ参考にしていただければ幸いです。 名前のリンクからホームページに飛べます。正確な値段はご自身でお調べください。 不老ふ死温泉place ／ 青森 price ／ 2名1泊 32,200円~ 1名 13,900円~ 手を伸ばせばすぐ届きそうな日本海を間近に入る露天風呂は、まるで海に溶け込むよう。特に夕暮れ時は空の色が変化し、夕日も温泉も世界の全てが黄金色に包まれる。地球の美しさにため息が漏れる。 また白神山地のミネラル豊富な水が注ぐ海からとれる海の幸は絶品。料金をプラスすれば食べれるアワビの踊り焼きのゴリゴリとした弾力と、ジュワッと広がる旨みが忘れられな
なんとなく使っていませんか？ 括弧の種類と使い分け｜モリサワ note編集部
突然ですが、質問です！ 以下の文章で、登場人物が実際に声に出して言っている部分と、心の中で思い浮かべている部分はどこでしょうか。 「みんなはね、ずいぶん走ったけれども遅れてしまったよ。ザネリもね、ずいぶん走ったけれども追いつかなかった」と言いました。 ジョバンニは、 （そうだ、ぼくたちはいま、いっしょにさそって出かけたのだ）とおもいながら、 「どこかで待っていようか」と言いました。 青空文庫 宮沢賢治『銀河鉄道の夜』 https://www.aozora.gr.jp/cards/000081/files/43737_19215.html 答えは簡単ですね。 「 」の中の言葉が声に出して言っている部分、（ ）の中の言葉が心の中で思い浮かべている部分です。 前後の文章からも読み取れると思いますが、括弧の使い分けがされていることで、より分かりやすくなっています。 このように括弧類は主に文章内で会
知識０から、ちょっとUIデザインに詳しくなるnote｜やました
前回は、「UIデザインってそもそも何なの？」という概論的な説明と、UIデザイン未導入の組織の中でみんなでデザインを始めてみるための施策（プロトタイピングとユーザビリティ評価）を話しました。 今回はサービス、プロダクト開発において、デザイナーではない人でも知っていて損はないUIデザインの重要ポイントについて説明します。主に以下の３つのテーマについて順番に議論をしていきます。 デバイスやソフトによるUIの違い ユーザーにかかる身体的・認知的負荷を理解する UIの重要概念（ナビゲーション、インタラクションなど）を知る 「ちょっと」と銘打っておきながらめちゃくちゃ長いnoteになってしまったので、気になる項目だけ読むか、何回かに分けて読んでいただくことをおすすめします、。 ※どこか内容に間違ってる部分やご意見ありましたらコメントいただけたら嬉しいです。 デバイスやソフトによるUIの違い皆さんがお使
デジタル庁のサイトやばすぎるwww - Qiita
はじめに みなさん、デジタル庁のサイトはご覧になったことはありますか？今話題のデジタル庁です。 こちらが2023年6月現在のデジタル庁のサイトです。やばくないですかこれ？最初見たときこれ「やっばw」と思いました。これからこのサイトのやばさを語っていきたいと思います。 洗練されたシンプルさ、そしてデザイン 僕は最初見たときびっくりしました。「なんてシンプルで見やすいんだ！」官公庁のサイトですよ？官公庁のサイトといえば、細かい字がずらっと並んで見づらいイメージでしたが、デジタル庁のサイトはとことんシンプルさを追求して見やすくしてます。フォントもNoto Sans JPを使われててとても読みやすい。黒も #000 でなく見やすい色になっている。 やばいですねこれ。 そしてこのレイアウトを見たとき、余白のおかげでとても見やすいなと思いました。そこでChrome Dev Toolでレイアウトを見てみ
モーダルで悩むのは「もうだるい」ので整理した｜上園晃博（Uezono Akihiro)
はじめにモーダルって言葉はよく聞くけど、なんかわかっているようでわかってない、、 というデザイナーの方は多いのではないでしょうか？ そんなモーダルについて悩むのは、「もうだるい」ということで整理してみました。 今回は、モーダルとは何か、モーダルの制御レベルの違いとそれぞれの用途や目的、使い分けのポイントについて解説します。 それぞれの使い分けがチーム全体で意識できると、よりユーザーにとって負荷の少ない体験が設計できるようになると思うのでぜひ読んでみてください。 モーダルとはモーダルウィンドウの定義から考えるとモーダルの意味がわかりやすいです。 モーダルウィンドウとは ユーザーが操作している画面（親ウィンドウ）の上に表示される子ウィンドウのうち、ユーザーがアクションしない限り親ウィンドウを操作できないもの（参考：wikipedia） つまりモーダルとは、小ウィンドウを表示する際に親ウィンドウ
実案件から学んだ、本当に役立つUIデザインの法則50 ユーザビリティチェックリスト総集編｜i3DESIGN Designers
「ユーザビリティチェックリスト」ということで、UIデザインの「あるある」を取り上げ、改善案とセットでまとめています。 今回は、10のヒューリスティクスをもとに分類してみました。10のヒューリスティクスについては、以前記事にまとめています。 具体的な事例を一緒に取り上げ、よりわかりやすく解説していますので、こちらもあわせてご覧ください。 また弊社ホームページにて、ユーザビリティチェックリストをダウンロードいただけます。こちらも合わせてご活用ください。 1. システムステータスの可視化（Visibility of system status）1-1. 入力項目が多いときはステップを分けるフォームの入力項目が多い場合は、項目をグルーピングして画面を分割しましょう。 フォームが長すぎると、ユーザーは入力を途中で辞めてページから離脱してしまうかもしれません。 その上で、ステッパーを設置して現在の進捗
主観と客観を切り替える鍛錬｜Miwa Kuramitsu
突然ですが、ここに一つのプロダクトがあるとします。 そのプロダクトを見つめる視線には様々な種類があります。 そのプロダクトを利用しているユーザーの視点、利用していないが存在は知っているという人の視点、それをつくるデザイナーの視点、プロダクトを運営している会社経営者の視点… もしあなたがデザイナーであれば、デザイナーの視点だけが唯一自分で体感できる「主観」で、それ以外はすべて「客観」となります。 主観と客観のスイッチング プロダクトデザイナーはユーザーの期待通りに正しく動くしくみを設計し、「このプロダクトを利用した時に、ユーザーの生活はどう変化していくのだろうか？」と問いを立てながらアウトプットを評価していきます。 自らの考える理想像をデザインしながら、一方でそれに触れるユーザーの様子を想像する…プロダクトデザイナーは主観と客観を電気のスイッチのように瞬時に切り替えることに長けた人が多いイメ
勉強会メモ「THE GUILD勉強会 〜ユーザーインタビュー設計〜」｜Kanako Fukiage
THE GUILD主催のユーザーインタビューに関する勉強会に参加してきました。 今回はじめて社外向けに勉強会を実施されるということで、note枠で運良く滑り込めたのでレポートを書きます。 ※言ってることが違う！などの問題があったらお知らせください！修正します… 概要- #01 THE GUILD勉強会 〜ユーザーインタビュー設計〜 @DMM.com - 「ユーザーインタビューとは、ユーザーから直接意見を引き出す重要なプロセスです。実際にユーザーに会いに行くことによって、データからは読み取れない情報を引き出し、ニーズや課題を発見することができます。今回の勉強会ではユーザーインタビューをどう行えばいいのか、ゲストスピーカーの皆さんにお話していただきます。」 - 日時：2018年4月12日 19:30〜 - 場所：DMM.com - ハッシュタグ：#theguild_study session
『ふりかえり』が開発チームを強くする｜あっきー
ハンズシェアでは２週間のスプリントを切りスクラムを組んで開発をし、スプリントの終わりにふりかえりをしています。『アジャイルレトロスペクティブ』を読んでふりかえり手法を改善した取り組みを紹介します。 これまでの『ふりかえり』これまでスプリントレトロスペクティブ（ふりかえり）をKPTのフレームワークを使い改善を行ってました。 KPTとは、Keep/Problem/Tryの頭文字を取ったもの １．Keep（良かったこと、続けたいこと）を出す ２．Problem（問題、開発の妨げになったこと）を出す ３．Try（Keepを更に良くする案、Problemを改善する案）を出す ４．Tryに投票し改善していくことを決めるKPTでのふりかえりをしている中で下記のような問題を感じていました。 ・KPTが形骸化 ・スプリントでやったことをそんなに覚えてない ・チームの問題発見・改善に対してクリティカルなものが
分かりやすい仕様書を作るための『考え方』と『テクニック』｜だらねこ
私は分かりにくい仕様書が死ぬほど嫌いです。なんかもう、脳が受け付けないってくらい嫌い。なんでここまで嫌いなのかは後で話すとして、まぁ、とにかく嫌いなんです。 しかし残念なことに、分かりにくい仕様書は世の中に氾濫しています。私もゲーム会社でゲームを作る過程で他人の仕様書を見る機会があるのですが…… _(:3」∠)_ 我、この仕様書を読みとぅない。と言いたくなるような仕様書が飛び出してくることも多いです。 ある程度はフォーマットを事前に用意すれば防げますけど、そこから外れる必要が出てくると途端に分かりにくくなっちゃいます。 ただ、読みにくい仕様書を書こうと思う人はいません（と信じてますよ）。なぜこのような事が起こるのかと言えば、 ・分かりやすく書こうと思ってもどうすれば良いのかわからない という点が強いのかなと。思うのですよ。なのでこの記事では、 仕様書は何を満たせば「分かりやすい」になるのか
「奇妙な制度」をつくったら、意思決定の質もスピードも爆上がった話。｜Yuya Ishikawa /Gaudiy CEO
成長フェーズのスタートアップであれば、大小の差こそあれ、以下のような「意思決定にまつわる問題」を抱えているのではないでしょうか。 ・組織が大きくなってきて、意思決定のスピードが落ちてきた… ・関係者がぐんと増えて、尖った意思決定が思うようにできない… この問題に早めに手を打っておかなければ、スタートアップ的な成長が実現できなくなってしまう。意思決定の質とスピードを圧倒的に高める、魔法のような解決手段はないのか…？ そんな課題意識から生まれたのが、今回ご紹介する「蠱毒（こどく）」です。 名前だけ聞いても「？？」だと思いますが、簡単にいうと「限られた時間内に、ある課題やテーマに対して、参加者2名以上がディベート形式で解決策やプランを戦わせ、結論を出す」という意思決定プロトコルになります。 Gaudiyの「独自の組織づくり」については、PIVOTさんやSELECKさん、エンジニアtypeさんなど
デザインに活かせるフレームワーク20｜金 成奎
久しぶりのnote投稿です。今回は自分の勉強がてら、UX・情報設計・アジャイル開発など、デザインに関わる様々な局面で知っておくと役立つフレームワークを集めてみました。 有名なものからデザイン以外にも使えそうなものまで幅広く選んでいますので、気になるものがあれば改めて実作業に生かすなり、掘り下げて研究するなり、資料に生かすなりしてもらえると良いのではないかと思います。 （ちなみにここでいう「フレームワーク」とは共通して用いることのできる考え方や思考の型や枠のようなもので、いわゆるCSSフレームワークの類ではありませんので、その点ご了承ください） 1.UXの5段階モデル まずは有名なUXの5段階モデル。アメリカのUXデザイナーであるJesse James Garrett 氏が著書『Elements of User Experience（ウェブ戦略としての「ユーザーエクスペリエンス」）』にて提唱
エンジニアといい感じに連携したいデザイナーの取り組み｜taiga / 佐野大河
こんにちは、デザイナーの佐野大河 @sn_taiga です。今日はエンジニアといい感じに連携したいデザイナーの取り組みについて話します。 社内でC2Cというデザイナー同士で学びを共有し合う場があり、そこで話した内容を社外向けにまとめました。 👉 C2Cについて詳しく書かれている記事はこちら チームのエンジニアにヒアリングしてみた画面を設計するときや仕様を詰めるとき、伝えるとき、動作検証をするときなどなど、日々デザイン業務に取り組む上でエンジニアとコミュニケーションを取るシーンは多いと思います。 そんな中自分が「エンジニアが開発しやすいように」よかれと思ってやっていることを付箋に書き出し、チームのエンジニアにヒアリングをしてみました。 良いと思った付箋に印を付けてもらい、その理由等を聞きました💬 「エンジニアが開発しやすいように」というテーマで書き出してみたものの、むしろデザイナーがエン
デザイナーとエンジニアを巻き込んだワークフローの改善｜鈴木慎吾 / TSUMIKI INC.
「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar」20日目の記事です。 今年の５月から、社内でクライアントワークのチームから自社事業のチームに異動し、映画・ドラマ・アニメのレビューサービスのFilmarksで有料会員機能のPMを担当しています。 以前はUIデザインやアプリ開発、あるいはその中間的な仕事としてプロトタイプ開発やディレクションなどを経験してきました。 PM業の傍ら、社内のデザイナーとエンジニアの受け渡し部分の改善に取り組みました。その検討過程について紹介します。 要件定義・UIデザイン・開発間のワークフロー改善もともとFilmarks内ではディレクターがGoogleスライドなどで要件資料とGithub Issueをつくり、 デザイナーがSketchでUIをつくりZeplinで書き出したURLをエンジニアに受け渡し、エンジニ
デザイナーやエンジニアの作業効率が向上するFigmaの運用方法を考える｜osanai / ui designer
カンムでプロダクトデザインをしている osanai です。こんにちは。 前回ご紹介したコンポーネント品評会により、デザインシステムにおけるコンポーネントの課題について議論が進み、不必要なコンポーネントが生まれにくくなり、デザインの意図が汲み取りやすくなりました。 品評会をしていると、しばしばデザイナーとエンジニアで「Figma でもっと効率よくできないかな」という話題が出てきます。例えば「コンポーネントの Variants のパターンをパット見で把握したい」「目的のページやコンポーネントにもっと素早くアクセスしたい」などです。 運用方法に関する課題に対して少しずつ改善に取り組み続け、徐々にですが Figma でのデザインシステムの管理が効率化されつつあります。今回はこれまでに実施した Figma の運用効率化の取り組みをご紹介します。 プラグインで解決編目的のページやコンポーネントに素早く
チームの症状と処方の考察｜Megumi Kaneko
はじめに自己紹介を少しさせてください。 私はクライアントワークで約30名規模の開発チームに1年間ほどジョインしていました。役割は5〜10名のエンジニアで構成されるチームのプロダクトオーナーとしてだったり、UIデザイナーとPMのチームのスクラムマスターとしてだったり、色んな形でチームに接してきました。 その中で経験したことが、広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」を読んで色々整理されたので、チームが陥りがちな問題について稚拙ながら考察を書きたいと思います。 チームの健康状態とはチームの状態を表す指標として心理的安全性はよく聞きますよね。 広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」には心理的安全性について下記のように書かれていました。 「問題点の指摘」や「自分の弱
デザイナーが構造化シナリオ法を使う上での注意点｜UXリサーチャーの独り言／もりみ
noteをサボっていた（？）間、自社の中堅以上のデザイナー向けに、少人数制のUXデザインの12回連続講座を開催しました。やっていく中で、記録として残しておいた方が良いなと思ったことの第2弾として、今回は、構造化シナリオ法でデザイナーさんたちが引っかかっていたところと注意点を記載します。 1.そもそも、構造化シナリオ法とは構造化シナリオ法は、丸善出版から出ている「EXPERIENCE VISION」という書籍の中で、ビジョン提案型デザイン手法のフレームワークとして紹介されている手法です。 頭文字が「エ」「ビ」で海老のマークがついていることから「エビの本」と呼んでいます。 このフレームワークを簡単に説明すると、価値を扱う「バリューシナリオ」、ユーザーの活動を扱う「アクティビティシナリオ」、操作を扱う「インタラクションシナリオ」と階層別に分けてユーザーシナリオを構造化して書く手法です。 今回の講
GoogleのProduct Managerになりました｜natsumi.kondo
要約: 日本で文系営業職からキャリアをスタートし、アメリカに渡ったのちにGoogleのエンジニア系職種であるProduct Managerになった人の話です。 このnoteは、へぇそんなキャリアもあるんだ〜という一つの参考に、また、現状打破のために何かしたいけど何をすればいいのと思っている方へ、なにかシェアできたらと思いいろいろと書きました。長いです。 まずかんたんに私の経歴を。 慶應義塾大学環境情報学部卒業 →リクルートキャリアで法人向け転職支援事業の営業 (n年) →Google日本法人で大手法人向け広告営業 (4年) →Google日本法人で大手法人向け広告プロダクトスペシャリスト (2年) →Google米国本社でGlobal Product Lead (4年) 福島県で高校時代までを過ごし、留学経験もなく、リクルートキャリアで営業として楽しく働いていましたが、頑張っていたら運よく
いくらAIが便利だからって、子どもの教育データをGPTに流し込んで表を作らせようとする馬鹿教師は滅亡して欲しい｜山本一郎（やまもといちろう）
いくらAIが便利だからって、子どもの教育データをGPTに流し込んで表を作らせようとする馬鹿教師は滅亡して欲しい 確かにAIは便利なんですが、どこかの会社とのオンライン会議などのログをそのまま文字起こしにして出力し、それをGPTに食わせて要約してSLACKに流している馬鹿もいました。まあどこまでOpenAIを信頼するか（あるいは他のサービスと比べてマシと考えるか）にもよるのでしょうが、某ベンチャー企業で当方との打ち合わせのログをそのままGPT3.5に食わせて出力した議事録のサマリを送ってきたので、さっそく「何考えてんだおまえ」という話になりました。 なんでこんなことに気を使うのかというと、もちろん第一義的には私どものクライアントは潜在的にOpenAIの競合でもあるからなのですが、ただ、仮にAppleの仕事をしていた人がGoogleのAndroidOSでPixelが提供している文字起こしツール
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
