Best word of advice: Simplify(versiononeventures.com)
versiononeventures.com
Best word of advice: Simplify
http://versiononeventures.com/best-word-of-advice-simplify/
4 comments
This makes some good point, except for (at least) one:
‘If you create a system that any idiot can use, then only idiots will find it useful.’ still holds, even though dumbed-down versions of everything become somewhat more popular from time to time.
> 3. Simplify your UI.
> […] Taking away features can be so much harder than adding features,
> but subtracting often creates the most value for your users.
‘If you create a system that any idiot can use, then only idiots will find it useful.’ still holds, even though dumbed-down versions of everything become somewhat more popular from time to time.
Concise != Poor
I see you're a Physicist, so maybe an analogy can help: would you use the Standard Model to calculate how long your car trip will take? Probably not, Newton's formulas suffice for that, even though those only explain a portion of the world. You certainly understand the concept of elegance.
It's the same with UI design. You want to achieve a balance between function and conciseness. When conciseness suffers, it's because you're working at the wrong abstraction level or have weak conceptual integrity, not that your UI is too useful.
I see you're a Physicist, so maybe an analogy can help: would you use the Standard Model to calculate how long your car trip will take? Probably not, Newton's formulas suffice for that, even though those only explain a portion of the world. You certainly understand the concept of elegance.
It's the same with UI design. You want to achieve a balance between function and conciseness. When conciseness suffers, it's because you're working at the wrong abstraction level or have weak conceptual integrity, not that your UI is too useful.
No. But I wouldn’t want some UI designer to remove the ‘SM feature’ entirely simply because he thinks that it’s barely used and only clutters the UI. The user has to choose the right tool for the right job and as a designer it is your job to make that decision as easy as possible – surely that includes sometimes not offering a feature, but that will simply force users to choose between your tool and another one if they have a specific job to do.
Not to mention that you were probably aiming for something like (special) relativity rather than the SM if you want to compare it to Newton’s formulae. :)
Not to mention that you were probably aiming for something like (special) relativity rather than the SM if you want to compare it to Newton’s formulae. :)
> No. But I wouldn’t want some UI designer to remove the ‘SM feature’ entirely simply because he thinks that it’s barely used and only clutters the UI.
If the designer is making assumptions based on what "he thinks" and defining function from that, this is simply a poor product and design process. This is designing backwards: the UI is a result of it's function, not the other way around.
Given you mention Gnome 3 as an example, I can see where you coming from, and why the trauma about design. Gnome is not necessarily a badly designed product, they just don't cater to your demographics, or most of the Linux user base actually.
You might like reading this short book called "Notes on the Synthesis of Form" [1], which is an attempt to formalize the process of design. I highly recommend it, it can be enlightening for people of all disciplines.
[1] http://en.wikipedia.org/wiki/Notes_on_the_Synthesis_of_Form
> Not to mention that you were probably aiming for something like (special) relativity rather than the SM if you want to compare it to Newton’s formulae. :)
I'm no physicist obviously, but what I was trying to say is: you don't explain the motion of a car thinking about how particles interact, it's the wrong level of abstraction; meanwhile classical mechanics explains this elegantly, even though it doesn't explain everything. There's a balance between conciseness and usefulness, which is the same challenge faced by design, or any other discipline that deals with creating models really.
If the designer is making assumptions based on what "he thinks" and defining function from that, this is simply a poor product and design process. This is designing backwards: the UI is a result of it's function, not the other way around.
Given you mention Gnome 3 as an example, I can see where you coming from, and why the trauma about design. Gnome is not necessarily a badly designed product, they just don't cater to your demographics, or most of the Linux user base actually.
You might like reading this short book called "Notes on the Synthesis of Form" [1], which is an attempt to formalize the process of design. I highly recommend it, it can be enlightening for people of all disciplines.
[1] http://en.wikipedia.org/wiki/Notes_on_the_Synthesis_of_Form
> Not to mention that you were probably aiming for something like (special) relativity rather than the SM if you want to compare it to Newton’s formulae. :)
I'm no physicist obviously, but what I was trying to say is: you don't explain the motion of a car thinking about how particles interact, it's the wrong level of abstraction; meanwhile classical mechanics explains this elegantly, even though it doesn't explain everything. There's a balance between conciseness and usefulness, which is the same challenge faced by design, or any other discipline that deals with creating models really.
If I understand your position correctly, you have offered a false dichotomy: designers must either remove a feature entirely or leave it in and clutter the UI.
Here is a simple UI:
http://whitemagicsoftware.com/software/climate/
Here is the same software, but with a "cluttered" UI:
http://whitemagicsoftware.com/software/climate/guru.shtml
It is entirely possible to make simple things simple while adding rich complexity for advanced users. It does, however, take more forethought and planning during development.
Here is a simple UI:
http://whitemagicsoftware.com/software/climate/
Here is the same software, but with a "cluttered" UI:
http://whitemagicsoftware.com/software/climate/guru.shtml
It is entirely possible to make simple things simple while adding rich complexity for advanced users. It does, however, take more forethought and planning during development.
I rather understood the original link to offer that dichotomy in the last sentence of the third paragraph: ‘Taking away features can be so much harder than adding features, but subtracting often creates the most value for your users.’. But, yes, your example is exactly what _should_ be done, but is often much harder to do than to ‘simply’ reduce everything to the simple UI.
Basecamp, by 37signals, is a great example of this in practice. They stripped back features so they could focus on the core. In the end they were left with a great (IMO) project management SaaS. No, it doesn't do everything, but what it does do it does really well.
I think you're right in some circumstances and perhaps not so in others. Gmail in it's current amalgamation is slick and some features are hidden in menus that really don't get that much action. This is certainly a preferable user experience.
At worke we track Omniture analytics on every click event on our websites, half of most buttons/links/actions are never interacted with.
The difference is in simplifying the UI versus taking features away. The former is perfectly fine, the best UIs (in my opinion) don’t exist/are perfectly invisible. However, taking features away in order to ‘simplify the UI’ is the wrong approach – making these features accessible in such a way that they don’t clutter the UI, preferably sorted/ranked by frequency of usage certainly is superior to dropping them. That's why Emacs has M-x/M-:, menus were invented, every sane desktop environment has some way to bring up a programme by its name and human-readable configuration files were invented: Such that the most obvious parts of the UI can offer the most frequently used features and all other, less-frequently used but still necessary, features are accessible in some way.
Interesting data point that 50% of your products features are never been interacted with - I would assume that this is true for many products
This roughly correlates with "the 80-20 rule": 80% of your users will use only 20% of your features.
I agree.
I really hate the trend of removing useful functionality in the aim of, what? I dunno.
I'm happy to have that functionality hidden away in text mode config files if needed, to keep the gui nice and clean. That way you just need a check box saying "Turn on advanced features? [ ] Caution: these are not supported and you're on your own".
I really hate the trend of removing useful functionality in the aim of, what? I dunno.
I'm happy to have that functionality hidden away in text mode config files if needed, to keep the gui nice and clean. That way you just need a check box saying "Turn on advanced features? [ ] Caution: these are not supported and you're on your own".
Anyone care to discuss this in relation to a product like AutoCAD?
(It's beyond my ken, but I'd like to hear)
(It's beyond my ken, but I'd like to hear)
I've used AutoCAD quite a bit, and it's complexity goes to show that a product doesn't necessarily need to be overly shiny and simple to sell. It does follow a few of the principles it's talked about, such as the simplifying of the UI by moving to a "ribbon" UI not too unlike the move Office made recently, and splitting out features to different products. For example all AutoCAD releases can draw lines and circles, but AutoCAD Architecture has different advanced features that that of say, AutoCAD Electrical. Backwards compatibility is a huge issue in the CAD industry, not only with files, but also UI issues like keyboard shortcuts. AutoCAD does this pretty well. I doubt someone who used AutoCAD back in the 80s would have a hard time sitting down in front of the latest version and still getting the same work done without the extra features. The UI and even the toolset are all extremely customizable, but the defaults are very sane as well.
It turns out the real challenge in creating excellent things is being as excellent at saying no as you are at saying yes.
Learn how to build an organization that can do a few things, really, really well and you will win. The trick is getting really good at saying No.
Learn how to build an organization that can do a few things, really, really well and you will win. The trick is getting really good at saying No.
1. Start simple, stay simple.
It cannot be said enough. Less is more – much more, and there is a very good reason that it pays to understand.
If you do less you can measure more. If you can measure more you can better experiment with what works.
Most products are simple, based on simple insights.
Make sure that you stay true to those insights, until you know you tried out every different interpretation of them. Don’t add new features just because you think that it will help, it wont, not yet. If your product becomes a success it’s not because of how many features it has.
2. Don’t confuse change with improvement.
One of the biggest challenges record artist face when producing a new album is fatigue. They get this from listening to the same riffs, passages, drum tracks, choruses etc. over and over and over. It’s actually one of the reasons why many have a problem listening to their own album when it’s finally out. Startups as intense and time consuming as they are, have similar problems. It’s very tempting after a couple of months of looking at the same design to want to change it and think you are improving your product. You aren’t, so don’t succumb to the temptation. It’s not worth it.
Furthermore, if it goes like it does in most cases, you will soon enough have to spend resources on changing things after you launch.
3. Build to integrate.
Think about whether your product could be a good extension to already existing products/services. That way you can tap into already existing digital ecosystems and leverage on their popularity and reach this will give you some standards to adhere to. Remember that the more you are able to interface with other services the more trust you will establish. Guilt by association works both ways.
4. Don’t do everything that is possible only what is necessary.
Constrain yourself. A good product has limitations. It doesn’t just succumb to every temptation that comes along. Focus on what makes your product the product and only add features if you get clear signs that it is needed. Most users will have to learn your product anyway so don’t try to impress them with features before they understand what your product is all about. I-Tunes have many flaws, Basecamp from 37Signals leaves a lot to be asked for, but when all is said and done, their products are rock solid and there is no feature like the rock solid feature.
5. Usability studies and focus groups are for refinement not for innovation.
Let me be perfectly clear. Running a successful and informative usability study or focus group wont help you understand whether the market wants your product or whether you have solved your interaction flow satisfactory. I know there is a lot of buzz around User Centered Design and that a hoard of usability experts will claim that they can help you design more successful products if you just ask the user (Which I find ironic). Don’t believe the hype, I say this as someone who also makes a living doing usability tests. There are a few situations where usability studies make sense for startups, but most likely it wont be in your situation.
There is no one–to–one relationship between what people say in a focus group and what they actually do. It’s way to complex and there are way to many psychological elements and social dynamics involved to allow you to extrapolate important data out of it at an early stage.
In most cases you are testing in a pseudo environment with mock-ups, html prototypes or even paper prototypes. Just imagine how Twitter, SMS, Google or LastFM in it’s early days would have scored. So many products need to be experienced before users will provide you with any valuable insights to build on.
It would be like trying to determine the usage and usability of a hammer by looking at a piece of paper with a drawing of it. You get the picture.
6. A feature is not a product.
Speaking of hammers.
Don’t just think about your product as a bunch of features. Instead focus on what it is your are selling at it’s core. What is needed for your product to function? How much can you take away from it without sacrificing the core product.
Think about features as something to add after you have launched.
http://000fff.org/wp-content/uploads/2009/11/product_feature...
A hammer has one purpose, which is to help you knock in nails. Everything on top of that is features. Therefore understand when you are working on your core product and when you are working on adding features.
The benefits of thinking like this, is that it will help you establish a very clear an precise picture of what makes your product your product. Which means you will much better be able to understand why you are adding features when you are and won’t get caught in the “me to” behavior that can drive companies out of business very fast.
7. Think how, not what.
What matters is not what functionality your product has, but how it works. A sign-up process is not just a sign-up process, a checkout process is not just a checkout process, a button is not just a button, a rating system is not just a rating system.
Think about how you can stand out by introducing something that everyone else might have but in a unique way. That’s what Steepster did when they re-designed their rating system (se how they did here http://blog.steepster.com/post/226679106/better-rating-syste...). Skype was not the first VOIP provider, far from, but Skype managed to make it stand out and look like a product not just a technology. In other words they productified a technology
You will be surprised how much the “how” can help improving your product.
8. It’s not innovation to use the latest technology.
It’s tempting to try and set yourself apart by using the latest build of some framework or technology. But don’t do it just because it’s the latest. Make sure that you understand the implications of what you are introducing. Is it processor intensive, is it increasing load time, does it improve the experience, is it understood by enough developers so that you can optimize it.
If you can’t answer the above, you probably shouldn’t do it.
All to often companies get caught in thinking that new technology in itself is the differentiation factor. But as most successful businesses know. Innovations have an introduction curve and not everyone should take advantage of a given technology just because it’s available.
Full post here: http://000fff.org/beyond-aesthetics-design-tips-for-startups...