There are two ways to work on https://www.nngroup.com/articles/journey-mapping-approaches/ : assumptive, and research-based. In an assumptive journey map, you are working with a group of internal stakeholders and building the map based on all of the assumptions that they make about the persona on his or her journey. These assumptions can (and probably should) be validated with user research later. After you create the journey map as a group, you can use dot voting to identify pain points. The phase or action that receives the most votes would be your "lowest point" in the journey. In a research-based journey map, you would interview several users who represent your target persona, and ask them specific questions about each action and point in the process. At the end of learning about their process, you'd ask them to tell you which part of it needed the most improvement. You might receive a lot of different answers, so if you have a lot of "low points" without any really standing out, you might still want your stakeholders to come back and add additional votes to help make a decision.

Generally speaking there are a bunch of UX principles and best practices advocating for a minimalistic UI. This makes sense in terms of https://uxplanet.org/cognitive-psychology-in-ux-cd7afed87886 (viewing Attention as a finite resource), perception and memory, https://www.interaction-design.org/literature/topics/fitts-law#:%7E:text=Fitts%27%20law%20states%20that%20the,size%2C%20the%20longer%20it%20takes. (advocating for larger target areas, hence less items in a fixed real estate), https://www.interaction-design.org/literature/article/hick-s-law-making-the-choice-easier-for-users#:%7E:text=Hick%27s%20Law%20(or%20the%20Hick%2DHyman%20Law)%20states%20that,can%20be%20vital%20for%20safety. (less choice leads to quicker decisions), a UX technique called https://www.interaction-design.org/literature/topics/progressive-disclosure , which means that large amounts of information should be split into several steps, https://uxdesign.cc/jakob-nielsens-eighth-usability-heuristic-for-user-interface-design-62fbbe7aa734?gi=36bec78df153 , and many other guidelines. Taken together, these principles mean that we often aim to reduce the number of items on display for our main personas (target user audiences), deferring more advanced options to more remote locations. https://www.nngroup.com/articles/flexibility-efficiency-heuristic/ promotes the use of hidden shortcuts and other "power features" for more advanced users, without using up the real estate seen by all users. All of these decisions require a fine balance which is ultimately at the discretion of the designer - because displaying all of these actions for you also means providing a more cluttered and difficult interface for all users, including yourself whenever you don't need these options (which is probably 99% of the time). Ideally the exact point of equilibrium will be based on user research, but even then it won't fit all of the users all of the time. Specifically Apple is sometimes https://www.quora.com/With-Apple-being-so-rudely-paternalistic-against-its-customers-and-treating-them-like-little-children-why-are-adult-people-still-buying-their-products , and only supporting the lowest common denominator, or what they view as the main use case, making it difficult to do anything they treat as a non-standard way of doing things (AKA " http://edition.cnn.com/2010/TECH/mobile/06/25/iphone.problems.response/index.html#:%7E:text=You%27re%20holding%20it%20wrong.,e%2Dmails%20from%20customers%20himself. "). Microsoft typically adopts a "wider" approach, supporting more use-cases with more ease, at the price of making the main ones less well-tailored to the persona, because that's the tradeoff you get between a generic and a bespoke UX. I don't work at Apple, but I believe this is why they hide things in menus :). *EDIT As some commentators have pointed out, one of the most important UX principles is https://uxplanet.org/difference-between-findability-discoverability-in-less-than-2-minutes-baabfd06d988 , meaning that options need to be discoverable directly via the UI without involving additional means. In your case this principle is sacrificed in favor of others - here it is at odds with the Minimalism idea, because it requires more use of real estate. This is not uncommon, as many UX principles can contradict each other, and the gist of the whole domain is to manage these tradeoffs according to the relevant goals. Since we aren't aware of the business goals behind this decision I personally don't think we can state that this is necessarily "bad UX", and as others have also pointed out, some of Apple's business principles are to discourage the use of other vendors' devices with its OS - so this decision may have been made to serve that purpose.

