User Feedback - Before, During, and After Development
Development doesn't end when it comes out of beta. Google demonstrates a never-ending development process that procures user-feedback in a way that is both non-intrusive for the user, and, in Google's interest, in a format concise enough to handle yet informative enough to act upon. The key is prompting the user for a small amount of specific information at the at exactly the right time - when they want to contribute.
When Google responds to user feedback quickly and implements changes in its software, the results are often half-working features that are experimental and unpolished (think Gmail Labs). For some, like me, this fresh feel "working demo" (Google's willingness to implement code before it is "finished") is a powerful tool and playground, and highly encourages me to give constructive feedback about glitches or ideas for new features. Oh yea, and it also dramatically speeds up the software development life cycle by helping the developers via sometimes immediate user feedback. Google's extreme implementation of the agile software development process puts the company on a path to being limited only by their resources (man hours, time, and maybe money) and the choices they make on where to focus their efforts. In other words, they've got a good thing going (and it benefits us consumers too).
Google's rapid development style isn't without mishaps. With the release of Google Buzz, many users like me were unpleasantly surprised to learn that Google had taken it upon itself to make connections (add "friends") between you and your "commonly contacted contacts". The off button for Google Buzz is buried in the settings, but go find it if you haven't yet because it's probably still on. I'm going to let Google figure out social networking for a little while longer before I jump in.
Usability vs. Features
Offering the right balance of usability and powerful features to each unique user is quite a challenge. Some software like Numark Cue (DJing software) and even Microsoft Office products (toolbars) offer different interfaces: (for example) basic, advanced, and professional. Though this is helpful, the idea of modules takes it a step further and allows the user to have any combination of add-ons instead of choosing from three pre-configured options.
To help users customize how they want to use Google Chrome, extensions can be installed, enabled/disabled, and un-installed. The concept of modular units within software is quite an intriguing one. It allows users to customize the features of the software.
Modules Explained
In addition to the initial installation and setup, most programs have "Options" or "Settings" that everyone is familiar with. These usually include minor tweaks in appearance. Modules, on the other hand, represent an entire feature or subsystem within a program (think the Calendar part of Outlook or a plug-in on Photoshop) and should also exist within the settings, allowing a user to fully un-install a feature that isn't needed. The user also has the ability to install any number of available "plug-ins" which can be provided by the original application developer and/or third party developers. This is organized in a type of marketplace (like an appstore) where most (if not all) of the add-ons are free (this may change).
We have seen this exact software model take hold in the mobile marketplace with the wide adoption of smartphones and apps. Apple's iTunes App Store, Blackberry App World, and Andriod Market are the big ones, allowing a user to install apps onto their hardware's OS platform (iPhone - iOS4, Blackberry OS5, Android - Froyo 2.2). Smaller app marketplaces are popping up everywhere. Specifically, cloud-based project management software benefits from using modules. I think that all types of software can be more successful in the long run by using modules (apps) and a supportive community dialog as part of the development process.
The modular software model highlights the importance of the user. The interface of the software is the most crucial first impression that a program can make. Too often it was an afterthought or simply "good enough". Now, it is finally starting to be noticed as the number one design feature in my opinion.
Communicate effectively with the User
Google does an excellent job of communicating with its users, AND providing a way for users to communicate back. New feature updates are visibly marked with "New!" and messages to the user are informative with details and (usually) offer a choice. Communication (technical writing copy) is fundamental to any application. There should always be another level of detail / description that can be accessed, whether it is in the help menu, or in a link pop-up, make it clear where the user can find it. Configuration modules are useless unless you have communicated effectively to the user about how they work and how to add/remove them.
An intuitive user interface: simple, offering ONLY the features I want and nothing else to get in the way. It sounds too good to be true, but it's not. Software development has a long way to go. Bringing the user and the developer closer together is definitely an exciting step in the right direction.
When users are passionate enough about an application, and the developers can meet or exceed that passion level, a functional, useful, successful app will be born, and cared for (updates, patches) throughout its life. If we can figure out how to get a better monetary incentive system for low-level consumer apps (specifically mobile), we can speed the process up even more.
Copyright 2010 Eric D. Maniloff - All rights reserved.
