なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita
なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】UXUIDesignUIデザイン画面設計 1.はじめに エンジニアの私がデザインを本気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。
【フロントエンド初心者向け】ユーザビリティを上げるちょいテク
フロントエンドの開発が初めての人が意外と抜けがちな観点をまとめてみました。 初めにざっくりと概要を話すと「デザイナーが作るデザインでは表現しづらいもの」をまとめたものになります。 デザイナーが作るデザインは静的なものなので(たまにがっつりプロトタイプを作ったりもありますが)、いわゆる"状態"を表現するのが難しかったり抜けたりしがちです。 具体的に言うとローディング、Empty、エラーなどです。これらをよしなに補完できるフロントエンドエンジニアはデザイナーからもきっと「頼りになるぅ！」と思われること間違いないでしょう。 と言うわけでそんな例を紹介していきます。 今後も思いついたら追加する可能性が無きにしも非ず。 ローディングを出そう こう言うクルクルするやつとか こんな感じでシュインシュインするやつがあります。 基本的にユーザがアクションを起こした時に待たせる場合は必ず表示させましょう。 ロ
【OOUI】設計を改善したらユーザー（オカン）が使ってくれるアプリになった話 - Qiita
▼この記事では、前回の記事で紹介した自作アプリを題材にしています。 前回の記事を先に読んでもらえると、この記事の内容がより理解しやすくなると思います！ 【初アプリ】未経験がFlutterで肉牛繁殖農家のためのアプリを作ってみた こんにちは、Takuです。 先日、Flutterで肉牛生育記録管理アプリ「Memow」をリリースしました。 このアプリのユーザーである自分のオカンオトンは、特にこちらからレクチャーせずとも問題なく使いこなしています。 基本的にオカンがデータを入力し、オトンは共有データを閲覧するという使い方をしているようです。 それまでアナログ管理をしていたオカンオトンがすんなりこのアプリを使用できていることについて、前回の記事を読んでいただいた方から「驚いた」という反応を多くいただきました。 ユーザー（オカンオトン）がこのアプリを使えている理由を自分なりに分析する
快適なUXを実現するOptimistic Updates(楽観的更新)とは何か
先日、とあるJavaScript関連の記事を読んでいたところ、"Optimistic Updates" という技術が紹介されていました。 日本語に直すと "楽観的更新" といったところでしょうか。 はじめて聞いた言葉で、日本語の記事も見当たらなかったため記事にしてみます。 Optimistic Updatesとは Optimistic Updatesというのは、ネイティブアプリやSPA(Single Page Application)などで使われる技術で、非同期の通信処理が成功するという前提(楽観)のもとに、通信のレスポンスを待たずに次の処理を行うというものです。 最も多いOptimistic Updatesの使い方は、UIへの反映をリクエストの結果を待たずに行うというものでしょう。 Optimistic Updatesの例 例えば、よくある「いいね」ボタンのようなものにOptimisti
プロトタイプを使って要件をまとめるときに気をつけるべきこと
JoeはUX/CXコンサルタントとして長年のキャリアがあり、現在はUXに関する書籍、講演などを多数手がけるUXの伝道師です。 「要件を決めた時に想像していた仕様と違う」 開発チームのほとんどが、プロジェクトの中でも最悪のタイミングで、このような発言を聞くはめになります。大抵、このようなことが起きると、開発者は自分を正当化しようと怒り出します。正確に要件を定義していなかったとステークホルダーを叱責するのです。 これはもっともな怒りではあります。しかし、同時にこの状況の責任は私たち開発側にもあることも事実です。 私たちは認識のズレを埋めるため、要件に必要なことをステークホルダーに伝えてきれていません。この記事では、開発の現場で起きがちなことについて話していきます。 要件をまとめることの背景にある厳しい事実 要件が決められるのは、大抵ステークホルダーとのミーティングのときです。ステークホルダーは
フォームバリデーションと送信ボタンの状態の最適解 - Konifar's ZATSU
タイトルを見て「あーあれね」と思った人もいると思うが、アプリデザインの世界ではすでに議論され尽くされているであろうこの話題について雑に考えをまとめておきたい。とは言っても明確な答えがあるわけではないので意見がほしいというのが正直なところなので、もしフィードバックがあれば @konifarまで直接教えてもらえると嬉しい。 何を言いたいのかというと、『フォームに入力されていない or 入力された文字が異常である場合に送信ボタンを押せる状態にするか押せない状態にするか』という話だ。たとえば次のように氏名を両方入力しなければいけないケース。 初期状態の送信ボタンがdisabledで、入力に応じて状態が切り替わる。 本当に送信できる時だけ送信ボタンがenabledになるというのはわかりやすそうだが、問題もある。入力項目が多くなってきた時に、ユーザーがなぜ送信ボタンを押せないのかわからないかもしれない
GoodUX
Each week, we'll feature inspiring UX examples, proven frameworks, and hard-earned lessons from in-depth conversations with product, design, customer success, and marketing experts. The end goal is to help you build user onboarding and product experiences that turn more of your new users into lifelong customers.
サービスデザインで考慮しておきたいUXチェックシート35問 - DeNA Design
こんにちは。DeNAデザイン戦略部 デザイナーの宮本です。 今回はサービスデザインをする上で考慮しておくべきUXについて考えたいと思います。 「既存サービスのリプレイス」「新規サービスの立ち上げ」どちらにせよプロジェクト初期段階で考慮する点が重なっていることが多いのですが、毎回白紙の状態から進めてしまうと必ず考慮漏れが起きることから、これを予防するために実際の現場でのノウハウ（失敗）を元に問いかけ形式のチェックシートを作ったので公開したいと思います。 なお、今回のチェックシートはモバイル向けアプリの改修・立ち上げ時を想定した初・中級者向けで、あくまで個人的観点から重要だと思うところを中心に列挙しておりますので、参考程度に捉えていただけると幸いです🙇 戦略・施策設計においてはターゲットユーザーの鮮明化と、本当にそのサービスが使ってもらえるのか？を重点的に言語化できるようにしています。 また
大規模デザインシステムを作る：いかにしてアメリカ連邦政府のデザインシステムを作り上げたか - カタパルトスープレックス
原文："Building a large-scale design system: How we created a design system for the U.S. government" by Maya Benari, October 3, 2017 現在、ほぼ30,000の米国連邦政府のウェブサイトがありますが、それらウェブサイトの間に一貫性はほとんどありません。テクノロジーの分野で働く数十万人の政府機関の職員がいますが、彼らの携わるウェブサイトの構築や管理方法に共通点はありません。 その結果、政府はユーザーが十分に満足できないサービスに多くのリソースを費やしています。連邦政府のウェブサイトは行政が提供するサービスの正面玄関です。アメリカ政府と何らかの接触をはかるときユーザーが最初に出会う場所です。米連邦政府一般調達局のFederal Front Doorイニシアチブの調査からウ
ユーザーインターフェイスにおける明示的アクション／暗黙的アクションの違いと設計の考え方 – usagimaru – Medium
明示的アクション／暗黙的アクションについてずっと言語化できていなかったので、このたび記事にまとめてみました。馴染みのあるMac OSそしてiOSを例に、画面上のオブジェクトを操作するための二つのパラダイムについて説明します。 2005年頃の Apple Human Interface Guidelines (HIG) を開いてみると、そこには「Explicit and Implied Actions – 明示的および暗黙的アクション」と呼ばれるデザイン原則が示されています。Mac OSのユーザーインターフェイスでは、明示的アクションと暗黙的アクション、この二種類の操作体系が同時に提示され、ユーザーは好きな方法を選択することができるようになっています。 明示的アクション明示的アクションとは、すなわち画面上に明示された手段を選択してコマンドを実行するというものです。Macを例にすると、ユーザー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Visual Sitemaps | Crawl & Plan Website Architecture + Flows
VUI Design概要 - Speaker Deck