I can see different approaches but all have something in common: the 3 inputs are received as a group. Align the main label with detail labels and do not repeat the detail labels (looks like a table with labeled collumns) you could use something like cards (depending on the design of the rest of the form but a card would group the inputs to a unit. or depending on the length of the inputs you could use the same but stacked vertically instead of horizontally. this way you do not brake the rule to place the labe on the left of the input.

What you are trying to do is a kind of accordion form, similar to https://wrabit.github.io/accordion-form/ . I think you're too immersed in the form rather than the action. I would try to adjust the global layout to make the action clearer. Some tips: What the user is adding is a new Extra Data, so I would put the add + button associated with the general form title. Put a name or title to each section. I would differentiate between a fixed title of the section and the editable name. A title always helps to clarify the difference between one element and another. When the user deletes it, it's clear that they're deleting the entire section, not just the edited text. Visibly differentiates the title area either by typographical change, background, ... This helps to hierarchize, differentiating the element from its editable area and to create the partition between each of the new Extra Data added. In the image of the question, the centered line is confusing by not defining a total division of each piece, it seems the second field is part of the first. The x is closely related to closing the window, I would not hesitate to put a trash can in the title area of each section to remove it permanently. A basic draft: Try not to make the user dizzy with trips from one place to another. A form implies the complication of "forcing" the user to insert data. Defining editing zones and action zones help to the clarity and understanding of the whole element.

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.

Progressive disclosure is meant to divide the UI into manageable chunks so as not to overwhelm the user with too many options and choices all at once. It's not meant to isolate each decision into a step of its own (that would be a wizard, and quite a tedious one). There's nothing wrong with dynamically changing the UI within the same screen based on the user's decisions, and it even has the upside of better reflecting to the user the meaning of the different choices they make. This enhances the feeling of control and helps them learn the system. A good example would this dialog from MS Outlook, where changing the recurrence from Weekly to Monthly immediately changes the fields affected by that change: Under the "extreme progressive disclosure" approach, this would entail navigating to a different screen and then back again in case you wanted to change your decision. I think it's easy to see that this is the friendlier option.

Here is a related answer on UX.SE: https://ux.stackexchange.com/questions/45001/is-showing-a-loader-inside-a-button-on-mobile-a-good-practice This is what I think: I agree with keeping the text in the button so that the user knows which action is being acted upon while also disabling the button so the user does not click on it. Another approach that could work: A progress loader come up on the screen when an action is triggered through the button - and the button itself goes into the active-disabled state or is replaced by a stop action - this could be useful in situations when the action takes a while. For e.g. Img src: https://material.io/archive/guidelines/components/progress-activity.html#

I see a bit of chaos in the image design. What's the difference between the x and the trash can If only three numbers can be added, I see the clarification as unnecessary, a space for three numbers will be enough Window save/cancel buttons are in the opposite corners Putting a bit of order in all the functions: Add the phone number Edit the phone number Delete the phone number Choose to receive SMS/Text If yes → Select phone number to receive SMS/Text Decline to receive SMS/Text The window content: Title + action description (Numbered) Fields to put up to three numbers Check to get SMS Edit icon Delet icon Phone number field Explanation text of the SMS/text Cancel/Save buttons From an organization scheme similar to the following, a good design can be created.

Hmm, that is the tricky case, let me offer what I think: First of all, it's good to let people know about what documents are needed upfront, possibly at the form instructions - when they fill the form they don't want to start running around I would advocate for adding docs on the page they are related to. At the time they reach the end you can expect a user to have form-fatigue At the form review page I would add the opportunity to add missed docs once again. It's a nice moment the main job is already done but there is a moment to pause and think. It seems to be a good place to give extra chance Good Luck!

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.

If there are useful defaults to have in both lists, go for that option. Useful meaning that you have reason to believe that in at least 70% of cases these will be the options selected by the user. Alternatively - if that's the option that promotes your business goals the most, AND you're fine with preselecting it for the user (i.e. the cost of error is minimal and there are no ethical problems with that). If not, disable the second list until the first one is selected and keep it in a "Please select..." state. Don't hide it because it might make the user wonder where that data is selected and might send them looking for it in other parts of the UI. You want your interface to be predictable. If the user changes the category in the first dropdown, reset the second one to "Please select...".

If these three screens almost do the same and have very similar content I would argue that they need to be united into a single screen with a control that highlights the difference and forces the user to make an explicit decision, like a button or an accordion or even a set of tabs (although that's probably the least favorable option because one of the tabs is selected by default).

I think you need to introduce a default value or recently used value already filled in the new form or some kind of checkbox for new form to auto populate the values from previous entry (mark it checked by default) This might speed up the adding entry process. Also, you can always have "Save and Add New" button to skip going to list view and adding the items quickly. Hope this helps.

Above the sticky bar (I assume you mean z-axis). Otherwise the sticky bar covers the dropdown, making handling difficult. Whenever the user opens a dropdown their focus is on it, not on the page as a whole.

I would use the dashboard page for simple navigation first, with three cards side by side. Every card with an icon on top, Small Title beneath it, and a small description underneath the title if necessary. Have a button at the bottom of each card to take the user to the respective form/page. Make sure to keep the form simple with help-blocks beneath the ones that need some explanation. Also, keep the form nice and centered, with at least 20% padding on the right and left, because you don't want full widths forms. Another idea is to show the form page in two columns. The actual form is in the left column, with a detailed explanation of the form in the right column. Do not try to juggle three different kinds of elements on one page, side by side horizontally or vertically. It might be a clever solution on your part but might end up very difficult for the user to understand and use. * I have attached the navigation page example I explained above earlier. Hope this helps. Imran

Add some progressive disclosure to the design: Turn the order around and let users choose first if they want to pay in terms or not. Make the possible pre-paid options appear that matter for their choice. Or make it a two-step form if you will but always allow to navigate back and change previous choices. If you like to play open cards and show all possible options at once, this indeed will add some cognitive load but also has its purpose: Users can decide if they want to pay in terms based on the pre-paid options at hand. Your 3rd example with the options disabled and the explanation seems ok, but you can also integrate all options in the same list:

Some general guidelines and questions that will impact what the best solution will be: Are all the inputs relevant for all the users? If no then try to only show the ones that specific users needs to see. If yes try not to hide any important fields. Hiding functionality is rarely a good idea, both from an accessibility point of view and it can also introduce stuff from a validation point of view. Are the inputs related to each other? Then one solution could be to split them into steps. But then they need to be ordered in a logical order. If it comes down to one of the aims of form is completion, having multiple steps can create a feeling of wanting to complete the form if started.

Leverage common patterns whenever possible; users come to your application with lots of shared patterns from other sources. The form above (current) approach: Is there a specific reason to use a vertical pattern? Going from detail to list vertically tends to confuse which elements are grouped together. We often approach a list first for what's already present, then make decisions as to Add a new item to the collection, or edit / delete what's there already. Since most desktop viewports are wider than tall, making a vertical add pattern tends to be confusing for several reasons: The value of the list is to show all elements already created, and to quickly search for a particular item or value. Putting the list below the list will push down some of the elements. The action buttons such a Take It and Clear Fields look like they belong to the table (which is a common pattern) There's also not an obvious way to abandon an edit. 'Clear fields' is different than Cancel. There needs to be an exit that reverts any edits to the pre-edit state. 'Cancel' is a common label for this. A list detail pattern on desktop using a panel Try honoring the list and provide a quick way to edit in place by using either a dialog or sliding panel. It's a common way to add or edit items in a collection. The panel comes in from the side when editing or adding a new item: Now if there's a sub object (the conditions), focus their attention by drilling into a condition detail:

If the manager made the decision, there is little you can do. Although according to the image there are things that could be improved: When designing use layout guides. Unify measures: Unify sizes in buttons with similar content. The buttons in the image have up to six different sizes and can be reduced to just 2. Unify the distance between buttons. The image has three different distances and should be always the same. Nor do I think it's so necessary to follow the typical table scheme with its title and cell with content. Knowing they are items to be selected under the same concept, everything can be in the same line:

It depends on what will likely happen next. If the user will want to keep working on the newly added item (let's say they're writing an article, and want to keep editing a draft), they'll stay on the Newly Added Item page. If they're more likely to want to add more new items, they should be taken back to the All Items page so they can click the Create New button again. Either way, they'll need a little confirmation message telling them that their newest item has been created.

You might consider a pattern that communicates the status of the form to the user without inferring anything about the content of the form. (An asterisk is often used to indicate that something has changed, but in the specific context of a form, it could infer that it's required.) Status chips near the title can tell the user that something is in progress without inferring anything about the input itself.

There isn't a real limit on the number of inputs for a modal window form, but there are other considerations: Should the user be prevented from working on any other tasks? If so, that's a modal. Does the user need to reference anything else on the page while working on the form? If so, you might consider a sheet. If the user accidentally closes the modal by clicking outside of the window, will they lose a lot of work? If so, consider a sheet or a page. Does your form combine a lot of different tasks, rather than providing one thing for the user to do? If so, consider making that a page.