There are two ways to approach these kinds of activities:
- Attempt to empower the people your work will affect
- Attempt to restrict the people your work will affect
By restrict I mean force everyone to do everything exactly one way. Restricting has its benefits. It will have a much smaller learning curve. It will keep everyone consistent. It will frequently work very well for the one thing it was designed for.
"Obviously a small learning curve is good!" exclaims Joe Q Designer. Everyone recognizes this, especially Joe. But in this case, Joe is getting a small learning curve because he's eliminated (restricted) many options and abilities. Clearly, you'll learn faster if you have less to learn. But Mr. Designer has traded flexibility for ease of learning. Unless J.D. has been both very careful and very lucky, this will come back to bite him in the end when someone needs to do something slightly different. Even though its only slightly different, Joe wont be able to accommodate it.
"I'll handle the slightly different cases as they arise. In the meantime, at least everyone is consistent!" Yes, Joe. But is this just consistency for the sake of consistency? Where Joe sees consistency, I usually see lost flexibility. Unless Joe can show a real benefit of the consistency, it's just a cop out.
"Well, I still think consistency is good. Plus, look at how little work has to be done with my solution to accomplish <a>!" Joe protests. I must say, I like how simply your solution handles <a> Joe. Who doesn't like simple solutions? I'm just concerned that <b>, <c>, and <d> are ridiculously hard now! If we'd made your solution less restrictive, <b>, <c>, and <d> would be easier. <a> would be a bit harder, it's true, but everything would be easier on average! Plus, when <e> comes along, we might actually be able to accommodate it.
I think its usually better to err on the side of empowering people rather than restricting them. And I definitely think its better to have a mindset of empowering people when you're designing things that will affect other people.
Don't get me wrong. You have to draw the line somewhere. You'll always be restricting something. Otherwise we'd all just give our clients C compilers and say, "off you go!" It's really a question of degrees and of what's important.
For example, if you know the users who will be using your system have no experience with computers, you're going to want to make things really simple. Like, iPod simple. However, your product is going to be better if your mindset is one of empowering, not restricting. It's not that I'm removing features because my user is stupid. I'm designing the set of features my users will most benefit from in a way that they will understand and enjoy. The guy who is thinking the second way is going to make a much better iPod than the guy thinking the first way.
So, Joe Q Designer, please stop trying to restrict everyone and start empowering us. We'll all love you for it.
As soon as I started reading this, I thought of the push in the last couple years to "convention over configuration".
ReplyDeletee.g. recent pushes in many Java framework designs, pushes toward DSLs, the allure of things like Rails and ActiveRecord (guess at what I want, your probably right, and I will tell you if your not).
As you said, its a fine line that must be made between designing for flexibility, forcing flexibility, and giving the majority of users what they need the majority of the time, without making them think too much.
Flexibility needs to be there, but I would much rather have a "dumbed down" interface that does what I want the bulk of the time and an easy one stop shop for all my configuration needs that can be as flexible and exact as needs be ... for those few times I need it.
The real problem is then really knowing your users and understanding what they need to do that majority of the time.
If we're only talking about design of end user systems, I agree with you, its clearly important to know the user and understand what they need. I still firmly believe the "empowering mindset" is important to doing this correctly.
ReplyDeleteEven still, you don't want a "dumbed down" interface. You want one that does exactly what you want in the simplest way. But as soon as it doesn't do what you want, you'll call it crap. If you can configure it to do what you want, then it's flexible, and has empowered you to change it. I think you'll agree that's pretty unusual in most run of the mill software though.
This whole idea becomes even more important when you look at API designs and "standards." Primarily because those are tools or practices you use to build something else. If they only allow you to build one type of thing, and you need to build another but *slightly* different thing... You wont be happy.
I agree
ReplyDelete