Depending on if a user can go a to a previous step, having a "BACK" and "GO" button to navigate through each view doesn't give much insight, but it would be helpful to describe each "view" with a specific name. That way, you could name each "BACK" button the previous view, and each "GO" to the next view. If you give each view a name and display what category they are currently viewing, users will always know where they were previously, where they are currently, and what the next step will be. Then after they are all done, make the button describe what they will see when they submitted. (i.e. "VIEW REPORT", "SEND DATA") (Also, progress bars are extremely helpful to users to know how far they are along the sequence.)

Five participants can uncover usability issues, but you can't report confidently with a sample size that small, so stay away from quantifying it. You can give the development team your suggestions for improvement (no need for 30 people to discover that the same button is broken), but if you'll be measuring improvement on the same feature at a later date, you really need a statistically significant sample for that (30 at the very least, 40 is better). A participant pool size of 5-12 is good for qualitative feedback. You might use 5 participants to find out why your analytics data are reporting that something is off, and provide verbatims from the users that support what you discover.

The problem that GitHub has here is ambiguity. Fork is a verb and a noun. The button shows the number of forks so one could argue that the button shows forks. But it's a button, not a link so it suggests that it performs an action and the label "Fork" suggests that it will fork the repository. A way Gitlab solves this is by splitting the button into two buttons: By following gestalt principles by connecting those buttons, the first with the label "Fork" gives meaning to the number on the second button, but only for those who have at least a little prior knowledge and are able to know or guess this. But just like Gitlab, most users of GitHub have a technical background so that's not a problem I think.

Multiple CTAs is not good design The idea of a prominent CTA button is that the user knows exactly what to do next. If you provide multiple CTAs with the same prominence/weight, you offload it to the user which action is the most preferable. Ask yourself, what would 80% of your users like to do on this screen? Then style that button as the primary CTA and the rest as secondary. Alternatively, if there is no clear preference, you can also style your payment options as a selection (radiobuttons) with a call to action (Pay).

In the question, you mention three different libraries when there are actually two: General assets library (free or paid) Personal assets library If a user has uploaded material to the site, it's logical they have a user created. Once inside the site, they can access their personal profile to view their own library or content. With this, one of the problems is solved since it's not necessary to mix private content with the general one. Regarding free and paid content, most resource sites solve this with a paid section with horizontal scrolling or a View More button, usually at the top, and the rest of the content occupying the entire page with vertical scrolling. Did you have a look at https://unsplash.com/ or https://pixabay.com/ ? All the problems you raise in your question are solved and in a good way.

I am in this situation when I initially started my career as a UX researcher when the turn around time was 1-2 weeks. The best way to start will be do a secondary research and obtain as much insights as you can about the existing product. Request the client to provide with you their customers/ suppliers profile and ask them about the pain points and frustration depending on the service and product. You can develop a persona based on these insights although it might not be accurate to a future user. This is how I started and it did yield some results.

Usability testing where you test out with users from both areas to have them access the two functionalities

Why Don't We Show the Price? Retailers like Amazon have the legal right to set their own prices independently, but some manufacturers place restrictions on how those prices may be communicated. Because our price on this item is lower than the manufacturer's "minimum advertised price," the manufacturer does not allow us to show you our price until you take further action, such as placing the item in your shopping cart, or in some cases, proceeding to the final checkout stage. The steps required depend on the details of the manufacturer's minimum advertised price policy. Taking these steps allows Amazon to show you our price consistent with our goal of always offering you the lowest possible prices on the widest selection of products.This won't require you to purchase the product. You can easily remove it from your cart if you decide not to buy it.We realize that this is an inconvenience and are regularly working to educate manufacturers on how their policies impact our customers. We welcome your comments and suggestions in our forum on this topic. Via https://www.amazon.com/gp/feature.html?ie=UTF8&docId=174014

Common practice is to have 2 permission types: View Edit - includes "Add", "update", and "delete" Is that something you can do or a user can have a single permission only? Here are two solutions to think about:

Don't make this is overly complicated for the user. A checkbox defines a state not an action and it is guess work for the user what will happen when it is checked or unchecked. So this should be an action that changes the state of all choices to default and has a clear label. Use a button instead: Since this is a reset button that undoes all the hard work a user has done, it should not be part of the flow of the form. For that reason I placed it on the right in the example. If you see that users like to experiment with the values and want to offer a switch between the default and a custom setup, you can use a radio or likewise control: In the example the dropdown's for the custom setup are disabled so it is clear that it has no effect changing them since the default option is selected.

There should be an organizer, who will invite the people they wants. To make it easier to send multiple invitations at once you can introduce groups. So then organizer can send an invitation to the whole group, let's say "Elm Street neighbours" or "My closest friends". There can any amount of groups, and everyone can be in any number of different groups. Anyone can see only matches either open-to-everyone or to which they has an invitation. Neither password nor link is needed. And then you can introduce other features, like "can other group members invite new participants" and so on.

In this autopay scenario, the ideal behaviour would be to show the form with the current populated fields based on what the user had set previously. This way the user can just make changes to the fields that they would like to change, instead of filling in all the details again. Here are some additional references that might be helpful: https://mikeknoop.com/ux-analysis-credit-card-form-ui-ideas/

