While researching another post, I came across Tesler’s Law named after former Xerox PARC employee, Larry Tesler. Tesler’s Law is an interesting concept that makes you evaluate who should bear the burden of needless complexity.
I was pleased to find Dan Saffer’s interview of Larry Tesler from his book Designing for Interaction. The opening of interview deals with consistency in interface design and was a bit of a gut punch…
Many of us realized that consistency would benefit not only users, but also developers, because standards could be encapsulated in shared software libraries. We made an economic argument: If we establish standards and encourage consistency, we can reduce time to market and code size.
Ugggggghhhh. I groan because this is probably an argument I made last week in a meeting and Tesler originally made this in ~1983!!! People have been arguing the same thing for 35 years!!! Truly, there is nothing new under the sun!!!
It’s humbling to know this struggle for consistency in order to reduce code size and time to market is not a new issue. It’s not caused by CSS. It’s not caused by JavaScript. It’s literally just a timeless User Interface problem. Those of us who advocate for design systems know their power to solve these problems.
Conversely, I wonder why such an old idea has struggled to become the default modus operandi for building interfaces. Perhaps it lends creedence to the myth that these things are just too hard. Or perhaps Xerox PARC also struggled to prioritize and get design fixes on the roadmap.
This interview is excellent and Tesler even gets into his thoughts around advocating for the user through a process called “Method Design”. I think one highlight for me were his thoughts around usability testing:
Usability testing should always be done before a designer finalizes unproven or controversial interface elements. But testing should be conducted in the cheapest possible way.
This is basically my whole thesis for rapid prototyping: Test unproven or controversial interface elements in the cheapest way possible.
The interview finishes describing the difference between Senior and Junior designers. In Tesler’s point-of-view, Junior members get fixated on a solution, while Senior members are always willing to rethink. I think there’s a grain of truth to that statement.