A developer sees an application as a toolkit to help them solve a problem. The more flexibility and power, the better it is. They’ve become comfortable with complex tools on the computer, over the years, because they enjoy learning about and using computers.
A nontechnical end user generally isn’t interested in operating a toolkit— they want to solve their problem, and the application claims to do that. The easier it is for them to get from problem to solution, the better.
When a developer sees a software interface, they see a palette of commands and parameters to pass to a software back end. Understanding that, and it’s implications, took years of learning and intensive usage that has blended into an imperceptible base layer of technological understanding.
To a nontechnical end user, the interface is the software. The button might as well mechanically do something. For whatever reason, often because they didn’t find it interesting, or their cognitive skillset didn’t easily adapt to it, or they just didn’t have the exposure, they didn’t learn about the basic structure of applications, and they’d be years away from understanding it enough to make decisions based on that.
Flexibility and power yields agency for technical users. It blurs obvious pathways and dampens signals for nontechnical users that just want a problem solved.
It’s difficult for experts to see things with novice eyes. That’s one of the most important things a designer can do for the software building process.
Fundamentally, interface design is a communication discipline. There’s a reason it’s a field unto itself, with its own degrees and professional organizations, and there’s a reason it’s often taught in art schools. There’s also a reason that every significant user-facing interface in your life, from your text messaging apps to the ordering kiosks in restaurants— none of which need documentation— were created by designers and not developers. Looking nice is not the point — it’s often a side effect of clear and deliberate communication, which is both difficult and important.
A nontechnical end user generally isn’t interested in operating a toolkit— they want to solve their problem, and the application claims to do that. The easier it is for them to get from problem to solution, the better.
When a developer sees a software interface, they see a palette of commands and parameters to pass to a software back end. Understanding that, and it’s implications, took years of learning and intensive usage that has blended into an imperceptible base layer of technological understanding.
To a nontechnical end user, the interface is the software. The button might as well mechanically do something. For whatever reason, often because they didn’t find it interesting, or their cognitive skillset didn’t easily adapt to it, or they just didn’t have the exposure, they didn’t learn about the basic structure of applications, and they’d be years away from understanding it enough to make decisions based on that.
Flexibility and power yields agency for technical users. It blurs obvious pathways and dampens signals for nontechnical users that just want a problem solved.
It’s difficult for experts to see things with novice eyes. That’s one of the most important things a designer can do for the software building process.
Fundamentally, interface design is a communication discipline. There’s a reason it’s a field unto itself, with its own degrees and professional organizations, and there’s a reason it’s often taught in art schools. There’s also a reason that every significant user-facing interface in your life, from your text messaging apps to the ordering kiosks in restaurants— none of which need documentation— were created by designers and not developers. Looking nice is not the point — it’s often a side effect of clear and deliberate communication, which is both difficult and important.