The borders around buttons and call-to-actions provide a much clearer representation of the physical contact/touch point for the user, although generally the user interfaces on mobile is laid out in a much tighter space so it may not matter as much as when you are designer on a desktop for click interactions. The combobox is a term used for specific types of dropdown input control that can be combined with other features, such as a search or multiple selection rather than just a simple dropdown list from which you can select one item only. However, depending on the operating system or design framework you use it also might mean different things. I think you can keep the function of the dropdowns (or combobox) similar to the app you are trying to mimic, but in terms of the style you should probably consider whether you are also trying to mimic the app or doing something different, in which case the border around the controls might not suit your particular purpose.

I find it is useful to imagine what the options would be if they were numbers instead of words. Let's say your question is: "On a scale of 1-5, how likely are you to buy this product again?" Now, you would never even think to question which order to use. The answer would always be start with "1" on the left, and "5" on the right (assuming a left-to-right language). So the trick is, don't let "words" convince your that it should be any different. If I change the question: "How likely are you to buy this product again?" Imagine them as numbers. It would seem fairly obvious that "very low" should equal 1, and "very high" should equal 5. And there you have your answer. In addition, as a rule of thumb: if you can't see an obvious reason to chose one order over the other, then there is a good chance that the order doesn't matter anyway.

I think your basic idea is fine, I'd make these changes: More specific tag group labels like "Using these subjects", "Using these activities", "With these goals", etc. Make the screen narrower. The tag input fields might possibly be half their size. Maybe you could add a little more padding and white space around certain elements to see if that makes it breathe a bit more. The example looks good but to avoid "cards on cards" you could remove the elevation and just keep it as a flat box. If you want users to see more examples, perhaps it could act like a carousel and the user could click through examples using forward and backward buttons.

I think it's more of an aesthetic or fashion decision than something inherently functional. Anyway, here's an argument. Most of the components in an interface are framed within an orthogonal grid, such as the example in the question. In fact, the screen itself responds to Cartesian axes, we have not yet reached the oval or formally fluid screen. This image shows a basic layout grid with its respective items where both elements are clearly perceived: This type of layout not only emphasizes the structure but interferes with a clear perception by adding a third element: the gutter. The grid alone, while simple, is perceptually too complex: Sometimes the designer prefers to avoid the clear preponderance of the base grid or eliminate these gutters from the root to simulate a less structured, more natural design or simply give more relevance to the items. The extreme would be the item with a fully rounded frame or circle: By eliminating the edges of the shapes, the optical center becomes more visually relevant, each item is placed at the intersection of the axes of the structure lines (a). The gutter gets totally diluted. Perceptually it's much simpler: The orthogonal shapes with rounded corners try to weaken the marked Cartesian axis of the base structure. But, while the gutter is still clearly perceptible, the rigidity of the union between the curve and the side generates a new element: https://en.wikipedia.org/wiki/Grid_illusion . Smooth corners are an optical arrangement to simplify visual perception, trying to avoid the mismatches described without dispensing with the use of orthogonal shapes, replaced by circled squares: https://en.wikipedia.org/wiki/Squircle .

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.

I would take this tried and true solution from Outlook as a starting point, and tweak it to my needs. Alternatively, the one from Google Calendar is also a good option, although I think it's not as robust and clear as the Outlook one.

While I think this question is very open-ended, the best advice I can provide is to design an interface that avoids blue light. This can be achieved in two ways: Creating a dark-themed interface Using warmer colors in the interface This means avoiding large areas of the interface with white, or near-white color palettes. Using a dark theme will allow for higher contrast, without higher eye fatigue. If your situation does not allow for a dark theme, my second bullet point about warmer colors can be an alternative. Here are some medical articles that might interest you on the subject: https://www.health.harvard.edu/staying-healthy/blue-light-has-a-dark-side https://www.uclahealth.org/eye/computer-related-eye-fatigue

