ANDPADでデザインを担当している後藤です。 エンジニア 「このボタン、分かりにくいですね」 開発を進めてて、エンジニアにこう言われたことはありませんか？ 「このボタンって、どう動くんですか？」 「このボタン、気がつきにくいですね。」 そういったときに、どのようにUIの意思決定をしたか、説明して納得してもらう必要があります。 今回は「並び替えボタン」で起きたケースを紹介します。 あまり目立たない機能ですが、データを整理することが多いBtoB向けサービスでは、要望が多い機能じゃないでしょうか。 【目次】 ・どこが分かりにくかったか？ ・エンジニアとデザイナーの通る思考回路は違う ・エンジニアの考えた解決策 ・画面上における機能の優先順位 ・機能単体のゴール ・まとめ どこが分かりにくかったか？実際の画面がこちらです。（※こちらは現在開発中の機能になります） さて、どこが分かりにくかったでし
ずっと前から積ん読状態だった「SQLアンチパターン」を読みました。 何年積んでたか分からないSQLアンチパターン読み終わったー。噂に違わずいい本ですねー。もっと早く読むべきだった。— @ketancho (@ketancho) 2018年3月6日 噂通りとても良い本で、まさに「エンジニアとしての血肉本」と言えます。1, 2年目の頃に読んでおくべきだったなーと少し後悔しています。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る 読んで終わりだと身につかないと思うので、自分なりのチェックポイントを言語化しておこうと思います。長くなってしまったので、章ごとに4つに分けたいと思います。この記事はその第一弾と
はじめに 驚き最小の原則（法則）という言葉があります。 Wikipediaの記事を引用すると http://ja.wikipedia.org/wiki/%E9%A9%9A%E3%81%8D%E6%9C%80%E5%B0%8F%E3%81%AE%E5%8E%9F%E5%89%87 ユーザインタフェースやプログラミング言語の設計および人間工学において、インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべきだとする考え方である。 要するに、使うときに「おやっ？」という驚きが少ないほうが良いプログラムであるといえます[1]。 [1]: どっちが驚きが少ないか迷う場面もかなり多いですが・・・ この記事では敢えて驚きの多いプログラムの書き方を紹介します。驚きの多いプログラムを読むとどんな気分になるか、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
