I'm going to avoid casting aspersions on my fellow developers and instead simply own up to my own failings…I've been developing software since I was 10 years old (my first program was written in BASIC on a Commodore PET), and professionally for well over a decade, and for most of that time, I believed that design was someone else's job, and that it didn't matter whether I could design my way out of a paper bag.
Design is everyone's responsibility, at least to some degree. No, you don't have to start wearing black turtlenecks or engaging in other clichés, but what you should do is start cultivating a basic knowledge of design, and training your eye for what is and isn't good design, both in the world of pixels as well as in the real world. Have you ever found yourself marveling at how difficult it is to figure out how to use some basic device? Listen to that voice in your head...it's telling you that you're dealing with a bad design.
An example of this may be found in some of the newer water coolers I've encountered. In a misguided attempt to modernize this humble staple of the office, some manufacturers have added text displays, extra buttons (including in some cases having more than one button of the same color). Think of a water cooler in your mind's eye...you'll probably see two spigots, one with a blue lever, and the other with a red lever, for cold and hot water respectively. There's no need for an instruction manual, and it doesn't matter whether your native language is English, Spanish, German, or whatever, the use of color easily conveys the purpose of each spigot. If you replace these easy-to-use spigots with buttons and screens that may convey more information, but require more time to comprehend, you have not done any favors for the person who simply wants a drink of cold water.
For developers who are fortunate enough to work on a team with a full-time dedicated design professional, then that person can lead the effort in creating and executing a beautiful and functional design. But we, as developers, aren't off the hook. We have to execute on the vision and ensure that the app being developed looks great and works well.
And for those of us who sometimes (or always) have to work without the benefit of a designer on our team, it's all the more important to think about and learn more about design, including observing and noting both good and bad design examples all around us, so that we are better able to provide user interfaces that are visually compelling and intuitive to use. This is true for all applications, but it's especially true when building apps for the web, or for Windows Phone (or other mobile platforms), or for the Windows 8 Store, where your competitor is just a click away. And if your app is ugly or hard to use, that click will come quickly.
To put it bluntly, our success as developers is riding on adding design knowledge to our toolbox, and now is a great time to start building that toolset.
These are two words that, when placed together, may draw snickers in certain corners. And you could argue there was a time when that snickering had a basis in fact. Not anymore. Microsoft has spent years building its design muscles, and creating a consistent and compelling design language, called Metro.
I had the opportunity to present at the MoDevUX conference in Tyson's Corner, VA. MoDevUX focused on user experience and design, and had attendees who design and develop apps for all manner of platforms. I gave a 30-minute talk on the Metro design language, and attendees seemed pretty impressed from the buzz on twitter afterwards, including one attendee who came away with a different opinion than he started with.
I'm grateful for the opportunity to share some perspective on how design is evolving at Microsoft, particularly since it gave me additional incentive to dig deeper into the Metro design language, and its inspirations in the world at large, as well as its roots in earlier Microsoft products.
There are several movements that have had an influence on the Metro design language, including the Bauhaus movement of art and architecture, Swiss Design, and Motion Design in Cinematography. Visually, Metro takes some of its cues from the world of wayfinding signage. As with some of the previously mentioned influences, this is a world that has a strong emphasis on typography and iconography that are stripped down to their essence, with no unnecessary ornamentation.
And there's a good reason for this…when you're rushing to catch the next subway train, or to try to make your flight before they close the doors, the last thing you need is visual noise getting in the way of the message…where is my gate? Likewise, Metro design places the focus where it rightly belongs, on the content that matters to your users, not on decoration or chrome.
You can learn more about the inspirations for Metro by watching Sam Moreau's talk from BUILD, entitled "Designing Metro style: principles and personalities," which does a great job of exploring the topic of where the Metro design language came from, among other things.
One of the first major software releases to show an end-to-end Metro influenced design was Windows Phone 7, as I'll discuss in a bit. But Metro did not simply appear, fully developed, with the release of Windows Phone. Rather, elements of what became Metro have been a part of several Microsoft products for years, and Metro is an evolution of these products, a refinement that has taken the ideas they represented, and codified them into a consistent and elegant conceptual framework.
An early view of some of the ideas behind Metro can be seen in the "twist" interface of Windows Media Center. The interface is designed to minimize elements that might interfere with your content...the TV shows, movies, and music that are important to you. Navigational elements such as media transport controls (play, pause, ffwd, etc.) are hidden by default, since many users will be using a remote control to navigate, which will already have dedicated buttons for these actions. In fact, only if you're running Media Center with a mouse or keyboard will you ever see these elements. This emphasis on content is reflected in the Metro design principle of Content before Chrome.
Likewise, the Media Center interface has a strong emphasis on typography, using text as the primary means of navigation through the available features of the software, and relying on text size to denote hierarchies of information.
I still remember my first chocolate-brown Zune music player. Don't laugh, but I loved the "double-shot" translucent finish. The color choices may not have been everyone's cup of tea, but it's hard to deny that it was a bold choice to include brown as one of the colors for the first generation of Zune devices.
But even more so was the UX, which took the "twist" interface of Windows Media Center to the next level, making the entire interface all about beautiful and clean typography. And several design choices appeared that have carried on to subsequent implementations of Metro, including text that bleeds off the right side of the screen, indicating the ability to scroll for more, and social sharing (the ancestor of the Share contracts in Windows 8).
The Zune HD stepped up the design, adding a bold, beautiful hardware design that was widely lauded, a capacitive touch OLED display, and a nice touch of whimsy, including a subtly animated home screen that responded to movement of the device by moving the foreground text and background tiles (or vice-versa) relative to one another. It's not something that you would necessarily notice immediately, but when you did, it was one of those "wow, that's cool" moments that delight with the attention to detail (delighting your users by attending to even the smallest details is a great habit to get into).
The addition of touch made for an interaction model that relied much more on direct manipulation, such as swiping left or right to change tracks on an album or playlist, that made the device a pleasure to use (and easy to use without needing to look at the screen).
The Zune devices weren't the only ones playing in the early Metro world. The Zune software for Windows is another great example of the ancestry of Metro, with a major focus on typography defining the UX and hierarchy of information.
Note, also the use of tiles with bold photography overlaid with crisp text. While the UX for the Zune client for Windows is busier than a typical Metro style application should be, in comparison with most Windows apps, there is a dramatic reduction in the use of chrome for hierarchy and navigation. Instead, navigation is achieved by clicking on the applicable content.
And when playing songs, the Zune client shows off some more attention to detail and early Metro stylings. Again, you see big, bold photographs and color choices, an emphasis on typography, including subtle translucent scrolling text with information about the artist, song, and album currently playing. And you can see the use of the simple and bold icons that continues in the more recent implementations of the Metro design language.
What you should take from these examples are some good practices to follow. When designing Metro style apps, spend some time thinking about the content of those apps. What is the essence of the content? How can I most effectively present the content to the user? More examples can be seen in the following examples of the more recent evolution and implementations of Metro.
Metro made its first big splash with the introduction of Windows Phone. With a Start screen made up of bright, bold Live Tiles, and an almost entirely chrome-free UX, Windows Phone was a huge change from Microsoft's previous efforts in the mobile space. And with it, developers can create apps that are not only beautiful in their own right, but also have their own Live Tiles that expose constant, up-to-date information, giving the user a great "glance and go" experience.
Along with a new design language, Windows Phone introduced new controls, including Panorama and Pivot, optimized for the touch-first environment of a smartphone, and designed to make navigating through content simple and intuitive. And the Windows Phone SDK and tools included project templates that provided named resources for all of the variety of font sizes and such, making it easier for developers to follow suggested practices.
Notice that the implementation of Metro on the XBOX 360 is not identical to that of the phone. This is natural, because there are critical differences in how users interact with a game console and TV compared to how they interact with a phone. The XBOX 360 dashboard is optimized for use with a game controller, Kinect, or voice, while the phone is optimized for touch.
The XBOX 360 also includes a music and video player based on the playback experience in the Zune client for Windows, and if you have not used it, I highly recommend it, both as a beautiful player for music (particularly if you have a Zune Pass), and as an example of a bold and effective UX design.
Despite the differences between the Windows Phone and XBOX implementations, the essence of the Metro design language is there. Unnecessary decorative chrome has been stripped away, leaving the important information and content to take precedence. While most of us won't be developing for the XBOX 360, the use of the Metro design language here helps familiarize users with Metro, discover content more easily, and prepares them for using Metro on other platforms.
Of course, I can't talk about the Metro design language without discussing it's most mature and sophisticated implementation, Windows 8.
Right from the moment you turn on a Windows 8 device, the emphasis on design shines through. Beautiful photography, and important information at your fingertips, without even needing to log in (of course, the user is in control of which apps can display information on the lock screen). The use of typography and of visual white space allows both the beauty of the lock screen background and the user's information to co-exist in harmony, neither detracting from the other.
And upon logging in, the user is greeted by the new Windows 8 Start screen, with Live Tiles providing access to the apps that matter most to them. These Live Tiles are alive with activity, updating the user with relevant information on upcoming appointments, recent emails, and more, giving them easy access to the information that is most important to them, without needing to open the apps. Of course, Live Tiles can also be used by developers to entice users to return to their apps for more information on the tile updates, so a great tile design is an important step towards a successful Windows 8 Metro style app.
As developers and designers, we should think of Live Tiles as the front door to our application, and put some effort into making that door as enticing as possible, to bring our users in again and again. The MSDN Library provides guidance on the use of tiles that you should review when designing the tile for your app.
So far, I've mostly talked about Microsoft's implementations of the Metro design language. But how does Metro help you, as a developer, become better at design?
No, I'm not going to start noodling on Tron: Legacy...I'm talking about the grid as a guide for laying out the UI of your Metro style application. The grid allows us to create Metro style apps that are consistent, both visually and functionally, with other similar Metro style apps. Note that this doesn't mean that you cannot differentiate your app visually. All of the apps (keeping in mind that these are from the Consumer Preview release, so they are previews, and should not necessarily be considered reference applications) shown at left leverage the grid to consistently lay out their content with a header and consistent white space that not only gives the content room to breathe, but also automatically leads the users' eye to the right location to find the important content. And each app is visually distinct, with variations in the balance between images and text, sizes of UI elements, use of color, etc.
Now if you're developing a Metro style game for Windows 8, of course you probably will not use the grid to lay out your content, but for most Metro style apps, the grid will provide a very useful way to easily make your app "fit in" with the Windows 8 environment.
My co-worker Chris Bernard, who is a UX Evangelist (yes, that's his actual title) puts it this way:
A grid helps you remove random and arbitrary choices around placement that can harm user experience—but it also provides flexibility and you should ‘respect’ the grid versus ‘obey’ it. Pushing boundaries on purpose versus by accident.
That focus on seeing the grid as a tool and a starting point, rather than a rigid requirement, is exactly right in my view. The grid isn't there to limit you, but to free you.
Templates will not turn a developer into a designer. But what templates can do is to give you a solid head start towards following best practices in the design of your application. The templates included in the Visual Studio 11 beta release include a Grid application template and a Split application template (there's also a Blank application template for folks who want to start essentially from scratch), as well as Fixed Layout and Navigation applications. The Grid, Split, and Navigation application templates all include styles (CSS3 or XAML resources) that help align your content to the grid.
Whether you choose to leverage one of these templates for your final application or not, I highly recommend that you go through the exercise of building at least a simple application based on the templates as a learning exercise. It will help you to see and understand how the various parts of a Metro style application work, both visually and functionally.
And with a little bit of work to retrieve some custom data in place of the sample data, perhaps a bit of added background interest via colors, an image, or even SVG elements, a few calls out to REST services, and you can end up with something a little more interesting, such as my in-progress Community Megaphone Metro style app shown at left. Note that, thanks to the the use of CSS Grid for layout in the Grid application template, my title, headers, and content all align to the recommended positions, with little or no additional work needed on my part, so I can focus on the aspects of my application that are differentiated, such as the SVG logo I've used for the background, and the Bing maps I've used for the individual tiles representing each event.
It's important, too, to note that the templates provided in Visual Studio 11 beta are but a couple of examples of how you can implement applications that embrace Metro style principles. You should explore using variations of size and proportion in your apps, and see how that impacts the visual hierarchy, or whether such variations may help highlight featured and/or relevant content.
Last, but certainly not least, developers wanting to learn more about Metro style app design, and the Metro design language can find guidance at http://dev.windows.com (focused on developing apps for Windows, and includes a section on Metro style apps for developers) and http://design.windows.com, the latter of which is focused primarily on designing UX for Metro style apps in Windows 8, and (at the time of this writing) contains the following resources:
It's a great time to be a developer, and whether you're developing Metro style applications on Windows 8, Windows Phone apps, or even web sites, design is becoming an ever more important part of the job. Taking the time to add design skills to your toolset will help you (and your apps) stand out in a more and more crowded marketplace.
My thanks to my Microsoft colleagues Chris Bernard and Sara Summers, both of whom have far more design expertise than I can lay claim to, for reviewing this post prior to publication. Their input helped me refine some of the ideas above. Any remaining typos, strange ideas, or odd statements are purely my own.
[Note: subsequent to publishing, I decided to update one of the photos to reflect the most current release of Windows 8 at the time of this writing.]
I work for Microsoft, but the views expressed on this weblog are mine and do not necessarily reflect the views of my employer.
All postings are provided "AS IS" with no warranties, and confer no rights.
Unless otherwise noted, all code provided in this blog is copyright © Microsoft Corporation, and licensed under the Microsoft Limited Public License (Ms-LPL). All rights reserved.