There are several possibilities. I would try making a separated working zone at the same screen. Horizontal split-screen to get a working area in the lower half Color difference between the image of the working area and the real one A button to move the partition boundary vertically A button with the option to see a working grid in both partitions Possibility of zooming in the work area, with or without repercussion on the real image. For example: Zoom in both with the usual two-finger gesture Zoom in on just one image with three fingers (or vice-versa) The user paints in the work area, the lower part, and visualizes the result in the real image, the upper part.

Your description seems to contradict itself. If 5 is the "ideal" score, then a higher score can't be "even better".. If the middle is indeed the optimal point and the extremes are to be avoided, you can use a chart that has the optimum in the middle, e.g. like this gauge: If one of the extremes is indeed "even better" and 5 is actually just "good enough", then @Danielillo's suggestions above works. If this is a situation like a school test, where an "A" grade is the highest score achievable by "conditional means", but there might be extra points (an "A+" grade) for outstanding performance, I would stop the chart at the highest "conventional" score, and provide additional means of encouragement that's outside the chart, like a badge or trophy or some "bonus points", but I would not make it part of the same scale.

The primary goal is to have them repurchase. Can you drop the other asks of them? Don't distract them from the purchase process. So you have 2 things you're asking of the customer here, all while you're getting them to do the main thing: hit that BUY AGAIN button. The first (thumbs up, thumbs down) seems unnecessary because if they like the wine, they'd just buy it again. The second (tasting notes) is really for your company to sell more wine by building up some kind of (recommendation engine?). Could you do that after the purchase in some way? The main thing is to separate the purchase process from the review process. Even from just a graphic design perspective, the Tasting Notes bar is bigger than the BUY AGAIN button. They don't need to live together. If you must have them together, try putting the review subordinate to any purchase call-to-action, or near the purchase history. They can follow the link to leave a review. You might also try to deemphasize the 'Complete' green. Since the purchase was completed, do you need to have this here? At the very least you can lessen the emphasis Try making the CTA button more noticeable. I know it's the brand color, but perhaps it can stand out more. Right now the 50% off and the Complete lozenge are more colorful.

Without knowing more about your specific application and its users it is difficult to offer specific suggestions. Also curious about your concerns around upgrading functionality. What do you fear will happen if you don't warn users in advance? In more general terms there are a few ways of approaching the introduction of new functionality or changes. In no particular order: When the change is ready - deploy it in parallel and encourage users to swap to the new version (Atlassian and Microsoft Office do this for example) before eventually switching over when analytics show a certain percentage of users have switched. The downside of this is that it requires you to serve and maintain multiple versions of your application. Create a newsletter (old school?) or twitter or Youtube or something and introduce users to upcoming changes that way before release. Could add a link to the article or video on the current site. When you do the release - include a wizard that highlights the change(s) on the interface as soon as the page is loaded. I've seen this sort of thing on currency exchanges before, for example. Test the new functionality (either functional or non-functional) with a group of users and see how they respond to the change. Does it confuse them? does it result in unexpected behaviours? Or do they get it straight away. This could then inform any subsequent rollout.

I think it is important to understand the factors that relate to user engagement, which are generally centred around the content contained within the website or app that they consume, rather than the aesthetics of the website. This because while the aesthetics (i.e. styling and visual cues or embellishments) can attract the user's attention, it is not what will make the user continue to be engaged with the content (think click baits). So even though there are A/B tests to show how a difference in the visual design and layout might attract more views or clicks, there are not as many studies on engagement because it is really based on how well the content suits the user's needs and whether it is easy enough to navigate or access for them (but this is not related to their engagement of the content).

I personally see idea A much more complete, with some adjustments. – should the query be cleared as soon as they make a selection? – The problem I see in this design is that the query and the chips share the same field and the result is very confusing for the user. The logic would be a text editing field and the chip's area. The text inside a chip is not editable, while the query is. There is a possibility that the user wants to add one more character to those already written, I would keep the query but in a separate field and the chips in a clearly non-editable area. – Once the user selects a category, since they must only select one, should other Categories not be shown anymore – Pretty much EVERY TIME I have to select a checkbox, I always select the wrong one the first time. The only way to not start the search process over again in the event of an error is to keep all possibilities clearly visible. Ultimately, it would be useful to continue showing all possible categories and hide the subcategories of the unselected ones. – Once the user selects a category, should the rest of its child Subcategories appear automatically – I would let the user decide if he/she wants to see all the subcategories with a View all option. At this point, I think the most important action is the immediate search with the typed characters than displaying all the subcategories of an item. If there are three subcategories, it would not be a problem, but if there are more than ten, I would let the user choose if they want to momentarily abandon the search and use vertical scrolling to see all the content of the results field.

How do you make sure that your code is working at all? Usually, that's done with automated tests, and the UI is no different in this regard. Tests like these can even be written before your feature is finished (as https://en.wikipedia.org/wiki/Test-driven_development requires). Having tests also means you'll know if it breaks later down the line. In my stack, this is done with https://laravel.com/docs/8.x/testing and https://laravel.com/docs/8.x/dusk . The latter uses a browser like a real user, so interactions that rely on Javascript can be tested.

I have seen the approach of first masking the image and then clicking on an image makes it available, or click shows a warning where you have to click on Yes to see the picture (explaining that there is sensitive content). I think Facebook uses this approach.