My take on form design when contracting with the US Navy was accepted by many (which means that they didn't come after me with torches and pitchforks...)
Up front, I analyzed enough to realize that a LOT of the forms were going to be used for various kinds of maintenance of data, though not everyone would do so. But multiple forms WERE going to be involved. Therefore, I came up with a design and implemented a form that became my "prototype" for everything.
All of the titles and logo images were in place. All of the crucial events had code in them for various purposes (mentioned later). The form had command buttons for common functions that would appear everywhere. The background was set up as a soft color that conformed to some Navy studies regarding color schemes. I had special common formatting routines for ALL controls that would set a control's foreground, background, and border according to various control states (and form states could enter into the equation). For instance, "normal" meant white background, black print, black border. "Dirty" meant a light pink background, dark red print, dark red border. But as a special touch, "normal+in focus" was different as was "dirty+in focus" - and that was true for other states.
The form's OnOpen code could test whether the user was properly registered according to a user role code. The command buttons were managed by a routine that made them visible/enabled or invisible/disabled and shuffled the visible buttons towards the right edge of the form. I.e. no gaps between two active buttons. The Form_BeforeUpdate would test whether the form was dirty AND whether the update was occurring because someone had used the SAVE button. If not, they would get a tweaky little message about saving before navigating or closing and the update wouldn't occur.
All of the buttons had event logging built in so I knew who had clicked a button when and on which table and which record the click occurred.
Once the template was ready, I built all of the other forms from the template, not from the raw form-builder. This meant one other thing: The look and feel of the set of forms was the same across the board. Maybe a bit boring, but once you figured out how to use the form for one of the operations, the other forms became almost "no-brainers." If you knew what the CREATE button did on the SERVER form, you knew the meaning and effects on that button on the SECURITY ACTION form. And the form knew, for every button, whether you were authorized to use that function and just wouldn't show you what you weren't supposed to use. It was a lot more extensive than that - but all of it was based on the idea of a template to preserve "common look and feel" for ALL forms.
That got kind of long-winded (no surprise, right?) but I think it is important to this topic. Designing a form doesn't occur in a vacuum. You are building an entire APP, not a form. Consider the forest as well as the trees.