This post is a mashup of my notes from the Adobe 😄 group’s session at MAX, the Apple iPhone Tech Talk with John Gelenyse, Director of Technology Evangelism & User Experience Evangelism at Apple I attended today and my personal thoughts on User Experience on applications that I see across the web (even the ones I have written 😉 ). Hopefully you will find these pointers useful in evaluating application designs before you deploy them to the masses.
Identify the problem:
A no-brainer, right? But you will be surprised how often applications start looking at features without identifying the core problem they are trying to solve. Just as often, the problem statement is formed incorrectly. For example, for a video aggregator like say, the Adobe Media Player, is the goal isnt to aggregate videos but enable easy discoverability of video content. The fact that this is done via aggregation is a secondary thing.
Whats the point?
This is the most important question that you SHOULD be able to answer in one or two sentences. Apple calls this the product definition statement. In his talk, John gave the example of Apple Aperture. While Aperture has a huge number of features, the product definition is simple and strong: “An online image management solution for professional photographers”. The product definition statement must include the function and the target audience.
Think Task First
Identify what the task is. The interface must make that task really easy. You should even break the tasks down by order of importance and make the ones at top really easy to accomplish. Again, dont design for the task that a minority will do. Identify and define:
- primary and secondary tasks
eg: organize, purchase and approve
- primary and secondary objects:
eg: people, movies, books
Keep it simple
Again, fairly obvious but I know some of my own applications suffer from this. As a developer, I know exactly what actions the various nuts and bolts on my application trigger but how obvious is that. How many actions are you trying to promote on that one application? Dont overthink the problem or optimize the design for the edge case. John exact words were :Simple and straightforward is best. Make it dead easy to use!
useful -> useable -> desirable
Andrew from 😄 talked about the progress of the application as it approaches completion. First and foremost, the application should be useful. Once you have that part worked out, make it usable so that an average user doesnt have a steep learning curve to your application. Finally, it should be desirable and this is where you tweak the designs, colors etc. A lot of applications seem to go the other way
Content is king
Remember the application design is to promote the content. In the case of the Adobe Media Player, the original designs were beautiful but reduced the video content area to a small window in the corner. The one released has the video as the primary focus and the chrome is completely secondary.
Create an experience, not an interface
Sounds like another slogan doesnt it 😉 ? But keep the user experience as the priority. While the buttons and knobs may result in a working application, if its not an enjoyable experience for the end user, its to no point. At this point, I think Andrew brought up the Apple IPhone and talked about how people forgive the mediocre phone capabilities of the device just cause the experience is so good (as an iphoner myself, I completely agree 😉
Choreograph sequence and flow
Transitions and animations arent just eye candy. They help keep the users oriented as the application interface changes as the user tasks change (for example, the Adobe Media Player starts out giving the user the ability to browse through content, but at some point the user finds a video to watch and now browsing is a secondary action with the watching being the primary. The transition of the browse area to a list on the right keeps the user aware that the browse capabilities are still there but are not taking up the main focus space)
Trust your instincts and later have it validated by usability tests:
If you have a seasoned design team, there is a good chance that they intuitively understand how users interact with applications. They may even come up with a paradigm that hasnt been established yet but may be a great idea (for example, a lot of sites now offer tag clouds that I prefer to get to the more interesting parts faster, but who came up with that ?). Dont be afraid to try something different. But validate the paradigm through usability.
Prototype, prototype, prototype
Nothing beats a prototype.
The 😄 team has an internal wiki where all the designers upload their work everyday. They then work off of each other’s ideas.