乃木坂46の公式サイトのリデザインで学んだこと｜Miyu Otsuki
先日、ふとしたきっかけで乃木坂46の公式サイトをリデザインを思い立ち、スキルアップの一環も兼ねてトップページをリデザインをしていました。 そのリデザインから学んだことなどをブログに書きたいと思っていたのですが、公式サイトに掲載されているコンテンツの著作権上、なかなか難しいかなと思い、念のため乃木坂46の運営委員会に問い合わせてみたところ、営利目的でなければ使用しても大丈夫（ブログの掲載も可）との許可をいただいたため、こちらに書くことにしました（2/9 16:43：問い合わせの内容は、公式サイトのお問い合わせフォームから送信したため、画像の添付などはしていません。コンテンツの掲載許可は頂きましたが、運営委員会に直接デザインデータを送ったわけではありません）。 なぜリデザインをしたいと思ったのかもともとアイドルが好きで、アイドルグループの公式サイトをチェックする機会が多いのですが、乃木坂46の
スタートアップのデザイン責任者がやるべきことまとめ｜坪田 朋
最近、相談を受ける事が多いデザインマネージャーの役割を経験をもとに書き出してみました。長いですが、迷った時の辞書代わりに使ってもらえるとありがたいです。 ここでは会社の規模が30名以上、デザイナー5名程度を超えた組織をイメージしてます。ユーザー体験に責任を持つサービスデザイン責任者と組織責任者の話は混同しないほうが良いので、今回は組織責任者にフォーカスしてます。 全体のストーリーはこのスライドで掴めると思いますが、もう少し具体的に実行した事などをリスト化したので参考になればと思います。 デザイン責任者として実行した事まとめデザイン責任者の仕事は何かを学ぶために行動してみた ・実績を上げてる会社へ一週間研修に行かせてもらい、成果をあげてる理由を分析して、100ページ位のレポートを作った。 ・池田さん、土屋さん、深津さんなど有識者に相談して感覚を掴んだ。 ・それらの行動は自分自身の勉強にもなっ
Dropbox paperのチームが良いプロダクトデザインの為に大切にしている３つのこと｜Hiro Yamada（foriio founder）
12月1日にレッドブルスタジオ東京にて、Dropbox Japan主催のUnleash the World’s Creative Energyと題されたイベントがあったので行ってきました。 クリエイティブな仕事のコラボレーションをサポートするツールとなりつつある最近のDropbox。Design managerのKurt VanerさんがDropbox Paperの制作現場の様子と素晴らしいデザインの傾向というタイトルで話してくれたのでメモを残しておこうと思う。 先程言った通り、Dropboxはただのファイル共有サービスではなくなっている。（友達紹介だけで14GBくらいの容量を稼いでいたころが懐かしい…。）そもそもファイルの共有サービスというより、クラウドストレージ的な側面が最初は強かったサービスだが、今ではPaperやShowcaseというサービスなどがローンチされ、彼らが次のフェーズに
読みやすさのデザイン備忘録 | 深津 貴之 (fladdict) | note
noteのコア体験は、「読む楽しさ」と「書く楽しさ」だと考えています。 本来ならコア体験は、調査でしっかりと導くべきものです。しかしアカデミックなUXとは異なり、実際のスタートアップ環境では時間とリソースに限界があります。このため調べながらも、走り出さなければなりません。 まず序盤はヒューリスティック（経験）ベースのデザインを行いつつ、調査やテストが可能なところから、裏づけやチューニングを行う流れになりそうです。 以下、「読書体験」における「可読性」のパートのメモ。noteチームにとりあえず提案する予定の諸々です（現時点では個人の見解です）。基本的には「当たり前のことを、当たり前に」やる予定。「これもやっとけ」的なことがあれば、タイポグラファーの諸先輩の方々には、ぜひご意見をお伺いできればと。 書体をサンセリフ系に変えるべきか？デジタルでは、一般的にサンセリフ体の可読性は、ローマン体よりも
数千ページのワイヤーフレームを書いてきたWebディレクターがUI設計時に気を付けている８つのこと。 - 笑顔を創りたいWebディレクターの日常
なんかすごい思い付きで www.adventar.org に参加してみたんですけども。 気づいたらいつの間にか自分の日になっていて面倒くさくなってきて激しく後悔したびっくりしたという。 ぼくはWebディレクターでありデザイナーさんではないし、すてきデザインができるようなビジュアルセンスのようなものは、誠に残念ながら母上から授けられずにこの世に生を受けているものですから、"いわゆる"デザインはやらないんですが、その前の画面設計についてはワイヤーフレームなるものでいっつもやっておりますので、その観点からなんか書きましょうとそういうことですお母様（謎） そんなわけで、うぇぶぎょうかいのむめいでぃれくたーのお時間です。 Webディレクターとしてはえーと、もうすぐ丸１２年になります。そうするとまあ、たぶん数千ページは「ワイヤーフレーム」をつくってきたんじゃないかと思います。正確な数字はわかんないです
デザインのバージョン管理をする世界
僕の同僚のデザイナーはデザインツールにSketchを使っている。デザインは区切りのいいところまで出来ると保存してDropboxで共有してくれる。最近ではGitHubでSketchファイルを管理することも試しているようだ。GitHubで管理することで過去に遡ったり、ほかの人の作業をマージできたりする。ただ、Sketchファイルはプログラムのソースコードのようなテキストファイルではなくバイナリファイルだ。この違いでGitまたはGitHubの便利なものの多くが使えていないんじゃないか。 先日Sketchファイルをテキストファイル(JSON)として管理できるツールを公開したので、どういうモチベーションで作っているのか書いてみようと思う。ツールはまだ完璧ではないが、ぜひ使って意見をもらえたらと…思う 🙇🏻 テキストファイルになるとできることあぁ、デザイン全体のボーダーの色が淡くなったのいつだっけ
全ての人が知っておくべきデザイン・レイアウトの基本ルールとテクニック15選 - LITERALLY
デザイナーでなくとも、デザインについてのいくつかのルールを知っておくと、日々の生活で何かと役に立つ。今回は、誰もが知っておくべきデザインの基本原則・テクニックを紹介する。 1.デザインの基本原則を覚えよう 1-1.「1/3ルール」を覚えよう レイアウトや写真の構成を考えるときには、黄金比*1よりも「1/3の法則」が便利だ。上の図のように、全体を9等分割したとき、各線の交点（図の丸点）に主張したいモノを配置するようにする。これだけで、不思議とスッキリとしたデザインになる。技の1つとして覚えておこう。 1-2.端をそろえて線をつくろう 写真や文などの「要素の端」をきちんとそろえると、きれいに整理されて見える。これはデザインにおいてとくに重要な基本ルールだ。全てをそろえる必要はないが、縦にいくつか要素を並べる場合は常に意識しよう。 1-3.視線の流れを意識したデザインにしよう 情報がたくさん詰め
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
デザイナー横断組織の変遷 - クックパッド開発者ブログ
こんにちは。デザイナーの池田（id:tikeda）です。6月末までユーザーファースト推進室というデザイナーを中心としたユーザー体験について横断的に責任をもっている室の室長を勤めていました。7月からこのユーザーファースト推進室をなくし役割を各部室に分散させる体制変更を行いました。 ユーザーファースト推進室については、過去のインタビューやブログのエントリーをご覧ください。 はじめに サービス開発では、デザイナー・エンジニアといった職種毎に部を構成し各プロジェクトに派遣するようなスタイル（A）、ディレクター・デザイナー・エンジニアといった役割の異なる職種で部を構成するスタイル（B）、またこの2つを組み合わせたハイブリットのような組織が存在しており、弊社だけでなく開発の現場ではよりよい開発が行われるよう試行錯誤が行われていると感じています。 クックパッドではここ数年、アプリケーションエンジニアは各
フリーランスデザイナーの「つくること、はたらくこと」 - Speaker Deck
Transcript ϑϦʔϥϯεσβΠφʔͷ � ʮͭ͘ Δ͜ͱɺ ͨΒ ͘ ͜ͱʯ ࣗݾհ ͢Έ͔ͩ͋ ʢ֯ాҁՂʣ 8FCσβΠ ϯˍΠ ϥε τ Ϩʔλʔ େࡕࡏॅɺ ੍࡞ձࣾͰͷ8FCσβΠφʔΛܦͯ����ʹϑϦʔϥ ϯεʹɻ ओʹ-1αΠ τͷσβΠϯɺ ΠϥετΛ੍࡞͍ͯ͠·͢ɻ ͱ�ࡀͷஉͷࢠͱ ͏͕͗͞�ඖ͍·͢ɻ Ωϟ ϦΞ͚ͩ ��ʹ ɾ ɾ ɾ ࠓͷ͓͠ͳ͕͖ σβΠϯΛ࡞Δ ʮཧʯ ͱ ʮϏδϡΞϧʯ � ཧฤ � ϏδϡΞϧฤ � σβΠϯͷઆ໌ฤ ϑϦʔϥϯεͱͯ͠ಇ͘ Θͨ͠ͷ৺ಘ 01 02 ࠓͷͶΒ͍ ࠓͷςʔϚ ʮσβΠϯࡇʯ ɻ ʮσβΠϯղܾʯ ͜ͷ͜ͱΛͣͬͱ؊ʹ͡ ͖͚ͯͨΕͲɺ ࠷ۙͲ͏ͬ͘͠ Γ͜ͳ͍ɻ ࠓͷͶΒ͍ ݟ͚͕ͨͩσβΠϯ͡Όͳ͍ɺ ͰσβΠϯͷத Ͱɺ ͖Ε͍ͳ৭ɺ ͖ͯ͢ͳϑ
翻訳: WebAPI 設計のベストプラクティス - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
F1の変なデザインについて知ってもらいたい・改訂版 | 不思議.net
新車発表シーズンなので、芸スポやニュー速にF1スレが立つことがあります そこで「なぜF1がこんな形をしてるのか」を中心に、F1について書こうと思います ちょっとでもF1やモタスポに興味を持ってもらえればこれ幸い できるだけ、全く知らない人でもわかりやすいように専門的な所は大雑把に書きます 間違いもあると思うんで詳しい諸兄は補足訂正お願いします 大雑把な目次 ■空力とは ■ウィング ■グラウンドエフェクト ■ボディ形状 ■パワーユニット（エンジン）ついて ■ルール、レースについて 2年前に立てたスレの改訂版です（だいぶ変わったので） ※書き溜めです ※わからないことは聞いてください。自分も答えますが、詳しい方もお願いします
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
知財教材「デザイナーが身につけておくべき知財の基本」 | 経済産業省 特許庁
ユーザーインターフェイス解剖学（公開版）
フォントの選び方・使い方
ドメイン駆動設計基礎講座〜戦略編〜
api-guidelines/Guidelines.md at master · microsoft/api-guidelines
新着記事
http://weblog.metacircular-evaluator.org/blog/2014/06/22/http-api-design
@logo-motion · LOGO MOTION
