Desktop apps for Macs and PCs generally have had the same UI for over 30 years. There was the top pulldown nav, a top “ribbon” bar with some handy doo-dad icons that you’ll probably need to access functionality quickly, sometimes a bottom nav. Oh yes, and lots of confirmation messages. ("Are you sure you want to close?" "Are you sure you want to save?" Apparently, the apps never thought you knew what you were doing. Honestly - that was sometimes the case.)
I believe the Web saved us from the nonsense we were experiencing with native Desktop apps.
- Web apps leverage browser functionality with newer, more flexible coding languages to create new functionality and UI approaches. Think HTML, JavaScript, AJAX, and more. They are easy to learn, easy to use to create apps, fairly easy to maintain (ok, easier than Java, C, or other compiled languages).
- Best practices and paradigms shifted to be simpler and more automated, based on user expectations. Rather than confirmation messages, we started seeing autosave used more. Rather than being able to access one version at a time and manually save versions, there was version control functionality built-into apps. Rather than long release cycles lasting months, Agile methodology sped it up to weekly or bi-weekly sprints and releases every month or two. Automation for testing and releases improved. Amazon now releases fully-tested, new features and functionality every 12 seconds.
- Simpler screens with fewer options. Web apps were a way to start over creating apps and software, focusing on core functionality first rather than nice-to-have features that didn't add bottom line customer value. Functionality was added as users needed rather than a product manager creating functionality that may - or may not - been used. And hiding functionality in 2-3 layers of pulldowns was no longer the norm. The goal was to create more direct interactions.
In many ways, without the Web, we wouldn’t have simplified software.
And the Web in its nature made software easier to create and distribute. Native desktop apps took a lot of time to develop, compile, and QA - and required a lot of effort for distribution. In the 80s and 90s, few would purchase software from a new, unknown software company, if that company could get its software onto store shelves. Even still, with the dawn of the Web and the rise of viruses and hackers, Web distribution and acceptance of new software companies was slow-ish. And online apps didn't really appear until well into the 2000's.
Then the industry giant, Apple, created the App Store for the iPhone.
Software and hardware innovations are linked. A leap-frog improvement in one is necessary for the other to gain improvements and vice versa. Mobility required us to simplify experiences. I mean how many options (buttons, text, or otherwise) can you really put in an interface smaller than an index card? Eyes can only read print so small and fingers can only press buttons 50 pixels square. Mobile interfaces meant simpler screen design, the rise of gestures and the emergence of voice technology.
And innovations in how we do business and live were occurring faster and faster because some of the operations and development side of software was simply easier.
- There was an easier way to distribute and purchase apps and software. You didn't need to go to a store anymore to get software. The device included a store in the operating system and companies could sell their apps to anyone. And it didn't matter if you were small and unknown. Your app's popularity, its rating and price-point mattered. This allowed companies that didn't think like the giants to create new software experiences that matched new conventions.
- The rise of services and APIs allowed complex functionality to be leveraged - not originally built over and over again by countless companies. You could now create code to access a service and be done. This sped up development time and lowered cost to get product out the door. And this lead to...
- Software-as-a-service companies, through services and APIs, allowing companies to specialize in an area and connect to another app in a related area to create a better app. So you could almost create your own super-duper, bells-and-whistles app the way you wanted by connecting a string of apps together. You got the features you wanted - not buy more features than you need, like the old app model. This opened up the possibility for new companies that wanted to bite off a smaller chunk of functionality to develop and sell.
- Move to leasing - rather than "owning" - software. In the old, giant days, people went to a store, bought a box that contained a book and CD or disks and "owned" that software. If there was an update, you had to go out and buy a new box with a new book and CD. In the current new model, you pay for access to tools each month and these tools are automatically updated on your computer or through a browser.
And these innovations in software operations and business continue happening, further speeding up innovations in app technology and usability. Apple pioneered being more open with distribution, but now larger players like IBM with Watson and Google and others are opening services for developers to leverage AI and other functionality that previously would have required years of development to create alone.
The move to voice commands over touch-interfaces is making interactions with devices even simpler, more available and easily accessible. The giants are providing infrastructure; the smaller players are providing innovation for process and experience (UX). With the speed of change, innovation, and need for better experiences, soon to use an app, you will only need to know how to have a conversation. No more touching, tapping, or gesturing.
With all of the shifts in best practices over the years, this raises the question: what exactly is a best practice for UX and UI? Best practice can lead one to think about familiar functionality, which often gets labelled as intuitive. So what does it mean to be intuitive?
I believe there are key elements that characterize a good UX/UI experience. And these elements have always existed - and always will - whether we are clicking, tapping, or using voice when interacting with a device.
- The product and UI solves a problem. If a product doesn’t clearly solve someone’s problem, and the user doesn't immediately understand how it does, then take it off the market. If a product solves many problems, simplify it. People won’t understand it if it is too complex with too many features and ways to work. People prefer simpler products.
- The product is found attractive by users. It can be plain, but it has to be easy to use and easy to look at. Visually attractive products make a difference (this blog post speaks to how products need to have a pleasant experience).
- The product has easily discoverable functionality. This is largely forgotten these days, especially with gesture-driven UX. And this has always been my personal challenge with gestures. How do people know gesture are available to leverage without a manual or demonstration? The sign of a great UX/UI is that you can use the product without a manual, without training. A great design challenge is to create a straightforward experience that invents new conventions to achieve new user goals. That’s a sign of a true UI artist.
- It has a direct and clear interface and interaction. People are able to use the product to get the job done. The interface uses plain and clear language. You can be direct but branded.
- It is interactive and conversational. Apps need to be more interactive - not less. And with the rise of voice technology, this conversational approach will only be in use more often. Rather than the user sorting out what he wants to find it on a menu, the menu is completely flat and activated with voice control.
Software and hardware is changing rapidly - and not simply through technical innovation but operational streamlining, automation, and collaboration. The giants are encouraging others to come to the table to innovate. And all of these players, in the end, still are creating experiences that demonstrate these 5 main qualities. We need to look at best practices as traits and requirements rather than features, functions and items to implement. We need timeless expectations to guide us - not specific implementation guidance.
Comments