Here some examples: Icons https://www.mediamarkt.de/ Color https://www.levi.com/GB/en_GB/ Typographic style https://www.adidas.co.uk/ Relevant info https://stackoverflow.com/questions Product Logo https://hebo.com/gb/ Mascot https://www.seek.com.au/ Figure/ground https://www.publitas.com/ Tagline https://www.esky.co.uk/

I've always been amazed by search bars with built-in filters, like the Discord search bar. By default, the search bar will help you search for specific words in all messages, but with the built-in filter options you can search for words or all messages (if left empty) from specific members, in specific channels, with specific criteria. In this case, in the example below, from a specific user, in the channel "Tips-and-tricks, and only those messages that contain an image. In your case, you would probably want to search for [assigned:no], and or even [assignee:], etc.

A gradient is a double-edged sword and not that hard to control. The formula is simple: YES when the gradient contributes to the final result of the product NOT when it's a gimmick The second case not only adds nothing to the design, it makes it worse. The captures seem to be of applications of habitual use and quite profuse in graphic elements. I would try a maximum cleaning at the UI level. Any background, gradient, pattern, or color, is visual noise unless it's something very subtle. Even pure white can be a perceptual drawback. Part of the application components are color-coded so that the user identifies them more easily. Any surrounding color is perceptually influencing this end in a negative way. In the bottom image it's clearly visible: the fifth and seventh objects, light green and gray, are better perceived on a white background than on the green gradient. The best thing is to avoid any colored background, especially if these backgrounds change from one application to another. See http://www.e-cartouche.ch/content_reg/cartouche/ui_access/en/html/Layout_learningObject2.html . Superimposing shapes to a gradient gives depth, but it depends on the case, not the desired one. A shape with a color similar to one of the gradient components will be interpreted as semi-transparent. If it's necessary to obtain this effect it's welcome, otherwise it is unnecessary noise. If multiple repeating color shapes are placed along the color change of a gradient, they will appear different in color. See http://www.e-cartouche.ch/content_reg/cartouche/ui_access/en/html/Layout_learningObject2.html . Conclusion: I would avoid the gradient background. But on the other hand I would try to let the user know at all times in which application is in a clearer way. As the interfaces are now, the change is too subtle. If the idea is that the colors are as subtle as possible, look for an element that helps an effective identification. A color code is always useful as long as it's easily and immediately interpreted.

One of the essential characteristics for an element to be interpreted as a CTA is isolation. The more isolated an icon is in a graphical environment, the greater the possibility the user will click on it. In the example image, those that are defined as non-clickable objects in the description are exactly the ones that have the best chance of being interpreted as such: R and ⇆. Answer to this question (if an element is not intended to be interpreted as actionable): avoid isolating non-clickable elements. If this is not possible, disguise this isolation as much as possible, for example by integrating the icons into the text or the graphic part of the table.

I often see a checkbox next to the input field which enables regex. All the text in the input field will then be interpreted as a regular expression. The problem I see with your approach is that it would not really be discoverable that you can use regex by prefixing your input with "re". Also, what would happen if you would want to split a word which contains "re" in the middle? That would make things messy.

Row expanders are useful if the user needs to compare expanded information among two or more rows. They can become unwieldy when the expansion section becomes large and complex. If you're only showing location and status, though, you can use the horizontal space to preserve vertical space. Cards could work. An alternative is offering the information in a modal panel such as a side sheet. The user can only engage with location/status information for one item at a time. The user would enter the modal and can then view, edit, and delete each location/status pair.

Whats in the data table? phrase, sentences, loading bars, integers, user defined names, etc.? Each of those require a different amount of minimal space to discern. I'm assuming it's names or phrases. If this is the case, then the column width should not collapse further than the width of the column header, or even the expected string length. In most cases, you will come across data in a table that requires disclosure, like a long name or a description. In this situation it's more important to design around how the user can read the full value if the string when the data is truncated (EG: tool-tips).

