You already answered your own question. Keyboard/screen-reader users will need to step out of the search field when it was focused automatically to make use of other ways to navigate. Also on mobile, Google doesn't auto focus on the input field. The reason is simply to not directly popup a keyboard since that would be annoying.
If you want to make your main ...
This icon seems to have different meaning in different systems:
it's called "caret sort" or "chevron sort" in Carbon Design System;
it's called "unfold more" in Material Design, while for sorting they use different icons;
it's called "sort" in Font Awesome;
Fluent Design System uses different kind of arrows for ...
Autofocus is a tool that is wildly helpful if done correctly and it is appropriate to the situation, but there are many, many things that can go wrong. If your implementation doesn't avoid all of these pitfalls then you will cause great annoyance to some (or maybe all) of your users:
If the autofocus happens only when the page has finished loading, then ...
Show one task at a time, using progressive disclosure
On your first screen, you can provide a simple checkbox questionnaire where the user can identify any health issues that they may have.
When the user clicks Continue, you'll ask for more information on each identified condition. Use a different screen for each condition, and only show screens if the user ...
Here is an example of where auto focusing the search field is extremely annoying, unwanted behaviour:
Go to Openclipart and search for something, say linux.
Scroll down to the bottom and click the next page button.
Now on the second page result you want to scroll down the page by pressing the spacebar.
Except you can't because the stupid search box has ...
I think those questions are significantly important for the user's health, and you shouldn't minimize and/or designing it more compact. Because the wrongly made decision or wrongly understood question can highly affect the user's treatment plan.
You can still improve it by adding a header. I would recommend 1 of 2 options:
Questions with the nested ...
Adding to Izquierdo, I would also say
Shorten disease names (e.g. Major depression or other mental disorder)
Deemphasize secondary information (e.g. excluding anxiety and stress)
Format the follow-up questions more readable
It would also be helpful if the diseases were ordered a bit better and segmented into sections (but I could not think of anything good ...
Conventionally, like in newspaper column layouts, it's top to bottom, then left to right as your colleague suggests.
For your dataset, a list of countries with just 3 columns, there's going to be a lot more different eye movements needed from your user if you organise them left to right first - looking across 3 items, then back to the start of the row ...
When I need to have actions in a browse list, which is often, I have the primary action as a stand-alone button and other actions in a drop-down menu for quick access. This maximises space for information in the row and (imho) keeps it all nice and tidy.
Rather than having an icon, a label ACTIVE INACTIVE would be much more understandable
If for some reason you have to use an icon, I would recommend a colored dot for active/inactive 🟢🔴
Due to our user feedback, we realized they did not use the Last transmission, and we are looking to communicate if the device is alive or not.
Did you find ...
A visually hidden label is generally only used to benefit screen readers where there is something visual on the page that isn't conveyed. That is, if the design of the page implies a label is associated with an element through some visual connection but there isn't really a "programmatic" connection between the two elements, then adding a hidden ...
It depends on the company's budget, openness to change, the worth of the effort, current state of the app.
You could be better off with a review of the design system and the app itself. Identify all the building blocks in the app, categorize and group them, refine and make sure they are consistent throughout the app and improving them. This would result in ...
It’s going to depend on how large your recruiting budget, potential participant pool, and incentives are. You can use tools like respondent.io to screen millions of people extremely quickly, but there will be a cost.
I’d suggest creating a screener survey that buries the target site in a list of other sites. Example:
Which sites have you visited in the last ...
I think the easiest and most plain answer is:
If your website is all about searching (like google), you should autofocus the search field.
If you website is not mainly about searching, you shouldn't autofocus the search field.
The main goal of a design is, to provide information as clear and easy as possible to the users. You do not want your ...
Tl,dr; some reasons not to give the search field autofocus when entering a site are:
Searching is not the main function of your site, just an optional tool you offer to your users
Searching is the main function of your site, but it requires more than 1 field/parameter to work
Google does this not because 99.9% of its users will search; it does it because ...
Agree with Michael Lai.
As you move closer to release your mockups will need to match the actual product, but only to iron out fine details, such as components animation timing, colors versions..
If you are still gaging a specific user journey, say the the efficacy of one idea, I wouldn't mind too much on updating minor UI details.
That said, yes I would ...