We are a software company that provides some great products, managed by an outdated admin site.

We want to re-design the admin site and create a toolbox for our clients that helps us report the data that is stored/edited by that admin.

We are considering making two separate UI's and also making it one UI separated by user permissions so that our clients don't have admin functionality. How would you decide which route to go?


I had experience with both approaches reaching the market. I find that having one UI component is better in most cases, especially if you look at the long term planning. If reporting features are configurable or require little coding to adapt to different data sets, incorporating them into other aspects of the product helps with user's decision making. For example, admin of the database needs to schedule maintenance window and would like to see usage peaks and troughs. But this is more project management approach than UX.

Looking at pure UX, if you are 100% UX driven, it really depends on your user stories. Two separate UIs is better if you want everyone to instantly recognize, what part of the system they are in and if there is very little or no overlapping functionality. A single UI allows for shorter learning curve if there is a chance the same person will use both UIs.

Another angle is how many features admin UI has. If the system has hundreds of functional points and supports even more scenarios, it might be an overkill to introduce reporting into it. Reporting too can be overly complicated with various BI tools involved.

I will stop from it taking further, as I am not sure I understand the logic behind "toolbox for our clients that helps us report the data that is edited by that admin". If it is a toolbox for the clients then you, as a software company, should not be involved in report generation, in my mind at least.

  • I think you hit the main tension here which is, the question of the overlapping functionality. I could create two functioanlity audits for each component and then compare where the overlap is - but how do I determine how much overlap calls for a combined UI? If 50% of the functionality is the same? 60? 80? Obviously there is no rule of thumb, but as you said I am worried about this combined UI's not being easily recognized and not feeling like a an admin tool or a reporting tool - just this large mess. Dec 16 '13 at 3:11

I recently had to make the same decision with the current project that I'm working on. Basically, there was a use case for a rep with limited permissions and a use case for an admin with all permissions to create, edit, etc. My situation may be a little bit different than yours due to certain feature sets within the app, however in my case, most features that were available to the rep were also available to the system admin, but they obviously had more features at their disposal.

Given that both users will have different accounts, the system admin can define and allocate permissions which in turn, removes/adds features accordingly. So depending on whether you're a normal rep or a sysadmin, you'll either have a limited amount of features available to you or everything.

Now, does this affect the UI and the decisions that you make with it? Absolutely. If you want to create an experience that is familiar across all users regardless of permissions, if that's the way you want to go, then how you design the interface is important. The approach I did was segmented most features into their own blocks per se. This means being cognizant of what features rely on what, however if done right you can still make the experience similar with or without a certain feature for both parties.

In the end, it really depends on the particular use cases. Fortunately in my case, having it so there's a limited feature set for one party through permission and little more available for the other (and not being superfluous at the same time)it creates a consistent experience for both users and is less time to market with having only to build one product.


It is not so much how to decide but rather what information you will use to make the decision. There are always multiple competing priorities when it comes to the limitations and scope for UX design, and you may find that perhaps time and budget are your biggest roadblocks rather than UX design decisions.

It seems like there needs to be a better understanding of your users, or else you will just be making a lot of assumptions about how the system should be designed in theory. I would suggest that it is probably better to base that decision largely on users rather than in a limited capacity. Otherwise should just wait until users complain before overhauling the design rather than building an interface that doesn't really cater for anyone properly.

I think if you base the decision on the amount of risk versus the amount of information you have access to and find the right balance for the project then you can't go wrong, or if you find that you've missed something in the analysis, at least there is a way to move forward.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.