Feature Exposure vs. UI bloating

When developing my web applications, I usually tend to have an icon/button per feature/function and place it in a way that it is easily accessible without distracting the user during his usual work. However, I often have confrontations with part of management because they feel certain buttons should be on multiple places and be as visible as possible.

What is your take on this? Should buttons/functionality within the same context have one place were the user should always look for it (my approach), or should buttons be duplicated to all places were the user might need them (management's approach).

Examples:
- Put another edit button right beside the tabs of a config-screen to get to the edit-mode to the app because the edit option is inside a toolbar-menu and not visible right away
- Put a save button above and below a textarea because the user could either be finishing typing (lower save is close) or finishing reading the preview (upper save is close)

Our reasoning behind the debate:

my approach:
+ slick design
+ unused icons stay hidden
+ structure
- user's without prior exposure to the software might need to look up the features/search

management's approach

+ functions are visible where they are needed
- redundant UI-components for the very same function
- disorganized look and feel
- UI bloat

I reckon that the reasoning seems biased, but that's why I am asking. What approach results in a better UI?

Answer

Duplicating actions isn't always bad in my opinion. Especially not if they are not exactly the same from the users perspective.

I think in the end, there is not one way to follow for everything. It is not do-not-duplicate versus duplicate-as-much-as-possible. Look at the case at hand and decide what the user might think here, what is their usual pattern, what would they do if it was not an application but a paper thing, how would they think. And based on that, decide where you want to provide what kind of actions.

---

Going into your first example:

Put another edit button right beside the tabs of a config-screen to get to the edit-mode to the app because the edit option is inside a toolbar-menu and not visible right away

I think this is what you say:

If so, then the two actions have different meanings for the user. The first 'edit-mode' puts them in an editorial/redactional modus (also inside their own minds) and makes everything editable. The second 'change these settings' only does that with this page.

---

Your second example:

Put a save button above and below a textarea because the user could either be finishing typing (lower save is close) or finishing reading the preview (upper save is close)

I had a similar situation lately:

In this case the first save button provides a quick way to make changes; an [ edit - change something - save ] is easily done and the user doesn't have to scroll down the whole form. And when the user does need to set the advanced options they can just follow the form and save at the bottom.

(One can argue to put the advanced settings under a link above the first save button and let it fold out when clicking the link. This is not always wanted though.)