2

Background

I have a right sidebar and a left sidebar, both are shown all the time, the right sidebar purpose is to change the background in the middle editing frame by selecting one of the options in this bar, this is always shown, I was asked to add another sidebar on the right side that is going to be a text options toolbar, where you can change fonts, style, size, etc...

I don't want to show both at the same time I want to have only one selected because there is no live preview of this editing flow so I see no point on having them both shown besides the code is already done to have one, show it and hide it...

My question is

How can I justify my assumption that having both right sidebars shown at the same time is wrong or at least that is not a good practice or is it?

Am I on the right track by assuming that I should not show the user too many options at the same time if he is not focused on using them all?

  • not sure if I'm understanding this correctly or if you made a typo. Anyways, the way I read this is that you will have 1 sidebar on the left, one on the right, and then another added sidebar on the right (hence 3 sidebars). Is this correct? – Devin Aug 23 '16 at 16:54
  • Yes! sorry for the typo – Abdul Hamid Aug 23 '16 at 17:15
8

Learn, don’t justify

Here's your problem:

How can i justify my assumption

Don't justify it — test it. User experience is about discovering the answer, not enforcing it through academic stubbornness. What if the alternative performs better for some reason you didn't foresee. Users are a complex animal.

I suspect your resistance to change is grounded in this fact:

the code is already done to have one, show it and hide it...

You aren't avoiding change by using justifications to preserve your hard work on the code — you're only delaying it!

Continuous improvement

Refactoring is a reality of writing software, just as it is with product design. Making assumptions comes with the territory, but there's a very good chance you missed something. That's why we test for usability, performance, stability, etc.

You have to go into every project as if you're building a prototype. Not in the sense that you write throw away code, but with an awareness that everything you do is up for revision the moment you release it.

How do you know when it's time to improve? The product leadership sets performance metrics at the outset. Everything is continuously measured against those goals.

Back to your question

Without context, our assumptions are far less valuable than yours. There is a solution to your problem, but we'd have to know more about your users and the product to get anywhere near it.

  • 1
    ...and if the assumptions are correct, the test will be the argument. – Heitor Aug 23 '16 at 18:25
0

I agree that "the code is already done to have one, show it and hide it..." is a bad reason not to make the change. Your other objection sounds more solid - will this be a useful feature for the end user? Ask your users.

Btw, there are precedents for this although not exactly the way you describe, if I am understanding you correctly. For example in Axure, multiple sidebars are accommodated on the right and left by stacking them vertically. See example: http://kimhiltz.com/wp-content/uploads/2009/05/Axure1.gif

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.