If the app uses keyboard, I'd consider a text field (a single line text editing element) where user can type using natural language. The field should only allow to type the predefined strings such as This week, Last month, Last quarter, Today, Yesterday, Since Tuesday, etc. and date ranges such as December - May (for the most recent December to May range), 2015-2020, 12/22/1990-May/5/2000, etc. The user would need to press as few buttons and type as few characters as possible: Automatic capitalization. E.g. upon typing l (for Last), the system should automatically correct it to L. The characters that lead to unsupported formats should be prohibited/ignored. That is if user presses the a button after entering Dec, the button press must be ignored as the only possible option is December. The hints on what's possible to type next are also very helpful. Upon typing j, the system should offer June and July. Support natural language features such as references to holidays. Example: Since Labor Day. Examples 1) The letter z will likely never appear in the supported formatted string and as such should be completely ignored. Starting the string should be possible with digit or one of the few letters such as t (for This, Today, Tomorrow, Tuesday, etc.). If user has already entered y, the system will only allow for e as a next character because y presumably means only Yesterday. 2) If user starts with typing l, then only possible option (I can currently think of) is Last. 3) The system should also offer hints on what's possible to type next and allow to select options with vertical arrows and completing the currently entered term with Enter button. 4) If user has typed j, the options offered should be June and July with June being the default (first in the list) option. If user hits Enter, then June is selected. If user types u and l next, the system should offer July as only valid option. 5) If user types a, this could mean April, August, and After (e.g. After Labor Day). Other thoughts For clarity, along with the user input, the system should display the actual interpreted date range. For example, if today is December 1, 2021 and user types Since last Friday, the interpreted date range should be Friday 11/26/2021 - Wednesday 12/1/2021. The preferred date format should ideally match user's native one. If the app can support voice input, I'd recommend using it as well for the similar input style. Though correcting such input would require another algorithm. At least, allow user to speak meaningless words such as from, and, etc. Example: the user may say something like from last quarter and until yesterday. Here, from, and, and until are useless (meaningless) words. To support as many natural language constructions as possible you may want to first spend some time on collecting and organizing them. And then maybe creating sort of parser off the set of formal declarations. There are some libraries that already support this kind of input. Though they may not support all variants you may need. Example: https://github.com/argenos/nldates-obsidian .

I think an obvious one that's missing would be another common accessibility theme but for colour blindness. Another one that I know about is a theme that makes it easier to read in high intensity light (e.g. outdoors in the sun) for readability. Actually, with the new https://material.io/blog/material-theme-builder for dynamic colours, there should be more flexibility and response to different contexts.

I think the main reason is to leave free space to work with the application. An extreme example is https://discord.com/ . On the home screen, the lower left position for the avatar looks like a random decision: But when starting to work on the application, the position of the avatar, an element that is not used as often except to define basic work preferences, makes more sense, since it leaves room for all the other working components more complex and frequently used: Perceptually the isolated user avatar in the lower left corner allows it to be viewed easily for access if necessary. In applications with screen changes, each menu component, tools, panels, etc., tend to vary in position according to the number of items, as happens in discord. The lower left location can be set as a fixed position. If I had to highlight main reasons: Clear differentiation between work area and personal area Fixed position Isolation Ease and immediacy access

I can think of two approaches you might try: 1. Use a Filter. Show all of the options that the business can do, and then let the user filter by brand. Hide the unavailable options rather than showing disabled - a disabled state implies that the user or system can do something that might enable them somehow, and this isn't the case. 2. Use Progressive Disclosure. Before showing any options, have the user select their brand first, then show the list. The better option is going to depend on why the user is on your page. Are they trying to book an appointment and just need to complete that one task (this sounds like the case)? Progressive Disclosure will help them stay focused. Are they generally looking at what your company does in order to decide whether you're a reliable business for many future needs? It might be better to start with the big list and let the user engage filters several times.