Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't really get the point of Tesler’s Law: "any system there is a certain amount of complexity which cannot be reduced"

Is it basically saying don't try to hide a bunch of options behind a hamburger menu?



It's become common practice in B2C software to distill the UI down to an insane degree (eg. basically an infinite scroll feed). Since the job to be done of most B2C software is basically: placate my existential angst with various forms of content, this works. Consuming content is not a complex task.

However, it's become en vogue to apply this same design logic to B2B software, where this approach is bound to screw things up.

In B2B software, the tasks are often much more complex (eg. help my large organization collaborate on bespoke long term projects and juggle hundreds of stakeholders, while offering cascading permission management), so any software suitable for this task is going to be a nightmare to use no matter how good the design is (because its a nightmarish task).

The same goes for front-end website builders. Wix has a simple UI because it only lets you do simple things. Webflow's UI is super complex, because it offers all the powers inherent in coding HTML/CSS by hand. So you essentially have to learn HTML/CSS to use it.

The UI of any tool must match the complexity of the job to be done. This doesn't mean UIs can't make things easier/faster. It just means UIs can't remove steps unless you remove requirements.

Often when a tool is lauded for "good design," its because it encourages removing steps that were unnecessary all along, but people were still doing out of tradition. The tool then gives people an excuse to stop doing the stupid tradition, because "X doesn't allow that."


From the site itself:

> 1. All processes have a core of complexity that cannot be designed away and therefore must be assumed by either the system or the user.

> 2. Ensure as much as possible of the burden is lifted from users by dealing with inherent complexity during design and development.

> 3. Take care not to simplify interfaces to the point of abstraction.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: