Tweet

This blog post might not make justice to the depth and expertise that the discipline of Information Architecture deserves (although the definition of Information Architecture is still in flux) so I’m providing links at the end of this post to other websites that can take you much deeper into Information Architecture.

Demystifying IA

As deep as Information Architecture is however, it really is just a portion of a larger scope of activity called User Experience. Information Architecture is a means to an end. Information is not the user. The user is the user - a human. I’ve seen many websites or apps that sometimes seem to be primarily designed to please information itself - as if information or content was THE user. Take the typical approach of defining the ‘navigation menu’ for a content driven website. It is typical to see the navigation menu reflect the content structure available in the site, for example:

We’ve designed menus like these for years, but this is a completely anti-user view of the world. The website or app in this case is designed based on content types instead of designing it based on user needs. A user (in this case a ‘developer ‘) arrives to the website with a technical question about ‘how to set up data binding in a data grid control for a line of business application’. When the user gets to this site they know they have a need but the site is talking to them as if they knew where to search for their answer - should they go to Case Studies and hope to find how another development company solved a similar problem? Should they go to Tutorials and see if there’s an article that addresses this question? Should they go to Code Reference hoping some information is provided there? How about the Forums?

A different approach is to make the navigation menu based on a different metaphor that addresses users’ needs. If you start simplifying the sample menu I mentioned above you will perhaps find that the best result is just to substitute all those options for one single search box where users can write their need/question.

While I might sound too extreme here, well, that’s actually what Google did - instead of having nested menus with tons of topics or categories like AOL or Compuserve did back in the day - Google said, let’s just give the user one simple input textbox so users type what they are looking for and voila! one of the cleanest UIs that turned into one of the most profitable and efficient user interface metaphors in the last decade. Still today the Google search page is considered a digital icon - just like the Fallingwater house from the Architect Frank Lloyd Wright in architecture or the Starry Night from Van Gogh in painting.

If you ask me, the Google.com site is a great example of how the Metro Principles would manifest on the web. There’s a lot of conversation going on right now about applying the Metro Principles to phone and tablets but a lot of people are also asking, how would Metro manifest in a website - look at Google.com. Fierce reduction of elements. Content, not Chrome (no pun intended ). Google.com has slowly been getting more elements (look at the top) but it still is quite clean.

The Google example is pretty radical (though real) and shows how Information Architecture doesn’t mean only information structure. The term Information Architecture tends to make it feel like users are not part of it (since the word ‘user’ is not included in ‘information architecture’) but users are actually the center of it. Some of today’s best and most recognized Information Architects like the folks at iA get this and while they love to give shape to information, all their projects have user as the center - Try the IA Writer app for iPad.

On October 15^th, 2008 Glenn Murphy, an Software Engineer in Google wrote a blog post titled Content, Not Chrome. It’s interesting to see how the browser ended up being named ‘Chrome’ though

In conclusion, IA is not only about “structuring content” but about crafting the axis, the foundation, the structure of your entire digital experience. Saying IA is critical for a digital experience is an understatement. Literally think of IA like the soul or spirit - the essence of the experience. And just like every spirit (that I know of… :)) it needs of a body to manifest through. This body is the app.  So there you go: IA is the spirit. The app is the body. They are so interconnected, so tightly integrated that you can’t think of them separately. They form THE experience.

IA is all about bringing order to chaos, to align the misaligned, to sequence the random, to parse the mix, to understand the complex.

What is Information Architecture?

The Information Architecture Institute defines Information Architecture as “the art and science of organizing and labeling websites, intranets, online communities and software to support usability“. The Guardian recently made this post about the definition of Information Architecture. Also, here is a really good video produced by Buuteeq on What is Information Architecture? to show their non-techie customers the value of Information Architecture. It’s a good video to understand IA in simple words.

The way I describe the activity of Information Architecture is bringing order to chaos, to align the misaligned, to sequence the random, to parse the mix, to understand the complex.

The goal of the Information Architecture (IA) stage is to define three things:

-  Information

-  User Tasks

-  Relations between Information & Tasks

That’s what the user has in a digital experience: 1) information and 2) the potential of doing something with this information - whether it’s consuming information to help take decisions and/or for generating new information.

Most of us will start creating a Windows Phone app for either A) a client B) an idea of our own (startup idea). In both cases when the project begins we will be exposed to shapeless and scary ‘blobs’ of information like names, dates, prices, images, temperature ranges, zip codes, phone numbers, avatar images, scores, in-app purchases, stocks, locations… in the Information Architecture stage you take that shapeless blob and deliver structured information. Doing it in single try is impossible. It needs many passes. If I think I’ve nailed it on the first pass I’m wrong - Only Zeus himself could do it in a single pass But in all seriousness, force the IA to go through many passes whether you do it or you have others take a stab at it and provide feedback.

Tools to Define Information Architecture

We have three very useful tools that help us define our IA:

1.       IA Document

2.       Application Flow chart(s)

3.       Low Fidelity Prototypes

Something very important to consider here is that at this point we are not designing the user interface or the app itself. We are still working at the ‘essence’ or ‘spirit’ level - so no need for us to over invest time in visual design, user interface or animation details. Right now we simply want to straighten out our blob of information, bring order to chaos.

IA Document

The IA document I usually create is quite simple although you could add as much detail as possible. The truth is in many cases this document grows to become the actual specs of the app. But in our case we will keep this document nice and short. Here is an example that shows how we have brought our now more orderly blob of information into a document that shows the main and primary hubs as well as the spokes. This is a sample IA Document for a simple ’stock price’ app.

Download the sample IA Document in Word format. 

App Flow Charts

Remember the good old flow charts for software engineering (or any other process)? That’s what App Flow charts are, it’s just that the visual nomenclature we use is focused on user flow, experience and interaction design. I take the IA Document, with its early stab at the main, primary, and secondary hubs and also the spokes and transform it into a App Flow chart. Initially I add little visual information to each screen. Just enough to see the different modules connecting to other modules.

Then little by little I start adding more details to those screens for example I start adding some UI controls - only the critical ones that allow me to start telling user stories. Later I start turning some of these screens into abstract Pivots, Panoramas or Pages.

And so, little by little App Flow charts become more detailed going from simple task flows to screens that show an idea of content views and even navigation. I wouldn’t call high end fidelity App Flow charts wireframes but many people would. Low fidelity wireframes certainly.

Low Fidelity Prototypes

Once the IA Document and the App Flow chart are more solid, it is always a good idea to start working on paper prototypes - our third tool in defining the IA for our app. These can be helpful due to their low cost ($ and time-wise). A paper prototype is a paper version of your app - how fun is that! You can put together one of these bad boys by simply sketching out the different screens of your app, or for a more refined paper prototype you can use wireframes of your app. Just like with an IA Document or an App Flow chart, Paper Prototypes also evolve little by little and go from low fidelity to higher fidelity. Notice I say “higher” and not “high” fidelity because I personally don’t think it’s worth producing a super refined, polished, high fidelity paper prototype. The idea of a paper prototype is *precisely* to keep it rough, quick and dirty. The good thing about a paper prototype is that it is something that you can actually place in front of an actual test user.  The IA Document and the App Flow chart are too abstract for mortals to go through You and I sure… but for our dear user testers, a paper prototype is something they can actually use.

Please refer to the Paper Prototype section of the #3 Ideation and Concept post of this series for more information on how to create Paper Prototypes.

Now, it might seem, when I tell you that after the IA Document, comes the App Flow chart and afterwards comes the Paper Prototype, that I’m implying there are days or weeks or months in between these different stages/steps, but no In fact we are probably talking about minutes or hours between IA Document to App Flow to Paper Prototype. That’s the whole point of this process - to make it quick and dirty.

At the end you will have a solid IA document with structured information, a solid set of App Flow chart(s) and even some low fidelity Prototypes.

Architecting Information (for a Windows Phone App)

As I mentioned before, I won’t make justice to the practice of Information Architecture in this post but the method I use to define the IA for a Windows Phone app is the following:

1. We capture the needs of the project. We work with our client and write down the different needs, requests, data types, questions, wishes, and even ponies and unicorns in post it notes.

Important

Write user tasks or needs in post it notes of the same color. Write information/data or content on post it notes on another color.

2. We host a creative analysis session with at least one person from engineering and one person from our creative team and we go through the post it notes, we explore, we best guess, we inquire, we question and we debate to define and understand what the client really needs (which might be different from what they think they need).

3. We add our own flavor. Based on this analysis we add our own post it notes with needs, questions and also ponies and unicorns.

4. Create logical groups of related items. Group things in a way that makes sense. Pair things up, group them, relate them and highlight cross over connections.

5. Define hierarchies and give order by capturing the general structure of the blob we are dealing with in an IA document.

6. Create an App Flow chart. Once the IA Document is at least a bit readable - transform it into an App Flow Chart. Notice our natural approach here will be to create a tree like structure but this is precisely where you can break the mold - you could approach your app structure in different ways, radial, layered, multidimensional, hub & spoke or others… however, talking about Windows Phone apps in particular, where the app structure is based on the Hub & Spoke model, it is best to from the beginning of this exercise define a Hub & Spoke structure to your information. A Hub & Spoke model would define a 1) Main Hub 2) Sub-Hubs or Spokes of top level 3) Spokes of secondary levels. Eventually these different hubs or spokes will end up manifesting as Panoramas, Pivots or Pages in Windows Phone but in this stage we are not yet looking into this. Notice I mentioned “eventually” J No need to get too concerned about Panoramas, Pivots or Pages during the first few passes.

Microsoft will not reject your app if you decide not to adopt or follow the Hub & Spoke navigation model - so feel free to explore other models if they make sense to your app. That said, the Hub & Spoke navigation model is arguably the best one and the one that will become the most familiar with users so it is better to use it.

7. We identify relations (or dependencies) between different branches in the structure and we capture them in the IA document or the App Flow Chart.

8. Put the IA Document and/or App Flow chart to the test by telling user stories against them. Look for showstoppers - gaps or excess tasks and/or content/information and/or relations between tasks and content that are blocking you from being able to tell a user story. Based on these run-throughs, refine your Document and/or Chart and test it again with the same and/or more user stories. Do this a few times until your structure reacts firmly to all the user stories you are trying to address with your app.

9. Create a Paper Prototype. After a few passes, it is good to transport the IA Document and/or App Flow Chart to a Paper Prototype. And from there you have 3 things to iterate on, IA Document, App Flow Chart and Paper Prototype. Test the Paper Prototype with user stories and refine it until it can stand the test of all the user stories you want to address in your app. The Paper Prototype is useful because it takes your IA to the next level and it starts feeling more real (even if just in paper). You might be able to capture other pieces of data with a Paper Prototype vs just using an App Flow Chart. Also note that a Paper Prototype is something you can actually put in the hands of a test user whereas the IA Document and the App Flow Chart might be too abstract for a non-techie user or simply someone outside of your team…

The process of defining the Information Architecture for your app is not a one shot or one pass type of activity. It requires of many passes and many tests to your IA Document, App Flow Chart and Paper Prototype. Also, a reminder that at this point we are not fully designing our UI so you do not need (and I would probably not recommend) to invest a lot of time making the screens look beautiful - that comes later. Right now we are just trying to bring order to chaos.

Conclusion

At the end you will have a solid IA Document and App Flow chart(s). Not sure I’d say Paper Prototypes are something that you end up with - I personally see those more for iteration and to refine your specs. Things you will throw away at the end. Everything that you learned with the Paper Prototype(s) will be reflected in the IA Document and the App Flow chart(s) anyway plus the Paper Prototypes can easily get really messy J

So with IA Document and App Flow chart(s) you are ready to go to the next step which is to really start nailing down your Pivots, Panoramas and Pages with more detail.

More Resources on Information Architecture

The Guardian - What is Information Architecture?

Information Architecture Wikipedia

Usability First - Information Architecture

Web Monkey - Information Architecture Tutorial

What is Information Architecture?

Complete Beginners Guide to Information Architecture

Information Architecture - A List Apart

Information Architecture 101- Techniques and Best Practices

Design Your Windows Phone Apps to Sell

Understanding Information Architecture Differently

Next Post | #7 Layout and Composition in Windows Phone. In the next post we will review a couple different techniques to compose and layout Windows Phone UIs. The first one is using the Windows Phone design grid and the second one is using lists.

A month ago I decided to leave Microsoft. Today, I’m writing to say thank you to all of you for your support and friendship throughout the years. It’s been quite a ride. I could write a book (or two) about all the things I learned while at Microsoft, the stories, the products, the people. It’s definitely been an amazing, life changing experience to be here. Microsoft has this special something that keeps you hooked, motivated and inspired.

I feel very lucky to have started and closed my career in the company with two very different but each outstanding leaders, Forest and Corrina - both passionate about design and about growing personally and professionally and about pushing yourself to the next level every day.

I am taking sometime off with my family and then as soon as I can, will spend about a year working on personal illustration, design and speaking projects. I plan to continue to be involved with Metro

Hey, where’s the Windows Phone Design Series? - Well, now we will actually have time to finish it - and the promise of turning it into a free e-book at the end is still the goal.

While I’m offline  my brother Alejandro will help me publish the next few articles starting this week.

7 Years of Design Evangelism

8 years ago after reading about the leak on Sparkle, I found out about Creature House Expression 3 and started using it (Secret: the original Creature House Expression 3 that Microsoft acquired from a one man company in Hong Kong and that later became Expression Design, also inheriting the name ‘Expression’ to the rest of the studio - is still available for free here… check it out!). Back then I was also posting doomsday notes in the Macromedia Flash forums (you have to read this lol - I wrote on January 2004, just a couple months after that memorable 2003 PDC when Longhorn was announced) announcing Flash’s death due to this thing called “Avalon” (WPF) that Microsoft was creating… The story turned out to be much more interesting than that

Then, 7 years ago I joined the Expression Product Management founding team working for Forest Key and with other amazing folks like my dear and kawaii friend Miwa Mueller, Wayne Smith and Brad Becker.

Forest is the most inspiring, sharp, creative business leader I met during my career in Microsoft. I was lucky to join Microsoft working for him. He really pushed me to grow. He encouraged me to learn how to communicate to people - to demo and talk, to sell and pitch and even to make people laugh - I also learned how to motivate people and keep them encouraged and focused. Today I cannot measure the impact of his influence in my life - After Forest started growing (quickly) within the company, I started working for Miwa - I will always remember the first time we went to Japan, the dream of my life, being in Tokyo blew my mind away! By then I knew a tiny bit of Japanese and had friends in the city so it was a very fun experience. Miwa and I presented together in front of almost 700 Japanese developers. Fun! We stayed at her parents and the experience of actually sleeping, eating and even using the bathroom in a 100% japanese home was so interesting (and confusing too :)) - Arigatou Miwa-San

During these almost 7 years at Microsoft, I had the opportunity to be part of the founding teams that launched Expression Blend (and Expression Studio) version 1 to 4, Silverlight version 1 to 5 and WPF. I was there during the genesis of these technologies and learned tons from my Product Management team (aka Marketing), Product Team (aka Engineering) and DPE (aka Evangelism).

With a design background I drove design content, training, evangelism and messaging for Silverlight, Expression and Windows Phone. My audience were both designers and developers. Looking back at my career here, it is clear to me that my focus - the one big thing I did was drive Design Evangelism & Education. That’s what I do. While I love being an Architect and do actual design - my real contribution these years (and in the future) will be Design Education.

When I get back, you will hear more about my plans for the future on this area.

Artist in Residence

One of the most fun projects I drove during this time was hosting the Silverlight Artist in Residence event (originally kicked off by my friend Barak Cohen, then taken over by Nishant Kothary). In this event we would invite designers and developers (in pairs) to spend a week building a Silverlight app or game. It was sort of a Survivor-like, reality show experience for attendees and was always highly praised by internal teams as well as top agencies who visited us in Redmond. It became the de-facto training method for depth partner enablement. We trained the top design agencies in the U.S. as well as other top development shops. In a week, developers and designers would be ready to go back home and start working on real client work immediately.

.toolbox

After that I had the pleasure of working on Brian Goldfarb’s and Brad Becker’s group. The legendary and awesome Silverlight team. It was during that time that my friend (and “work wife” :)) Vivian Chan and I partnered to build .toolbox which basically solved, in one shot, the need of the community to get Expression Blend and Silverlight (design) training. Today .toolbox has more than 40,000 members from 100+ countries, hundreds of thousands of lesson videos watched and training content packages downloaded. Vivian has taken good care of our baby and added a fantastic series with additional badges on Windows Phone Design.

Metro Design Tour

This last year has been a blast! I started to explore a switch in my career from Product Management to UX Design. I was rescued by my dear friend Corrina Black from the claws of SQL Server and I joined her team. I learned so much! - Being in a UX team in Microsoft was a completely different experience!

Her group was nested right at the intersection of all of our client teams and the platform & tools group so we had exposure to everything - like a candy store of design. I had the opportunity to collaborate with the XBOX group in the early stages of design for the new experience released last Fall that brought the concept of “apps” to the XBOX experience. I explored and learned about designing Kinect-based experience thanks to some amazing people in the XBOX Design Studio including Grant Hinkson (oh nooo…) and especially Ali Vassigh (a must follow). I also worked on a number of Windows 8 BUILD sample apps - some of them like CheckMate, made it to Developer Preview.

Later, as part of the Windows Phone Design Studio, we reached out to our friends in the Western Europe region and partnered to put together a Design Day tour. We spent two months traveling and visiting 11 countries in Western Europe + South Africa meeting thousands of developers and designers, reviewing hundreds of apps and learning a lot from all of you who are making Windows Phone your own and are pushing it to the next level. Recently we also visited San Diego and Vancouver in partnership with Nokia - good times. Nokia folks are really great people.

The coolest thing throughout all these years has been the opportunity to be exposed to the end-to-end user experience and design vision and execution in Microsoft (Windows Phone, Windows, XBOX, Silverlight…). I’ve always enjoyed influencing, driving and contributing to the larger picture.

Microsoft

I will always be grateful to Microsoft for changing my life. For giving me so much support and so many learning experiences. For opening the doors of the world for me to discover and meet wonderful people inside and outside of the company - people from all sorts of cultures and countries. Today I know people and have friends in all 5 continents and it’s a blast to learn from different people who speak different languages, with different cultures and that live in all corners of the world.

For those of you exploring or interested in joining Microsoft - Do it! - It is an amazing company to work for. There’s always fun things to do, you have a great (and huge) campus in a beautiful city - Seattle and the surroundings are gorgeous. Tons of lakes, everything is green - Sure it rains a lot but that gives you infinite amount of trees, lakes and snow in winter time. Lots of trails for running, biking, hiking and the best adult hockey league You get free access to the ProClub which is one (if not) the largest gym in the US - it really pumps you up if you are into running or working out. The Company Store is cool because you get really good discounts on XBOX games and software. The ski and snowboard resorts are as close as 45 minutes away so many people leave earlier on Thursdays or Fridays and head up to the mountains for some evening action. You get free drinks at the office - I will really miss my Mango Talking Rain (Zero carbs! :)).

In terms of your career, one of the things I always liked in Microsoft is this culture that enables you to define and shape your own career. While you of course have managers and groups and VPs, at the end I feel it’s all about where YOU want to go. If you are smart then you can pick the right battles and the right growing paths and contribute to the company with what you think its best. Coming from a more entrepreneurial background, I found this to be the key for me to be happy in the company. They trust you.

If you are ever interested in working for Microsoft in any group, drop me a note and I’ll be happy to give you tips or connect you with someone in there.

If you are a designer then you will enjoy working for Microsoft. It’s a different culture and company from the one a few years ago. Microsoft has finally embraced design and is empowering design leads and designers to really drive the direction of the company. From Albert Shum to Steve Kaneko, Bill Buxton and Jeff Fong, you can see how Microsoft is a great place to develop your career doing design at scale that reaches millions of people around the world. Having had the opportunity to be part of the Windows Phone Design Studio was incredible. The design talent bar in there is mind blowing. People like Jeff Fong who guided the implementation of the Metro Design Principles to create Windows Phone or Mike Kruzeniski who has quickly grown to be one of the most influential design leads inside and outside of Microsoft.  Kat Holmes with whom I did some traveling in Europe a couple years ago and from whom I first heard of Metro. Jae Park, also a lead and member of the Microsoft User Experience Leadership team (with other folks like Kaneko, Buxton and Moreau). 

The People

Let me have my Oscars moment now…

Throughout the years I would receive emails from folks leaving the company saying something like “I’ll miss the people - it’s what matters” and I always thought of it as a cliche but nooooo… Now that I’m here, I’m like yeah - it’s true! - I will miss so many people. My always inspiring friend Corrina who kept me motivated and encouraged to run and run to the point that today it’s my favorite sports activity. My sweetest and mega-talented friend Sandy with whom I’ve spent hours and hours drawing and who introduced me to Eggs Benedict at Lola (ZOMG!) - I might finally use that 1,000 color pencil box Sandy. I’ll miss my friend Maria (born in the city of Toledo, Spain :)), Darlene - a rising star! and my buddy Jared Potter. I will miss my new and amazing Studio friends I quickly fell in love with: Jane, Jocelyn, Andrea, Jeremiah, Frank, Aaron, Kat as well as everyone else in the Studio and outside the Studio like my BFFs Miwa, Viv, Michael Bach, Joanna, Susan, Guillaume, Jon Harris & John Alwright, Emily Anderson, David Salamon, LuisDans, Tim Sneath and all my buddies in the Expression and DPE groups like Jaime Rodriguez, David Carmona, Emilio and Rick. Also my friends in the field - my dear and design evangelist rock star Sara Summers, Danwei, Katrien and Isabel, Kasugai-San, Chris Bernard, Will and Sean, no way to name everyone who is special to me. Just last weekend while celebrating my friend Jaime’s birthday I had a chance to see 3 of my favorite guys, Dan Fernandez, Brian Keller and Ben Lower (sorry @bgoldy and @jeffwilcox for missing you :))

lol this was just like when people receive an Oscar

I decided not to send a massive email to announce my departure but send an email to each person - it took a long time to send about 200+ emails but it was a joy to hear back from everyone. So much love I feel lucky and grateful. It certainly isn’t a goodbye for folks in Microsoft and especially in the community - we’ll meet again soon.

Albert Shum, the director for the Studio is the most accomplished and impactful design leader I’ve met at Microsoft. On our last conversation, he told me something I’m closing this blog post with - “it’s all about the team and the people in the team - work is fun and all, but at the end it’s about our lives, family and the people who matter to us. If we can have you take a seed from what you learned here in the Studio and plant it somewhere else, and have you grow something amazing and different, that’s what this is all about.” 

… and so that’s what I’ll do

   Tweet

To give continuity to the previous post on iconography, let’s talk about App Bar this week. I apologize for the “organic” approach to tackling down the blog post schedule� In this post we will discuss the Windows Phone App Bar. The reality is there’s already plenty of good information about the App Bar out there so I’ll see this post more as an aggregation of what I’ve found out there plus some other tips I’ve learned along the way.

The App Bar in Windows Phone is one of the controls with more personality in Windows Phone. It is usually seen as a navigation bar but what I’ve found consistently is it’s more like an “action bar”. The reason I say this is because if you look at the out-of-box experience in Windows Phone you will find most of the Icon Button or Menu Items are more like actions or ‘verbs’ than pointers to other portions of the app. This might sound like semantics but I think it’s actually something stronger than just that.

The most important navigation mechanism in Windows Phone is content itself. Our instinct when creating an app tends to be solving navigation by adding as many buttons or UI controls as we think we need. In iPhone you will find developers enable users to go to other sections or even content views using the tab bar. In Windows Phone these views would be part of a Pivot control (Featured and Most Recent). Categories will most possibly have been located in a previous Page, Pivot or Panorama. If the user wanted to go to Categories in Windows Phone they would hit the back button. The Search button would be in the App Bar and the “More” would remain there as our Ellipsis Expander.

So, in Windows Phone the App Bar is usually not used for navigation per se but for “actions”. I don’t think this is written in stone though - for example you will find Settings available in many apps in Windows Phone (in the App Bar). Settings is clearly navigating the user to another section of the app - it doesn’t sound like a verb. In Windows Phone if you wanted to have two Icon Buttons in the App Bar called Theaters and Movies, then instead of navigating the user outside of their current context, these buttons would act more like “view switches” so the user stays in context, but the view changes to show movies or theaters. This is what happens in the Calendar - you have a Month Icon Button - you hit it and the view changes to Month view but the user is still within the same context aka Calendar.

So they key takeaway is to always try to enable navigation through your application using content first - not UI controls. Use the App Bar mainly for hosting actions, not navigation (again, there’s always navigation occurring as you will be taken to another screen but within the same context).

Also a common approach coming from iPhone/Android worlds is to locate navigation buttons within content on the main page. In Windows Phone we usually avoid mixing UI elements like buttons with content. So if you have an email items list we would never place a button next each item for say “Deleting”. Instead we would recur to the use of tap and hold to bring out the Context Menu for the item, then hit Delete. In the case of the App Bar we could also have a Delete button in there, hit it and that switches the List View to multi-selection along with changing the App Bar to display new icon buttons relevant in this multi-selection mode, the user multi-selects items and hits the trash can button in the app bar.

The App Bar can either be collapsed or expanded (up or down). In both cases there are different states the App Bar can adopt.

App Bar

The Application Bar is one of our core navigation mechanisms in Windows Phone. It is a flexible control that lives on the bottom of the screen or on the sides if on landscape mode. The App Bar is 72 pixels high. The Application Bar always stays on the same edge of the display as the hardware buttons (Back, Start, and Search). Up to 4 icon buttons can be displayed in the App Bar but you could display down to 0 (zero) buttons if needed. If you don’t have icon buttons to display it’s better to switch to the Mini App Bar.

The App Bar is made out of the following elements:

Mini App Bar

In Mango, the Windows Phone team released a new mode for the app bar called Mini App Bar. The Mini App Bar is 29 pixels high. The goal was for this mode to release more pixels for developers/designers to use in their application when in many cases icon buttons were not needed and it was possible to condense required functions within the app bar menu space. This Mini App Bar would also enable us to use an App Bar in a Panorama, something that on the first release of Windows Phone wasn’t officially allowed. An option is to make Mini App Bar semitransparent (just the way you can do with a standard App Bar) if you want to let the content be visible. You can apply a 65% transparency to the Mini App Bar.

The App Bar is Flexible

Not every Panorama  (or Pivot or Pages for that matter) will require an App Bar. It will depend on your Information Architecture and content.  You can go from standard to minimized App Bar modes when going from Panorama panel to Panorama panel which means the user will see the bar rise or fall depending on the App Bar mode needed in that particular panel.

Icon Buttons as well as sub menu options in the App Bar may change across different panels to accommodate the right functions needed for each panel.

Multistate Buttons in App Bars

A common question we hear is if we can host two or even three state icon buttons in the App Bar and the answer is yes. Two states could be enabled/disable and three states could be state 1/state 2/disabled. In all these cases it is important to portray the icon button state using the right icons. In general we want to preserve the same icon throughout the different states although in some cases when it makes sense you can slightly alter the icon to represent the new state or even change it completely. For example in the case of the Favorite icon (I don’t believe we actually use this example in Phone but totally valid).

Another example is for instance the SMS (Text Messages app) in Windows Phone - you will notice that if you press the + to send a new message the “send” Icon Button in the App Bar is disabled (because you have not yet typed anything). As soon as you type one character, the Icon Button goes from disabled to enabled state and you can now hit it. These are the subtle details that can really make you app nice and polished.

App Bar Menu Items

Menu Items live in the App Bar and they are only visible when the App Bar is open or extended. Menu Items present tier 2 or second priority functions in your app.

It is important to consider that Icon Buttons and Menu Items should be seen as two different groups of functions. You have 4 open seats for Icon Buttons in the App Bar and in theory an unlimited number of Menu Items… although it is good to keep this from zero (0) to 10 items.

At the same time, note that you do not have to necessarily fill up the 4 seats you have available for Icon Buttons. You could decide to have only one Icon Button. You also could decide you do not need any Menu Items… zero. That’s just fine too.

One question/myth I’ve heard a few times is that you forcefully fill up the 4 seats available for Icon Buttons pushing the 5^th function and beyond as Menu Items but as mentioned previously, Icons Buttons and Menu Items should be seen as two different function groups (not necessarily with continuity). So  if you realize you need two Icon buttons, and three Menu Items… that’s just fine.

Custom Usage of App Bar

Throughout the out-of-box experience in Windows Phone you will find some instances where the App Bar seems to be designed and working in a non-conventional way. The reality is you can define custom setups for App Bars as long as they help you address your particular user experience. An example of this is the Photo Camera which when expanded will show the Menu Items for camera settings on top and display the icon buttons for picking the camera flash mode on the bottom.

App Bar Colors

The out-of-box color in app bars is dark gray. This color remains while in a Light or Dark themes. This color is neutral and reliable for a number of scenarios. You don’t have to use that color all the time though. There are a couple other ways to setting the color for your App Bar. You can set these colors on the background color of the App Bar or in the foreground color of the App Bar (the Icon Buttons and Menu Items).

1 - Using the user accent color in the phone

2 - Using a custom color based on your brand

While all these are possible, freedom means responsibility J Remember we are talking about Metro here so we want to keep design clean. Usually you will find black and white color (defaults) for icon buttons work the best. For the app bar background itself the default gray will always be a safe bet but if you need to color the app bar for branding reasons, just make sure this color doesn’t make the white/black icon button invisible or hard to see (like making the app bar yellow will make the icon buttons hard to see).

More Resources

In this section you will find some useful links to learn more about App Bar. There’s really good info about this control out there. Please drop me a comment if you have specific questions or scenarios and I’ll be happy to ask the team to give me ideas for me to share with you.

Page Structure - App Bar

App Bar on Orientation

App Bar Overview for Windows Phone

App Bar Design Guidelines

App Bar Icon Buttons

Jeff Blankenburg on App Bar

Tweet

Next Post | #15 Designing Windows Phone Icons. In the next post we’ll cover Windows Phones icons in depth.

Good week everyone! Last week I traveled to Germany to speak at M-Days. It was a quick visit but super fun event with tons of people who participate in different segments of the Mobile industry. I learned a lot about the staggering growth expected for everything related to mobile, phones, tablets, devices. Because of the trip I didn’t have enough time to write the next article called 6 - Translating Information Architecture into a Windows Phone App Flow. So instead of failing at my commitment to post every week I decided to produce the 15 - Designing Windows Phone Icons post. How naive! this post turned out to be one of the longest ones! (and I’ve wrote some long posts already!) - so here it goes.

Designing Windows Phone Icons is one of those things that would seem straightforward but instead it can be something actually quite challenging for different reasons. Compared to other aspects of Windows Phone, designing icons is definitely more of an art than a set of rules or guidelines. We’ll certainly cover the guidelines but ultimately there will be some creative/artistic aspects to creating great icons. This applies not only to Windows Phone for any other platform. Designing icons for iPhone, Android or Windows is always a whole specialty on its own. Creating icons is such a specialty that there are companies and designers who are devoted 100% to designing icons like the popular Icon Factory.

Windows has a long tradition with icons since its inception and the Windows team has provided guidance for previous version of Windows. Windows 7 icon design basically shows the highest point in skeuomorphism (using physical world metaphors with realism to illustrate abstract concepts) for Microsoft. From there, we are now going to a very clean and minimal style with Metro.

Let me provide you with a useful resource right off the bat before we start going deeper into the topic of the day. A designer in the Studio provided me with a cheat sheet that includes different tips for designing Metro icons. This is the designer that has drafted most of the icons in the Phone or has helped other designers in the Studio do it as well. Here are a few of his tips:

- All icons are monochrome

- Use knock outs instead of drop shadows

- Transparency instead of shade

- Chisel arrow heads

- Use square corners instead of rounded

- Use square end caps instead of rounded

And here is a visual chart with his tips:

You know how I always take things deep right?  So it won’t surprise you I will now want to talk to you a little about design history and where Metro icon style comes from. I think this will give you some context and will eventually enable you as a developer to look for the right designers to partner with. It should also help designers to pin point the visual style used in Metro for icons.

We’ve mentioned before that Metro is influenced by the International Typographic Style or Swiss Style which in turn learned also from the Bauhaus school of Architecture and Design. This whole movement was broad and global. With the continued globalization of the world in the early 20th century, many people realized that more common visual languages were needed to communicate with people of all sorts of different cultures and backgrounds.

Otto Neurath, a philosopher, sociologist and political economist defined the thinking behind something called the Isotype. His goal was to share political, economic and social data to people even when these were not experts on these disciplines or couldn’t even read. He is what I’d call, the father of Infographics - or at least the first one who really kicked of the idea of conveying complex scientific and economic/social data using only images. Neurath’s theories were put in practice when he partnered with Gerd Arntz, a designer. Arntz helped visualize Neurath’s ideas and craft an Isotype Collection that is now regarded as the early origins of all international communication, urban signage and transportation graphic iconography.

In Arntz Isotypes you can see how the concept of abstraction was present. Communicating a concept with as few elements as possible. No use of regional or extremely local aspects, textures or symbols but instead looking into represent concepts by observing a global understanding.

The Pictographic Corporation, founded by Rudolf Modley - designer, was the American wing of the thoughts and visual communication language that Neurath and Arntz started in Europe. Modley’s work, which represents American economics/communication aspects, demonstrates the same abstract, global visual expression from Neurath/Arntz.

One interesting visual aspect that Isotypes used was contrast. A masterful use of this tool allowed designers to produce and convey complex graphics in a single color. This would not only strengthen the idea of minimalism and clean design but it would also make printing cheaper. There was a strong social understanding from this visual design school of thought.

I found this concept of contrast has been applied in a couple different manifestations: Infographics and Illustrations.

From those years, 30s-40s, this visual language spread out throughout the world. The Second World War and its conclusion increased the need for a global language. Society had never had so many people traveling throughout the world. People from Asia came to America, and from America to Europe. People from Europe went to Africa, and from Africa to Asia. Globalization. With people from different cultures and languages, governments had the need to create universal visual languages to enable visitors to major cities like Paris, New York, London, Tokyo, Mexico, Munich. Throughout these years many designers addressed and produced symbols (icons) to address this need. Producing large amounts of graphics to convey instructions, warnings, guidance and information in communications, transportation, society/politics/economics and even sports primarily driven by the Olympics.

In 1974 the United States Department of Transportation (DOT) realized that just within the U.S, there were many different isotype collections being used. Multiple versions coming from different sources. Most of them would address the same concepts, for example, 21 different icons were found for Coffee Shop being used across different cities in the U.S.

The DOT commissioned AIGA (formerly the American Institute for Graphic Arts) to produce a single (”one rules all”) symbol (icon) catalog that address the visual needs across U.S. cities. This would basically unify the visual language in the country. It’s kind of ironic that a design style that’s supposed to convey universal concepts had SO MANY different versions of doing so!  This topic could take us into a deep deep conversation about Metro (how there are many ways of doing things , not just one) but I’ll skip that discussion for now  A number of designers including Massimo Vignelli, one of the most influential designers in the U.S. who brought the International Typographic Style to this continent.

This team of designers performed an extensive research and catalogued a huge number of symbols (icon libraries) used by different cities in the U.S. and other countries like Japan, France and the UK. Then they designed the “one rules all” symbol collection which is now used across the U.S. and many other countries. This symbol collection is available free of use in the AIGA website. Many of these icons would work great as Metro icons… some of them might not be readable at 26 x 26 pixels in an app bar but for in-app icons yeah, they could work.

This effort gave birth to what Ellen Lupton, prolific type and graphic designer described as “The Helvetica Man“. It is interesting to find similarities with Helvetica Man and with what we all know as Stick Figure which is kind of the simplest way to represent a person. Egyptians were already using this symbol back in the day. This just reinforces the lesson of today’s post: Abstraction. That’s all. See you next week.

…

Ok, not enough let’s go deeper 

But really, when designing Metro icons we are not thinking too different from those Egyptians or from our friends Otto, Gerd or Rudolf and even from Master Vignelli. Abstraction… how can I represent this concept with the minimum set of visual elements possible and in a way that as many people from anywhere around the world can understand?

That’s the same question we have to ask ourselves every time we design an icon for a Metro app (same applies to Windows and Windows Phone of course).

The goal behind these design style is to illustrate a concept in the most abstract and universal way possible. Think of a taxi cab. Taxi cabs are different all over the world - in some places they are yellow and black, others are red and white, others are black. Some have a tiled texture, others have local ornaments depending on the culture. So creating a icons in 3D, with textures and details could make the icon “too local”. By abstracting those details and leaving only the essence of what a taxi cab is, we are able to communicate more globally. This is inline with the Metro principle, Content, Not Chrome. By reducing details and visual weight from the iconography in the phone we release our user’s eyes to focus more on the content - not the icons. Icons, along with typography, motion, and other UI controls form a sort of thing veil letting the content stand out. Like we’ve said before, this icon style is simply a different style from what we see in iPhone or even Windows XP or Windows 7. This style follows different design principles.

Here are some Metro icons to be used in the App Bar or within your App as UI elements. You will immediately recognize the same design style behind these compared to the work of the designers described above.

Let’s now jump from History Channel to DIY (Do it Yourself) Channel!

Designing icons for Windows Phone

Talking about Windows Phone icons, let’s start by defining the different contexts and scope in which “icons” can exist in Windows Phone:

Branding

- Start Screen Tiles

- Application Tiles

- Splash Screen

- In-App Branding

- Marketplace

User Interface

- App Bar

- Status Bar

- In-App Icons

As you can see from this list, there’s a lot to talk about but I can see a couple big different areas or contexts in which we need to design icons:

1.       Branding of your app (we will cover this in a future post!)

2.       User Interface Icons (below…)

Designing icons for your app is part of defining the identity of your app itself, your brand, your value proposition and even business model. Branding is a whole big area of conversation. It’s also about color, style, value proposition, identity and others aspects. We’ll talk about Branding in a future post.

So in this post I will focus on User Interface icons, meaning we’ll explore the following 3 types of icons:

1.       Status Bar

2.       App bar

3.       In-App (UI) Icons

Status Bar Icons

Let’s start with status bar icons. The key takeaway here is there is no take away J You can’t do anything with status bar icons. They are pre-defined. Unchangeable. Fixed. So perhaps that’s the take away. There is no way to design a custom icon and put it in the status bar. The only thing we can do with the status bar as a whole is hide it while in our app (or show it). The status bar is 32 pixels high so a good tip is not to place any critical UI elements of your app up there so that if the user taps the upper portion of the screen to reveal the status bar, your UI gets obscured. 32 pixels is not a lot so you will usually not have this problem with UI controls but sometimes you want to take precaution depending on how you are incorporating branding or header-like elements up there. You might want to leave a buffer of 32 pixels or even push the branding/header down 32 pixels when the status bar is revealed.

This is a good article that describes every icon in the status bar.

App Bar Icons

Let’s start by killing a myth here. From a purist point of view, those icons we see in the Windows Phone app bar are actually buttons. I’m being a purist here. We tend to think that icons in Metro and Windows Phone need that circle around them. The reality is that the circle is a button control and not part of the icon itself. The icon is just the graphic. So formally speaking these are called App Bar Icon Button. Icon Buttons exist mainly in the app bar but you can also use them within the app space. Learning more about the app bar in general can help you understand better the context in which buttons exist. Jeff Blankenburg’s 31 Days of Windows Phone also has a good article on App Bar.

Icon Buttons in the app bar also use a small text label underneath them. This label is hidden until the user taps the ellipsis to expand the app bar. Theory says the icons should be self-explanatory but a label, which in this case acts like a website tooltip can be useful too.

The Best Metro Icon Design Tutorial - Templarian

The best Metro icon design tutorial out there is from Austin Andrews. This is a must follow designer - Austin shows us how to create an icon following the right dimensions (approximately 26 x 26 pixels for the icon which will be hosted in a 48 x 48 pixels circular button) and the right color (white). Note that we call it approximately 26 x 26 pixels because depending on the proportion of your icon, more vertical like a clip or more horizontal like say, a ruler, you might actually go a bit (2 or 3 pixels) bigger than the 26 either horizontally or vertically. You do not need to create a black version of the icons for the Dark Theme because the system will automatically invert the colors. Austin uses Expression Design for this tutorial. I love Expression Design and it is my number one tool. It’s like a mini Adobe Illustrator but the color picker is so much better because it’s big and always visible.

I really want to highlight Austin’s contributions to the Metro community here. Not only he provided an amazing tutorial but he has created a library of 300+ icons for you to use in your projects! You can even send him a tweet and he’ll create an icon and include in the next release of the library (just make sure the icon doesn’t already exist J).

Our popular friend Kirupa, Flash community God and Expression Blend Program Manager also has a good tutorial on creating Windows Phone icons with Adobe Fireworks. I personally don’t love the ‘k’ in the example (needs more weight) but nevertheless a useful tutorial.

The MSDN Library provides guidance on icon design as well. Here is some key design guidance:

Icon images should be 48 x 48 pixels in size. The foreground graphic for the button should fit in a 26 x 26 area in the center of the image so that it does not overlap the circle.

The circle displayed on each button is drawn by the Application Bar and should not be included in the source image.

Icon images should use a white foreground on a transparent background using an alpha channel. Windows Phone automatically colors the icon according to the theme selection (light or dark), and colored icons can cause this effect to display unpredictably.

Do not create a button that navigates backward in the page stack. All Windows Phones have a dedicated hardware Back button that should be used for backward navigation.

Keep Icon Button labels as short as possible. If the language of the device is English, labels appear on only one line, and are truncated if necessary.

Choose icons that have clear meanings when the phone is rotated. When the phone is in landscape orientation, the Application Bar appears on the side of the screen vertically. The icon buttons are rotated so that they appear upright to the user. It is possible for icon meanings to be confused when this occurs, particularly if two of the icons are mirror images of each other such as << and >>.

One thing to keep in mind here is that these guidelines kind of mix tips for icons and for icon buttons - they are not the same thing but useful anyways.

In-App User Interface Icons

The third way of using icons inside of a Windows Phone app is within the UI itself. I’d say we can classify the use of icons in:

1 - Notifications or Idle Icons

2 - Interactive Objects (usually inside of buttons or list items).

The same design principles reviewed in the previous section apply here except you are not restricted by a 26 x 26 pixel size because since you are stepping outside of the app bar well, size doesn’t matter. Note however that the 26 x 26 guideline is still “recommended” as you will see in the following examples. You can however depending on your design make icons bigger if you wanna push Metro beyond what comes out of the box

Notification or Idle Icons

These are icons that communicate a visual message without being actionable. They are not buttons or other interactive control - they are simply graphics. These icons will usually be floating without any container around them. They can piggy back on some other interactive element to provide this object with context. For example an email will display a clip icon indicating this item has an attachment but the icon itself is not tappable (clickable?) - the email item is.

Interactive Objects

Icons can also exist as part of interactive objects. Here the icons can sit to the sides, top or below an interactive element like a button or a listbox item. Check out Facebook for example which uses the icons people have grown to know well in their website next to their main Panorama menu. Icons could also exist inside of icon buttons. Icon buttons are those little 48 x 48 circular buttons we use in the app bar. Well, we can also use those outside of the app bar and within the app itself. In Metro you will always tend to wrap an icon that is meant to be interactive within a container of some sort to make it “feel clickable”. This is more of a guideline than a rule. I can see how you could create some nice apps using big tappable icons without a container.

One of the things to consider when using icons in your app either as notifications or as part of interactive objects is to make sure you are adapting to the user theme (light or dark) if you app is designed to respect this user choice. If you have decided to make your app not follow the user theme choice, that’s fine, you won’t have to make your icons adapt. If the theme is light then you want to make your icons black. If the theme is dark then the icons should be white. Here are a couple articles that will explain more how to do this (mostly for Developers).

Reacting to Themes to set the right icons…

How to: Change Icon Buttons and Menu Items Dynamically for Windows Phone

Tip: Do not use Tiles inside of apps!  This is a classic. Everyone loves Tiles. I know I do. But we always see folks using Tiles as “tab controls” or simply as “icons”… so you’d have the icon inside a square (like a Tile)… No, let’s not that. Tiles are Tiles, and they are meant to exist “outside of the app context”. That’s precisely their value. So, remember, no tiles inside of apps, even if it’s tempting. Icons are usually used floating nicely without any borders or containers unless they exist within buttons.

Update: Someone named ‘contextfree’ left me a comment on this post with 3 really good things to consider if you do want to use tiles in your app:

- Do the tiles represent “content” that someone might care about? They shouldn’t be used for navigation or tools.

- Is the page with the tiles a kind of sub-Start-screen for the kinds of content your app deals with?

- Can you actually pin the tiles to the Start screen as secondary tiles? (If it doesn’t make sense to implement a pin-to-start feature for your tiles, it probably doesn’t make sense to present them as “tiles” to begin with.)
Here are a bunch of examples with annotations to highlight the type of icons we are using within these apps. Remember there are basically two types of In App Icons: Notifications and Interactive Objects.

Click Image for many more examples of icons in Windows Phone apps…

Tools to create icons for Windows Phone

App bar icons are required in PNG format (with transparency) so they are bitmaps, not vectors. Vector based icons simply don’t work in the app bar control. I received a question in Twitter about whether it was a good or bad idea to represent the user accent color in the icon buttons in the app bar. From a Metro point of view there’ s nothing wrong with changing the color of the icons to something other than white or black (look at Twitter for example). You provide icons in white with transparency (PNG) and then you can specify the foreground color of the App Bar - this foreground color will be applied to your icons magically! You could bind this foreground color to the Phone accent color or even pick a custom color based on your branding (i.e. Twitter app) - thanks @Asmodai42  for the clarification here!

Because of this the tools you will need for creating Windows Phone icons need to produce bitmap graphics which basically any graphic design tool will do. Now, here’s something important: even though the icons are to be saved as PNGs (bitmaps), I strongly recommend you use a vector graphic design tool to create them like Illustrator or Expression Design. Photoshop and Fireworks also support vector paths. The goal is to create your icons in vectors so you can easily scale them without losing quality. Once you are ready export them as PNGs. Creating your icons with vectors is like preserving the source code of an app - you can always go back and make any changes you want.

If you are a developer and don’t have these tools you might want to use Paint .NET (designers will cringe with this ) - it’s all good as long as you can adhere to the specs, guidelines and style we’ve described here.

Resources

Icons are one of those things that are produced by the thousands. We’ve found many free Metro icon libraries and some for sale. Here is a list of some of these libraries and I’m placing a little note on what I think about these. If you know of others please leave me a comment. If you disagree with my review let me know too J

Some of my comments will actually help you I think in getting a better idea of what’s good and what’s bad.

Windows Phone SDK - The SDK includes a number of icons produced by the Windows Phone Design Studio. I believe we have nearly 40 of them. These are great to use in many scenarios and in some cases can be modified. The icons also get automatically exposed in Expression Blend under Common Properties | IconUri Property (check out Kirupa’s tutorial). The physical path for the icons in your PC is: C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Icons

Templarian - Amazing collection - amazing contribution to the community.  @templarian

http://idsgn.org/posts/helveticons/ Let’s start with quality. These are simply to notch and also $279 USD No comments. They are just awesome.

http://www.iconspedia.com/search/windows%20phone%207/ Many good icons but watch out for some that have too much density and when scaled down for app bar usage will not be readable. Do not use icons with so much going on: Example 1 Example 2 Example 3. Another thing with these icons is that they are provided in blue and black. Ideally they be provided only in white. You don’t really need blue. Second thing I notice is these are all provided with a circle. The circle should not exist. Remember the icon is just an icon - a lot of people think Metro icons always need a circle but no, that is never the case. The App bar icon button are circle buttons with an icon inside. Finally the other issue I see is these icons are provided as PNGs which means you will have to edit them to remove the circle and change them to white. It’s not like it’s a lot of work but vector icons would be better (remember, create icons in vectors and save them as PNGs). All this said, showing the icons within a circle does help providing context on how the icons will look.

http://www.iconsforwindows8.com/free-windows-metro-icons/index.htm These are free icons that are good. I noticed a consistent issue when centering the icon in the circle (through remember the circle shouldn’t be there).  If this misalignment is caused by some extra transparent pixels in the icons then that could be a problem when you add these to your app bar. It is better not to use the arrow icons in this collection. The arrows used in this set are not chiseled so formally speaking they are not Metro. You can always check icons against the AIGA collection which is the style we follow in Metro.

http://yankoa.deviantart.com/art/MetroDroid-200340391 I understand these are not really for Windows Phone - don’t get confused using these for Metro. Gradients and shadows, not Metro

http://yankoa.deviantart.com/art/MetroStation-183210118 These are some really good icons. Use these J There is one icon for a CD that when previewed showed like it was using two colors - black and gray but no, it was just black and semitransparent black. That’s perfect! You never wanna use two colors, only one - but you can use transparency. Good job!

http://metro.windowswiki.info/ Good icons. They look so similar to the ones we provide in the SDK that I wonder if they came from there J

http://graphicriver.net/item/metro-icons/1399780 Really good icons - for sale at $8. Provided in multiple formats so you can edit them if needed. While they present the icons in a circle they do so to show them in context of being used in an app bar.

http://msdn.microsoft.com/ja-jp/windowsphone/hh544699 These icons are provided by Microsoft but unfortunately they are not Metro icons. Even the icons shown there with a single “gray” color seem to come simply from changing colors in one of the full colored icons and not optimized to work well on small icon buttons in the app bar. Do not use these icons for app bar buttons or for in-app Metro UIs. These graphics are great for games but not Metro apps.

Icons and Localization

Turns out that text is not the only thing we need to localize. In many cases icons or graphics can have different meanings in different locales. Some interpretations of icons can end up being pretty rude! J So here are some tips for you to consider when choosing icons for apps that will be used in multiple countries and cultures.

Question for you: During the Windows Phone Design Day tour I heard at least a couple different comments from people saying that X or Y icon meant something different in China, India or Norway… do you guys have examples of these type of icons that you know have a different meaning (perhaps a bad one) in other countries? Drop me a comment here please J

Icons using fingers such as an OK sign or V-sign may mean different things to different cultures. Our Western symbols do not always mean the same abroad. An oft cited example is the representation of the house referring to a home page, or a letterbox to mail. The use of animals in logos can cause embarrassment and further problems. For example, pigs are considered unclean in the Middle East and cows as holy in India.

Avoid single-letter concepts, as confusion will be introduced through translation

Avoid graphic elements with text

Avoid graphics depicting human body elements and body language

Avoid graphics depicting humor, puns, and slang

Avoid graphics depicting physical environments

Avoid graphics depicting ethnic, racial, political, and religious environments

Avoid graphics depicting gender-specific elements

Avoid graphics depicting images of animals

Avoid graphics depicting sexual and violent elements

Avoid graphics depicting regional conventions, such as reading direction, date/time, and monetary elements

Avoid text and numbers in icons and images because they require localization.

Source

This is a good paper with more details on localizing images, considering cultural aspects and visual metaphors.

In this post we’ll try to answer a very common question that developers and designers ask us all the time and that in fact we in the Studio try to define always when exploring new features in Windows Phone: Should we use a Panorama? Or a Pivot? Or a Page?

First I will start by saying that it is not Panorama OR Pivot OR Page. It is more like Panorama(s) and/or Pivot(s) and/or Page(s).

When I first started working on Windows Phone I had a wrong perception.  I’ve found this wrong perception also in many other developers and designers throughout these months. The perception many times is that you have to choose one out of these three screen types for your application. False. Windows Phone apps are made out of a collection of screens of different types that are interconnected. So Windows Phone apps are made out of a number of Panoramas, Pivots and Pages. It’s not OR, it’s AND/OR.  In Expression Blend and Visual Studio you can create a new Windows Phone project with a Panorama or a Pivot but it’s just the starting point - from there you can add a number of Panoramas, Pivots or Pages.

Could you have apps that needed only one single Panorama? Sure (i.e People Hub although it has so many connections to other parts of the phone like contacts list, settings etc - that’s it doesn’t feel like a “one panorama” app).

How about a single Pivot? Yes (i.e. Twitter app - kind of, although even that one has orbiting pages around the main Pivot).

How about apps made out of a single Page? Yes. But it is not common.

The large majority of apps are made out of a healthy mix of many screens of different types, Panoramas, Pivots and Pages.

Defining what types of screens to use depends on the Information Architecture (IA) of your app. We will get deeper into IA in the next couple posts so for now let’s try to define a series of guidelines (or rules when possible) to know when to choose one screen type versus the others.

During the tour last Fall I came up with the following statement that I think exemplifies the current ‘state of the union’ in the Windows Phone Marketplace:

“Panoramas are overused, Pivots are misused, Pages are underused.”

As we mentioned before, the choice of using Panoramas, Pivots or Pages is directly influenced by the IA in your app. Here is a quick guide to pick Panorama, Pivot or Page depending on your information needs:

Panoramas are for content consumption.

Pivots are mostly for content consumption and in some cases for content input.

Pages are for one dimensional (one view) content consumption scenarios (whether lists or video, audio, images/photos…), great for content input and great for content generation.

Panoramas

“Panoramas are like Magazine Covers. They expose only a few top pieces of content.”

Panoramas are gorgeous! Why wouldn’t we use them? Every Windows Phone app needs at least one or more Panoramas! - Wrong. Panoramas are gorgeous yes, they leverage the Light, Clean, Open, Fast Metro Design Principle. They are designed to make the user feel like they are dealing with content that spans beyond the physical borders of the phone itself! - content peaking communicates continuity in a beautiful way tempting the user to swipe to the left or right and discover more content. The parallax animation effect where the background of the Panorama moves a bit slower than the content floating on top of it (basic animation principle to convey depth used since early animation studios) makes panorama an immersive adventure.

Panoramas rock, and because they are awesome we tend to overuse them.

Here are some guidelines for when to use and when not to use Panoramas:

Panorama(s) are the “Magazine Cover(s)” of your app. They display only the top or featured content for users. They expose a sneak peak. Not all the content - just those top headers and articles. It’s just a sample of the goodness of your app - not your whole app! Panoramas display a summary of the functions and content available in your app. Literally think of them as magazine covers. To design Panoramas, think of them as full spreads of content, not as single Pages but as a whole large spread. It’s fun to design. Want to get inspired to design Panoramas? Explore some popular and well design magazine covers:

Windows Phone apps do not always require of a Panorama. There are apps that use no Panoramas and that’s just fine.

Panoramas can’t hold large amounts of data. For performance and experience reasons do not use Panoramas if you have the need to present a large amount of content for users. How much is too much? In general stay within 3 to 5 Panorama panels. Use ListBoxes that use a maximum of 15-20 items. Panoramas are not virtualized (memory managed) so think of them almost as big flat images than dynamic content controls (like Pivots). Again, they are more of Magazine Covers - beautiful and immersive.

Panoramas are not best friends with ‘draggable’ controls or objects. Sliders or other controls that have a draggable function can interfere with the swipe gesture in a Panorama. If you require of input controls that are draggable it is better to pop out a Page, have the user make input there and then return them to the Panorama.

Leave Panoramas for the end of your design process. What?! Yes! J I realized that Panoramas are better designed and more easily laid out when you leave them to the end. This is contrary to what I did initially and what I’ve seen most people do. It’s even contrary to what Visual Studio promotes but trust me, leave Panoramas to the end. Panoramas expose only the top/featured/most recent pieces of content of your app - but you cannot define what top/feature/recent content to display in your Panorama until you have not nailed down the full extent of your IA and the rest of your app including Pivots and Pages. Creating a Panorama once the IA and flow of your app have been defined (including Pivots and Pages) is the way to go and makes your Panoramas more streamlined, better designed and more efficient. You can certainly decide or define you will need one or more Panoramas early enough in the process - go ahead and include them in your application flow - but do not go ahead and design them just yet.

Pivots

“Pivots are data friendly. You have large lists of information to present to the user? Use Pivots, not Panoramas.”

Pivots tend to be misused. These are powerful, horse power controls that have the ability to present and handle large amounts of data. They are virtualized so their performance is much better and optimized for handling large amounts of data compared to Panoramas. Pivots are best friends with ListBoxes (or ListView) controls. Many times we see us trying to use Panoramas (because of their cool, immersive value proposition) when we should be using Pivots.

Pivots help you present lists with information from the same data source but sorted out in different ways. Pivots have Pivot Items. Each of these Pivots Items can present information from the same database but sorted out in different ways. For example in these two cases we have two different Pivots. The first one shows golf courses presented in three different Pivot Items, one shows Recent golf courses, next shows nearby golf courses, the third one shows all gold courses available. So, all are golf courses but we present them in 3 different ways. Also notice that we present information from the same database in completely different ways. Notice how nearby courses use a map and highlight data related to location, where recent shows a list in chronological order and displays the date when we last played in that golf course.

Pivots are not best friends with ‘draggable’ controls or objects. Sliders or other controls that have a draggable function can interfere with the swipe gesture in a Pivot. If you require of input controls that are draggable it is better to pop out a Page, have the user make input there and then return them to the Pivot.

List view design is fundamental for a great Pivot experience.

Pivots can also be used for displaying completely unrelated information between its different Pivot items. For example Settings. Think of this metaphor as application tabs.

Pages

“Pages are best for content input and content generation. ”

Pages sound kind of boring - no parallax effect like in Panoramas, not immersive, not feeling like they span beyond the screen borders - just a plain good old static screen. This perception is what drives many of us not to use Pages enough and instead force functionality into Pivots and Panoramas even when these are not needed.

iPhone and Android apps are naturally driven by single static pages. It is the task of the developers/designers to create immersive experiences within these page boundaries. In Windows Phone, with Pivot and Panorama as strong and exciting UI metaphors, it is easy to forget that Pages, like in iPhone and Android, are still super important and can help us solve many scenarios.

Pivots and Panoramas are great for content consumption. Pages are best for content input and content generation.

Pages are the best for receiving input from users. Think of a calculator (multiple buttons), forms that users will fill out with information and other heavy input scenarios. Perhaps configuration or settings and other scenarios with a number of input controls like sliders, text boxes, checkboxes, radio buttons.

Pages are great for content generation. Think of note taking apps, drawing or sketching, chat or communication apps and games as well.

If you only need to present a set of data without multiple views use a Page. If you need multiple views, a Pivot might work much better, or a Page linking to other Pages.

Pages are great for showing details of a previously selected item in a list or another object in a Panorama or Pivot.

Pages are like pawns in chess, there are many of them, they are usually not the star the show but, they are essential for an app to function.

Next Post | #6 Translating Information Architecture into a Windows Phone Application FlowNow that we have learned more about application flow and choosing the right screens, Panoramas, Pivots and Pages for our apps, we are ready to get deeper into Information Architecture. In the next post we’ll learn more about IA and how we can translate it to Windows Phone Design paradigms.

Introduction

Today we begin our preparation to get ourselves ready to define the Information Architecture (IA) for our app. We will discuss Information Architecture more in depth in a future (not too far away post) but first I want to touch on a couple concepts that I think are critical for us to be able to visualize in our mind how a Windows Phone app is structured. With this knowledge in mind plus the IA for your app we should be in a good place to move forward in the design process. The first concept I want to talk about is Hub & Spoke Navigation Model and the second one is Choosing Between Pivots, Panoramas and Pages. This week we will cover Hub & Spoke and next week we’ll go into the choosing the right screen patterns for your apps.

The Hub & Spoke navigation model or “distribution paradigm” is not exclusive to Windows Phone. It is a widely known model used on website navigation and structure as well as in other digital interaction mediums. The Hub & Spoke model is particularly popular outside the digital realm and widely used in transportation, telecommunications and urban design. One of the best examples are airline route maps.

Wikipedia defines the Hub & Spoke Distribution Paradigm as “a system of connections arranged like a chariot wheel, in which all traffic moves along spokes connected to the hub at the center.”

While working on this post I came across Paul Laberge’s Going with the Flow… Using Metro to Control the Experience article and I must say he covers almost everything I wanted to cover here . Paul does a great job of highlighting the top concepts related to Hub & Spoke navigation in Windows Phone. To avoid duplication I will refer you to his article and instead will spend some more time here covering examples and other in depth guidance on Hub & Spoke. Make sure you read Paul’s article.

The reason Hub & Spoke is important in Windows Phone is because it helps you define the flow of the application, or the flow of the experience as Paul describes. When working on a Windows Phone app the flow is the first thing to nail down - not the visual design.

The Hub & Spoke navigation model is ideal for small digital devices, like phones, where screen resolution is limited and small but where content is still a lot to deal with. Here is a typical side to side scenario between Windows Phone Hub & Spoke and iPhone/Android non-hub and spoke models.

The Backstack

A fundamental concept in the Hub & Spoke model in Windows Phone is the “Backstack”. The best way to describe it is with breadcrumbs. As in Hansel & Gretel breadcrumbs J Once upon a time Hansel & Gretel where navigating happily through a dark dark Windows phone app (with black background). Every time they went to a new screen they’d drop a breadcrumb there so they knew the list of screens they’ve been to. They went on and on until they found a little house where an old lady invited them in offering ice cream sandwiches and apples. Luckily in this version of the story Hansel & Gretel were smarter and they decided to go back home. The list of breadcrumbs they dropped helped them return back where they came from.

In a nutshell, in Windows Phone the user taps objects, buttons, list items, icon buttons in the app bar or other user interface controls to move forward in the app structure. Basically, the user moves forward by making decisions.

The user moves backward in the app structure by using the back button… the user moves backwards by instinct and memory. The back button is used “blindly” by the user and the user learns to trust the back button. From this point of view the breadcrumbs analogy actually works only for the developer of the app. The user doesn’t have a visual map that tells her where she is going to - she just knows she is going back where she came from.

This is the reason why handling the Backstack correctly is so important, because the user will use the back button with only her memory as a guide. It is also the reason why starting to define the right app structure early in the design process is fundamental for the long term success of the project.

Removing Steps in the Backstack

Sacrilege!? No, not really… in fact, you as the developer or designer are responsible for removing steps from the backstack if needed and whenever it makes sense. I was first introduced to this concept by Corrina during the Windows Phone Design Day tour last Fall. In her REFINE session she provides some really good example of when it makes to remove steps in the backstack.  At first I would have though the backstack is untouchable since we want to respect a user’s path but there are different scenarios when it is convenient to remove items from it. In this example Corrina explains that it obviously doesn’t make sense to have users return to the credit and billing screens once the purchase transaction has been completed. Instead when pressing the back button on the last screen the app would take the users back to the wish list.

In this other example we can see an opposite scenario where removing search and results from the backstack could cause confusion for the user. The user is in a wish list, searches for products, finds some products and adds one to the wishlist. From this last screen it makes sense to send the user to the search results screen (the previous one) since she might be interested in adding more items from the same results instead of going all the way back to the wishlist and having to perform perhaps the same search again. So you can see how in different scenarios, it makes sense or not to remove screens from the backstack.

Here are some additional tips that Corrina shared with us during the tour:

“Remember, back means back; not forward, not sideways, but back.”

“Ensure application state is persisted appropriately.” 

“Ensure transient interface elements do not appear in the back stack.”

Diagraming the Hub & Spoke Navigation Model for your App

Here are a couple methods to diagram the flow of your app and how the Hub & Spoke model will get to manifest in it. Please note these are techniques for illustrating diagrams and not methods for defining your app flow. Your application flow can only be defined later in the design process when you start exploring and maturing the Information Architecture.

Abbreviated Nomenclature

This method is quick. It’s great when quickly wanting to convey an idea of flow to your peers - other designers or engineers. You can use this by sketching it with pen or pencil or using some of the visual assets in this Expression Design file or Adobe Illustrator file. It consists of drawing circles with abbreviations as follow:

Start - Windows Phone Start Screen

Pv - Pivot

Pa - Panorama

Pg - Page

Visual Nomenclature

This is a more detailed nomenclature that allows you to convey visually the key elements or screens in your application flow. I’ve created some Expression Design and Illustrator templates for this nomenclature if you want to use it with your favorite visual design tool. You can also sketch this out. Here is a way I do it that uses just a few strokes making it as easy and quick as possible.

Learn More about Hub & Spoke Navigation Model in User Interfaces

This is Paul Laberge’s article on Hub & Spoke model in Windows Phone. Also, here is the Navigation section in the Windows Phone UX Guidelines which describe Hub & Spoke in more detail as well as explains some other concepts like Tombstoning.

A good way to understand Hub & Spoke is to explore alternative navigation and information architecture models. Also, Tombstoning is an important component of the Hub & Spoke navigation model as it allows application to persist their state even when users have moved beyond our outside of it. Escaping Navigation Hell by Like W is a great article that describes specific techniques to craft experiences where content is a lot and complex - while this usually drives for an also complex navigation mechanism, Luke provides shares some tips to tackle down navigation (or not to at all! J).

Finally if here is the obvious Wikipedia page for Hub & Spoke as well as the Infragistics Quice Design Pattern page for Hub & Spoke (worth studying for other common navigation design patterns).

Next Post | #5 Choosing Between Panoramas, Pivots or Pages

In our next post we will review the criteria to decide when to use Panoramas, or Pivots or Pages. We’ll demystify the use of some of these screen patterns.

In the previous post, The Design Process of a Windows Phone App, we discussed the importance of defining a theme for your Windows Phone application. The ideation stage helps you refine your theme and generate ideas to help enhance the user experience around that theme. We talked about the value of selecting a user experience as a theme, like dining, running or sailing instead of thinking of apps in terms of APIs or RSS Feeds available out there.

The Ideation and Concept stage is quite fun and it is best played with other people! - There are 3 key stages in the Ideation & Concept phase: 1) Brainstorming 2) Exploration and 3) Consolidation. In a nutshell during the Brainstorming stage you generate tons of ideas, during the Exploration stage you dissect and study many of those ideas (but not all) and in the Consolidation stage you decide which ideas will move forward to become part of your Windows Phone app. Only a few of them make it through alive.

Brainstorming

Brainstorming is usually the first stage when designing a Windows Phone App (or designing anything for that matter). This stage is all about freedom of thought. It’s about coming up with tons of ideas, even if some are crazier than others. It’s about thinking outside of the box to come up with innovative solutions.

The best tools for Brainstorming are storytelling and tons of multicolor sticky notes although sketching and moodboards help too. To begin with, this article has 10 really good tips for effective brainstorming.

In general you would use brainstorming to define two things: 1) the general idea for your app and then later 2) the features for your app.

Brainstorming can help you come up with cool ideas for Windows Phone apps that provide unique value to the user and that differentiate from other apps in the Marketplace. Once you have defined the general goal of your app, then Brainstorming can help you generate and explore specific ideas (features) for your app.

First, you will need a theme or general (broad) user scenario(s) to address. One of the typical things we see here is the almost instinctive approach of “creating an app just because there’s an API or web service available out there”. So we end up with dozens of Yelp!, Twitter or Foursquare clients. While there’s nothing wrong attempting to create the best client for any of these services, the real opportunity to innovate is found by thinking in terms of user experiences and not APIs or Web Services. So, instead of saying “I will create an app based on the Yelp! API“, say: “I will create an app to aid the user in the dining experience“. Decide what user experience you want your app to be a part of, based on your business area, your personal preference, your hobby, or something you hear people really want. You will find that most successful Twitter (Seesmic) or Foursquare (4^th and Mayor) clients are the ones that think beyond the API.

Another common approach we see at this stage is some people condition themselves from the very beginning. For example they begin the Ideation stage knowing for sure they will create an app “to check the price of stocks“. So we end up with yet another stock trading app, or another RSS Feed reading app. The key to come up with good and original ideas for apps is to think of a user experiences. So instead of thinking “I will create a stock portfolio app” think “I will explore how to help the user in the experience of stock trading” - ah! Much broader, gives you more room to come up with ways to contribute to the experience.

A great brainstorming technique to accomplish this type of approach to generating ideas for Windows Phone apps is Subjects + Objects + Verbs. I remember we put this one together back in Architecture school and it was fun! Last year we started using it for UX design as well.

Subject + Objects + Verbs

We hosted this group brainstorming technique during the Windows Phone Design Day tour. It consists of having a group of people write a bunch of Subjects, Verbs and Objects related to a user experience and then choose some of those words to put together a new scenario. This exercise ignites creativity because it forces you to come up with solutions for scenarios based on words you didn’t write yourself - scenarios you would have never come up with yourself if it had not been for the collective consciousness of the group.

• Get some multicolored sticky notes and markers. Preferably all the markers have the same tip width and the same color (black). Sharpies work great.
• Get 3 different colored sticky notes and write the word Subjects in the first one, Objects on the second one and Verbs on the third one.
• Paste these 3 sticky notes on a big wall.
• By now you should have defined a theme for your Windows Phone app - remember to think of user experiences like dining, sailing or working out (no specific solution at this time). We’ll be using dining (eating at a restaurant) in this example.
• Ask participants to write one Object, one Verb and one Subject related to the activity or experience of “dining”. One word for each, on separate sticky notes and to paste them below the header sticky notes you initially created.
• This will fill up the wall with a bunch of Subjects, Verbs and Objects related to the experience of dining (or any other theme you and your team chose like running, sailing…)

• Next step is to divide the group into smaller teams of 2 or 3 people (or 1 if few team members) and ask them to select 3 words they like as a team: One subject, one verb and one object. Encourage them to select words that trigger ideas or imagination for user scenarios. Some teams struggle with agreeing in which words to pick. A tip here is for each team member to select one word so they end up with one subject, one verb and one object. In reality you could assign random words to each team - this will force them to think outside the box and come up with unique app user scenarios to solve.
• Once teams have selected their 3 words, they are ready to start generating ideas about how to solve or address the scenario that magically appears by selecting a random subject, verb an object. For example:
  • Vegetarian Girlfriend + Yell + Double Cheese hamburger
  • Children + Play + Food
  • Chef + Cook + Tomatoes
  • Grandparent + Propose + Check
  • Lady Gaga + Meet + Dishes
• Participants then have to come up with scenarios that are inspired in those 3 words, for example, Gaga + Meet + Dishes… we know we won’t design a Windows Phone app specifically for Lady Gaga right? J and unless we are huge fans we won’t create an app focused on Lady Gaga alone but what if we translate Gaga to a broader concept like “Famous Personality”. So, Famous Personality Meets Dishes. What if we created an app to track personalities who attend different places for lunch or dinner? There could be maps and personalities and when users spot someone famous, they tag that person. I’m not talking about a paparazzi app J but just an app that would give users an idea of how possible it might be for they run into their favorite actress or hip hop rapper if they go to X or Y place for dinner or lunch. Hook that up to Foursquare and Yelp and you have some good APIs to support your user experience. Just an idea. It is important to encourage participants to feel free not to take the words literally but to extrapolate to whatever makes sense like in the case of Gaga which we elevated to Famous Personality or the verb “Yell” which could be broadened to “being upset in general” or “having a problem”. This idea of spotting personalities in restaurants is something I would have never come up with myself if it had not been for those words some other people in my group wrote down on those sticky notes.

Here’s another example with three words that really called my attention: Kids + Play + Food. I would have never come up with that scenario myself - I don’t have kids but thanks to 3 different people who wrote those words I now I have a scenario to work on. Kids playing with food in a restaurant can be a real problem. How could we help solve this scenario?

This is where some techniques described in Gamestorming can be helpful. Here is one example with the Impossible Scenario Brainstorming technique. Remember these are games so if you take it too seriously you won’t get far J no need to start thinking of how you will build the app or what backend server architecture you’ll need. Just have fun. In future stages you’ll have enough time to prioritize, explore technical feasibility and be picky with ideas. Right now just play this game with your team.

Impossible Scenario for Kids + Play + Food

A mother and father might have 2 or 3 kids that play with food and that’s a problem but an impossible scenario would be the same couple having 100 children! Impossible right? (I guess…) what would you do as a parent of one hundred children that play with food when taking them to a restaurant? Sounds like a nightmare - you’d have to know all their names, their preferences, who they hang out with, are some of the vegetarian, their age groups? Who are the most well behaved and the worst? Etc. As a caring parent of a 100 kids you’d know these things J that’s the impossible scenario. Now bring it back to reality: while it’s not really possible for a parent to take her/his 100 kids to a restaurant, it is indeed possible to have a 100 children (from different parents J) in a single restaurant or other public facilities like a museum - ask McDonalds or Chucky Cheese! Now translate all your “learning experiences” as a parent of one hundred kids and leverage those as the restaurant manager or the restaurant itself. How would a restaurant help these one hundred kids (or their parents) not play with food and make a mess out of the place? What if the app sponsors social activities while at restaurants, a sort of mini social media for parents to meet and get children to play activities together or simply for children to learn about other children’s cultures based on the other children who have checked in?

Another technique to test your Object + Verb + Subject is Alternate World, where you’d say something like, what if the restaurant was on the moon? What would happen to a meat ball being thrown by a kid? I can see the meatball floating across the restaurant hitting a grumpy old man on the other side! This gave me an idea… What if your app becomes an actual game where children can make all the mess they want? With actual food from that particular restaurant? J Like throwing little Big Macs or McNuggets. If we have Fruit Ninja why not Messy Food. It kinda makes me thing of Angry Birds meets Fruit Ninja meets Cooking Mama.

One more technique is In Other’s Shoes. Here you have to pretend you are someone or something in the dining experience. Sure, you can act as the waiter and discover the dining experience from his/her point of view. This will help you open your mind to scenarios you would have otherwise not thought of. Allowing you and your team to think from a completely different point of view. Now, instead of being a person, think you are… I don’t know, the spaghetti plate J think of how you got to the restaurant, the ingredients that made you who you are, how you were cooked, served, eaten. This will also expose you to the dining experience from a point of view that you would have otherwise not thought of before. Does this mean we will create an app for spaghetti plates? Not necessarily… but having explored the lifecycle of spaghetti will have taught you more about what happens behind the counter, back in the kitchen, with inventories or storage in the restaurant and I’m sure that’d open new ideas for apps.

Very different approach from thinking first of the availability of an API out there right? APIs, Web Services, and all those goodies should just be tools to help your app contribute to making a user experience better.

There are some great brainstorming books out there like Gamestorming and Thinkertoys. These tend to be more focused on brainstorming techniques for marketing/business groups (in my opinion) but you can adapt some of those techniques for design groups too.

Play these activities (that’s the word - play) with your teammates or with friends and family if you are an independent developer. These are games to come up with ideas. You can’t be too serious at this stage. Things will get serious on the next few stages.

Pecha Kucha

At the end you can present your ideas to your team (or some friends) using the Pecha Kucha (Chit Chat in Japanese) presentation model where you have 20 slides and 20 seconds per slide to present a summary of your ideas. This model is great as it will force you to remove garbage and noise and leave the best ideas. It will also force you to “start” bringing those crazy ideas down to earth.

Exploration

In this stage you and your team Explore the feasibility (Business), desirability (Experience) and viability (Technology) of the ideas you came up with during the Brainstorming stage. I will focus on Experience in this post as I’m sure if you are a developer or a product/marketing manager reading this post you will know much more than I do on how to explore the technical viability of ideas.

When it comes to Experience, the goal is to take some of the ideas generated during Brainstorming and dissect, stretch and test them. You can do this with some of the following tools:

Sketching

Storyboarding

Paper Prototyping

Storytelling

As mentioned previously, design is not a one shot activity - not a “one try” type of activity. Design is a process where we take shapeless blobs of concepts and ideas and we start working them out, exploring them and treating them as clay. Little by little we get to know these ideas better to the point where it all starts taking shape. Sketching, Storyboarding, Prototyping (focusing on Paper Prototyping in this Ideation stage) and Storytelling are any creative person’s tools that allow for idea exploration.

“Every block of stone has a statue inside it and it is the task of the sculptor to discover it.” - Michaelangelo

Sketching & Storyboarding

The boxing glove technique illustrates precisely what sketching is all about, particularly during this exploration stage.  You do not need to become an artist to convey ideas with sketches. In fact during early sketching phases it works even better to be more abstract and generic with your strokes. That’s what a boxing glove (or better yet, a thick pencil or marker) will help you accomplish. Try the following exercise: get a black marker (like a Sharpie) and a sticky note (one of the little ones) and try to sketch a full Windows Phone panorama in there. The paper size and stroke thickness will immediately restrict you from adding detail and that’s what sketches should be, general non-detailed manifestations of your ideas.

Sketching: the Visual Thinking Power Tool by Mike Rohde is a terrific post about sketching with many great links and resources. The Messy Art Of UX Sketching by Peiter Buick is a must-read UI sketching post with lots of practical techniques.

This is a great series on sketching tips by Anders Toxboe

User interface sketching tip 1: Drawing rectangles and corners

User interface sketching tip 2: Drop shadow

User interface sketching tip 3: Use a thick pen

User interface sketching tip 4: Get your arm off the paper

User interface sketching tip 5: Constrain yourself

Finally, these are 50 sketching resources for user experience designers - There are some nice articles, videos and presentations there for those of you who want to go deeper into sketching.

Paper Prototyping

Paper Prototyping means literally using paper to build an “interactive” (or more like a guided I’d say) interactive experience. You can produce a paper prototype by sketching on paper. For Windows Phone apps you could sketch it all in rectangular shaped paper. I personally enjoyed sketching Panoramas, Pivots and Pages using 3″x 5″ sticky notes. They are cool because you can stick some next to each other and layout Panoramas with 4 to 6 panels, or Pivots with 3 to 6 items. If you are doing user testing with your prototypes then you might want to formalize the presentation a bit more and sketch in letter size page. How do you make objects interactive? Well, you literally sketch-out the different screens or UI modules that would be displayed or change when the user “interacts” with them. In this guided prototype you would aid the user by pasting, removing, changing parts of the paper prototype depending on what the user wants to do. This is a great way to start testing concepts early enough and it’s cheap not because it’s paper but because in one 15-60 minutes you can put together a good paper prototype vs investing hours, days or weeks building something interactive. Remember at this point we are still in Ideation technique and we are still giving shape to the “shapeless blob of ideas”.

Another way to do paper prototyping is something I learned from Jared Potter, a Sr. Design Integrator in the Studio. He sketches Panoramas, Pivots, Pages and then takes a picture of them with his phone. He then emails those photos to himself and imports them all into Expression Blend (you could also use Powerpoint…). In Expression Blend he then creates buttons on top of his sketches, over areas where he drew interactive elements like Push Buttons, App Bar buttons, List items. He then uses Behaviors to enable the buttons to take him to other screens (other sketches). In 15 minutes he has a full paper prototype (interactive) working in Blend and he is ready to start testing some of his ideas. This is a sort of hybrid paper-digital prototyping technique but is just as cheap (considering you have Blend, Powerpoint or similar J).

Paper Prototyping by Shawn Medero is a great read with theory and practical tips. Paper Wireframing is also another good read. Notice in this case, the author explain a technique that uses pre-created wireframe-like UI elements. They print these out and then they compose UIs. It is still paper prototyping although they do not sketch things out with pen/pencil - instead they use these pre-created UI controls and patterns. Should I create some of these UI control stencils for Windows Phone? J Ok, will do.

These are 3 great articles about paper prototyping theory - not many practical tips but good reads to understand the value of doing low fidelity prototyping.

Paper Prototypes: Still Our Favorite

Looking Back on 16 Years of Paper Prototyping

Using Paper Prototypes to Manage Risk

Storytelling

Some people (including myself) would argue this is the most important of the tools for ideation. Storytelling is indeed fundamental for the whole UX design process. Storytelling allows you to convey scenarios and describe users, problems and solutions in a way that makes sense, that engages people and helps them immerse into a future world where you app exists. Not only it helps you and your teammates and clients understand your vision for an app but it helps in digging deeper into the app and making it more interesting. Good storytelling is also what makes your app sell… selling it investors, to teammates, clients and users. Flat story telling will yield flat apps. Structured and engaging storytelling usually renders in apps that are unique.

A good way to explain the value of storytelling in user experience design is with words:

“Storytelling traditionally begins with a “Once upon a time…” opening, and then a storyteller’s silent pause to gather his thoughts. The traditional openings, of which there are many (often with responses from the audience), were “rituals” that served as a signal that the teller was suspending “time and space” as we know it and transporting the audience to a world of imagination and play.” - Barry McWilliams

“As experiences now span multiple media, channels & formats, we need to look to narrative, interaction, emotional elements to sustain transitions across channels and formats” - Joe Lamantia, Beyond Findability Workshop at IA Summit 09

“To create a truly memorable and satisfying experience, a UX designer needs to understand how to create a logical and viable structure for the experiences and needs to understand the elements that are important to creating an emotional connection with the product users.” - Cindy Chastain

“If emotion and meaning can emerge from the harmonizing of elements that make up a story, then to design for optimal experiences we need a story by which to harmonize the elements of a product, service or system.“ - Cindy Chastain

Storytelling is the foundation for every other way of communicating User Experience and User Interface ideas. Stories can be told with your voice, sketches, storyboards, moodboards and/or videos.

Telling User Experience stories is not too different from writing movie scripts or novels. Similar elements of storytelling exist for developers and designers to craft engaging and revealing details about user experiences. Common elements of storytelling are: Theme, World , Character(s) , Props (Objects),  Story(ies)(Plot).

Theme is the one sentence that describes everything. Your foundation. Your mantra. The phrase you and your team will live by. Every scenario, feature, decision, you take about your app needs to pass the Theme filter - the Theme validation. World is the setting, the landscape, the room, the street or in the case of digital experiences it’s also screens (of different sizes), or platforms like phones, tablets or even Facebook, where these digital experiences occur. Characters are the Subjects or (personas) or other beings that participate in the experience.

Props (Objects) are physical or digital assets that complement the user(s) in their experience. Stories define Actions are the relations between Subjects and Objects.

In addition to the elements of a story, the structure is also important. You will find different story formats have somewhat different structures. A basic story structure consists of: Setup, Confrontation and Resolution. So, when defining and telling a user experience story, begin by laying out the users and their context. You can then establish their problem or goal and finally explain how this scenario is solved with the use of your app. The biggest risk of stories is for them to be flat - instead, tell stories that have spikes of revelations and aha moments, perhaps everything seems lost and then your feature solves it all.

You can express user experience stories by writing them down and by using some sort of visual media like sketches in storyboards and/or moodboards. Also note that storytelling in User Experience design is multidimensional meaning there are different levels of the experience for which you can write a story. First you might want to write the top level app end-to-end story. Then you might want to write a story to describe the top feature buckets. Finally you could write stories for specific features.

A really valuable technique I learned while doing marketing is to write mini-stories called elevator pitches which is basically being able to convey a story in 30 seconds or less. If you cannot describe your app, your core feature area or a specific feature in less than 30 seconds then chances are you have not yet got a hold of the scenario or feature and you need more time to explore it.

“If you can’t tell your app or specific feature story in 140 characters, chances are you need to do more exploration before continuing with the process.”

An even more effective technique I’ve been using lately is to describe your app, your core feature area or specific feature in today’s world elevator pitch standards: Facebook status and Tweet. So try writing a mini story (really nano-story J) for the 420 character limit for Facebook status and then a 140 character mini story for Twitter. If you cannot express your app or feature with these limited set of characters then just as previously mentioned, chances are you might not have yet nailed down the user experience thus more exploration is required. When teams have a conflict agreeing on a Tweet long story that describes their app or features of their app then it’s good to go back and talk more about the app or feature looking for the key elements it is contributing to the user experience.

Here are some good descriptions I’ve found in the Windows Phone Marketplace:

CocktailFlow

Tweet Browse, find and discover cocktails with a continuously growing collection of drinks.

Facebook Browse, find and discover cocktails with a continuously growing collection of drinks. The application features beautifully presented recipes and identifies cocktails that can be made from ingredients in your bar. It also gives suggestions on what ingredients to buy next to make additional delicious cocktails.

Seesmic

Tweet Seesmic lets you update and view multiple social networks in an efficient and powerful application.

Facebook Seesmic lets you update and view multiple social networks in an efficient and powerful application. Manage multiple Twitter accounts, your Facebook account, your Salesforce Chatter account and organize all your accounts, searches, trending topics and lists in your customizable “spaces” dashboard.

Experience Themes: An Element of Story Applied to Design was a terrific session presented by Cyndi Chastain at the IA Summit 2009 in Memphis. She talks about storytelling for user experience designers and developers. Better Writing Through Design by Brownwyn Jones is a good post that provide practical tips to better write user experience stories. Using Stories for a Better User Experience by Whitney Quesenbery explains the use of personas for writing stories as well as ideas to capture stories directly from users during testing sessions. Here is the Whitney’s presentation with notes and slides. Not directly related to user experience design but I thought this article on Conflict and Character within Story Structure was very helpful for me to understand the basic structure of stories - structure which can easily be translated to user experience storytelling.

A Note of Caution with… Babies

During the Exploration stage you will unavoidably face conflicts of interest and people will fall in love with ideas. Ideas are like babies, and babies can be so cute that you don’t want to let them go even when they turn out to be evil. So learn how to cut the cord and let ideas go if they prove (and that’s a key word here… prove) that they are not worth pursuing. At the same time, embracing some ideas and defending them whatever it takes is just as important. Without a strong sponsor in the team, a great idea might fall off the tracks and get lost forever. What we want to find throughout our Exploration is “evidence that proves” that this idea is worth pursuing or that it is not. In the process, the idea will mature and by the end you will have learned a lot about it. Notice it’s not the time to make this idea mature 100% but to get a feel for how feasible it is. I just read a tweet from a quote from Ed Catmull, President of Pixar: “The culture of Pixar is to protect an unformed idea“.

Consolidation

Where Brainstorming is all about freedom, Consolidation is all about taking decisions, about getting clarity and about reaching consensus between different points of view in the team. At this point the team will have explored and learned a bunch of ideas in detail. It will be easier for the team to take decisions on which of the ideas to further develop and take into the next stages. A good technique at this point is to use red and green dots or any other forced ranking technique. What we want to achieve here is remove ambiguity and have a clearly prioritized list of scenarios so that we can cut out the ideas that just don’t have technical, business and experience potential.

A forced ranking technique would be to give people $100 (fictitious J) and ask them to put as many dollars as they want next to the idea/scenario they believe should be brought forward and developed as part of the Windows Phone app. This will give people a budget and by doing so will make people think well where to invest their “money”. Some people might choose to split their voting investment in 5 parts - $20 each. Others will feel really strong about a particular idea and will put $45 on it and the rest split on other ideas. Some might split their investment in a 100 parts! But of course their “decision and influence power” will be greatly diminished.

At the end, depending on the results, define a benchmark and cut out all ideas below that benchmark. All the others become a prioritized list of scenarios for your app which will be further explored to turn them into features. Done!

Next Post | #4 Hub & Spoke Navigation Model

In the next post we will explore the hub and spoke navigation model which is the basis for structuring Windows Phone Apps.

Here is a proposed design process for Windows Phone apps that I’ve been using. While many of these are conventional design process stages, I’m trying to explain them from a Windows Phone app point of view specifically. Drop me a tweet if you have any comments or questions or leave a comment in the blog

This post is about the end-to-end process so I will keep it high level and in upcoming posts we’ll start exploring each of these steps in detail. Next week for example we’ll begin with Ideation & Concept - all about storytelling, sketching, storyboarding and low fidelity (paper) prototyping. This process basically becomes the axis for the rests of the posts. I have no doubt that based on feedback we might refine some of the stages and will be adding more examples as we create them.

Chart is read from bottom to top... 

The Windows Phone design process is no different from other design methods for authoring websites, mobile apps or designing anything for that matter. Designers around the world value the design process, make it their own, tweak it, perfect it and change it for every project. No project is the same so it is important to understand the design process more as a set of guidelines than a set of rules. Keep it flexible. The thing to understand about ‘design’ is that it is not a “one-shot” type of activity - you have many shots. You do not have to nail down the design in a single try but instead it’s an iterative process much like what sculptors deal with when producing a piece of art. When they have a piece of marble, they just don’t start working out the details from the beginning, like eye brows, or finger nails or hair. Instead they give the block of marble a first pass and start giving it a general sense of form, the main volumes and core masses. Then a second pass and they start defining more specific masses for arms, thorax, head and legs. Then a third pass, a fourth and a fifth one. It takes them many passes for them to reach the point of being able to work out the little details. User experience design is the same. You can’t start working out the details at the beginning and if you try to, the beast (aka your app) will get back to you and eat you :0. For example, Application Flow has to be defined before you get to Visual Design. I’ve seen this happen many times, we try to skip some steps to stay ahead of the curve, and the lack of design exploration comes back to us with fury later in the project. Bryan Agnetta explains this well @25:49 in his BUILD session titled Journeys.

App Theme

We begin our process with an application theme. Wait! This is the first point where things can fall apart! - But we are just getting started Arturo! J I know, I know but the app theme is so important to enable you be successful on the next few stages. The thing I’ve noticed time after time is that when we start our app design process we either 1) already have a super clear idea of what we want or 2) we have based our goal in an existing API or Web Service available out there. Both approaches in my opinion are wrong. If you have a super clear idea of what you want then you are conditioning yourself and your team to a solution we haven’t even allowed ourselves to explore yet. If you decide to create an app based on an existing API or Web Service you will end up with yet another Twitter, Yelp! or Foursquare client or another stock app that gets data from Yahoo! Finance or another RSS aggregator that gets news from CNN… Search for CNN in the Marketplace and you’ll see what I’m talking about. While those apps might be a good learning experience, believe me, they won’t breakthrough or contribute a lot to users. Do not think of APIs or RSS Feeds at this point. Think of user experiences. So instead of thinking: “the CNN RSS Feed is available w00t!” - think: “How can I contribute to the experience of getting the latest and most relevant news for users?”. As soon as you think of it that way you immediately open a huge world of exploration for you and your team. It’s no longer an RSS aggregator, now you have a higher goal, a heroic task to help users get access to the most relevant news for them. Because the objective is broader, the solutions are less concrete and that’s what you want at this point. You want to keep it open so you can explore and come up with innovative ideas. Instead of thinking in terms of APIs, think in terms of experiences, like the running experience, the dining experience, the sailing experience and then ask yourself and your team how can you contribute to enhance that experience for your users. Note it doesn’t necessarily mean solving the entire experience… it could mean solving just X or Y portion of the experience where users tend to find difficulty or where you see an opportunity for helping users reach their full potential. Later on in the development process you will decide if you use an API or RSS Feed from whatever source but your starting point should not be the technical solution. The most popular Twitter (Seesmic) or Foursquare (4^th and Mayor) clients are successful precisely because they thought of the experience first - not the API behind it.

Now, if you are authoring an app for a client who has a specific product or service or you are porting and app from iPhone or Android into Windows Phone then certainly the theme (and more than that) will already be defined. In most of those cases, depending on budget and client needs you might have to go directly to the Information Architecture stage. Let’s be honest, I’d love to tell you that you can still do Ideation and Concept but the real world as well all know is that if you have a client that hires you to port an iPhone/Android app to Windows Phone, chances are the theme, concept and even information architecture will already be defined. This is not bad news J In fact, once you get to the Information Architecture and Interaction Design stages, the best of the Metro Design Language comes out: Pivots, Panoramas, App Bar, List Views, Typography, Layout and Motion. When porting apps from other platforms, your job becomes an exercise of 1) understanding the current IA in those platforms and then translating it to the right screens, content views and navigation metaphors in Metro. The fundamental thing to understand when migrating from iPhone and Android is that you are not migrating the UI. You are migrating the Information Architecture. By thinking and acting this way, you will prevent wrong conversion processes… like when some folks try to migrate the back button from iPhone (usually an on-screen button on top left) to a button in Windows Phone… guess what?… you don’t need an on-screen back button in Windows Phone because we have a hardware Back button. So, it’s better to think in terms of “migrating IA” than “migrating UI”.

Ideation and Concept

Now that you have a theme or mission it is time to start generating ideas for it. The Ideation and Concept stage is fun! - it’s almost like playing games. Games of brainstorming, games of sketching and of telling stories. There are 3 key stages in the Ideation & Concept phase: 1) Brainstorming 2) Exploration and 3) Consolidation. In a nutshell during the Brainstorming stage you generate tons of ideas, during the Exploration stage you dissect and study many of those ideas (but not all) and in the Consolidation stage you decide which ideas will move forward to become part of your app. Only few of them make it alive.

Brainstorming Full Freedom

This is a stage where the goal is to generate tons of ideas that relate to your mission, like “Contributing to the hotel booking experience”. Imagination, delusion and craziness are good skills to possess at this point. Be playful and think outside of the box. There are concrete brainstorming exercises like Subjects + Verbs + Objects and ways to stretch your mind like Alternate Worlds, Impossible Scenarios and In Other’s Shoes. We’ll discuss all these techniques in the next post. These games can be played with you and your team or even friends if you are independent developer. The goal during this stage is not to constrain yourself wondering “how will you get to build or program this or that”. It’s not even about how thing look. It’s about generating ideas and the crazier, the better. In the next few stages, those ideas will be brought down to earth and executed. After all, as we all know, there’s a million great ideas out there but only the one or two that get properly executed, succeed.

Exploration Dissect/Inspect/Test Ideas

In the Exploration stage you will take some (not all) of the ideas that came out of Brainstorming and get to learn more about those ideas. You learn more about your ideas by dissecting, inspecting and testing those ideas. Ideas at this point were just born, they are babies and they have not fully developed or matured. This is where some of those, perhaps crazy ideas that were generated during Brainstorming fall apart - but many of them will make it through. You will undeniably notice you or others in your team will embrace, adopt and fall in love with some ideas - their babies. I’m tempted to say that’s not good but at the same time, you have to love certain ideas so you can really push them forward. Sometimes ideas need development for them to fully manifest. If you give up on an idea too quickly you might have missed a good opportunity. Luckily at this stage we have 4 very useful tools that allow us to explore our ideas and find some good ones: Sketching, Storyboarding, Prototyping (Paper) and Storytelling. These tools help developers and designer to put ideas to the test.

Despite initial expectation, Sketching can be learned and in fact having less sketching ability might even help you remain more abstract at this point. Storyboarding will help you tell stories in a similar fashion to Pixar or Dreamworks animators. You use drawings and boards with scenes of user experiences showing ideas to help and contribute to those experiences via apps. It’s a visual mechanism. Prototyping is a whole world to explore but at this stage we’ll focus on Paper Prototyping. There are a couple ways to do this: one is to literally build an analog prototype made out of paper, sticky notes, cardboard and tape. You can then test scenarios by manually pasting screens on top of others to convey interaction. This type of paper prototype requires a guide and a user tester. I know it sounds like a completely dorky activity! J but it seriously is not… it is a very serious thing. It is amazing how much feedback you can capture by investing $0 and only 15 to 60 minutes in putting together a paper prototype. I won’t be telling you to do paper prototypes in more advanced stages of the design process but at this point it’s your best shot. Another way of doing paper prototyping is with Expression Blend (or Powerpoint or any other “interactive tool”). This really is a hybrid analog/digital technique first shown to me by Jared Potter, a Sr. Design Integrator in the Design Studio. In a nutshell, you sketch screens on paper, take photos, insert those photos in Expression Blend, add transparent buttons on top of “clickable” areas and hook up navigation. Done! He calls it the 15 Minute Paper Prototyping technique and we’ll talk more about it in the next post.

Consolidation Make Decisions

You begun the process with tons of ideas during Brainstorming. You allowed yourself and your team to Explore many of those ideas… but here in Consolidation, only few ideas, the very best will come out alive. This is the stage where you make decisions on what makes it into the app and what doesn’t. There are different exercises to help your team narrow down the list and obtain a prioritized list of ideas. The goal here is to remove ambiguity as much as possible. By now, ideas will have evolved to more than just concepts and will in most cases become user scenarios (or information scenarios). A list of prioritized scenarios is what you need to move on the next stage.

Information Architecture

The goal of the Information Architecture (IA) stage is to define information, tasks and the relations between these. That’s what the user has for herself in a digital experience: information and the potential of doing something with this information - whether it’s consuming information to help take decisions or gain knowledge about something or also for generating information.

Information Architecture is a whole discipline on its own (there’s even an Information Architecture Institute). The goal of Information Architecture is to bring information to order.

During the Ideation & Concept stage you generated some great ideas. These user scenarios involve shapeless blobs of information like names, dates, prices, images, temperature ranges - in the Information Architecture stage you take that shapeless blob and deliver structured information. Doing it in single try is impossible. It needs many passes.

We have two very useful tools that help us define our IA: Application Flow chart(s) and Low Fidelity Prototyping.

So you take a first stab at you IA and then you test it by creating Application Flow charts. These have different levels of maturity, mainly from task flows to detailed screen + content view + navigation charts. Remember the good old flow charts for software engineering (or any other process)? That’s what app flow charts are, it’s just that the visual nomenclature we use is focused on user flow, experience and interaction design. Once you get an app flow chart, you can try telling the story of that user scenario, you will get feedback and ideas for refining the IA so you go back to the AI document and polish it. Then you go back and test by creating a higher fidelity app flow chart and so on and on. Little by little app flow charts become more detailed going from simple task flows to screens that show an idea of content views and even navigation. I wouldn’t call high end app flow charts wireframes but many people would. Low fidelity wireframes certainly.

The other tool we have are low fidelity prototypes. At this point paper prototyping can continue to be helpful due to its low cost ($ and time-wise) however, the app flow charts will be getting higher fidelity pass by pass and you can start using these charts to build your prototype. You could print out the app flow chart and put together an analog prototype (no longer with made out of sketches but printed materials) or use Jared’s prototyping technique in Expression Blend just that instead of taking photos of sketches, you take your app flow screens.

At the end you will have a solid IA document with structured information, a solid set of app flow chart(s) and even some low fidelity prototypes based on this app flow.

One thing I noticed after creating the Windows Phone Design Process chart is that IA represents almost 35% of the total of the height, almost the same as Interaction Design (the next stage). While the chart doesn’t necessarily represent the scale of a project, I must say it’s pretty accurate to think that IA deserves all that time. If you nail down the IA then the rest becomes so much easier.

We’ll have a specific post on Information Architecture for Windows Phone apps in a few weeks.

Interaction Design 

We have defined the structure of the information as well as the tasks users can perform with this information. Now we have to start crafting the user interface for all these things to live in.

That’s what interaction design is: creating a set of user interface and user experience elements that allow for our well-structured information to manifest and for our users to successfully accomplish their tasks related to this information. What we want to achieve at this stage is to deliver the maximum potential for information and tasks to occur. While our IA might be just perfect, if the interaction design is not fully executed then what happens is our information won’t be fully realized in our application and/or users are not able to accomplish the tasks they want.

In my opinion, by default, interaction design is a filter to information and tasks. It is a filter because by definition it is not the information nor the tasks but a means. Interaction design (or user interfaces) are the intermediary between the user and the information. In other words, user interface (what results of interaction design) should be guilty until proven innocent I think this concept relates a lot to what Metro Principles establish: Information is the star of the show, not the user interface. The UI is there only to accommodate information and enable tasks. It will be a matter of good (or bad) design execution to define whether this user interface layer is a thin, almost invisible veil or a thick and heavy membrane. I’m not even talking about visual design here but interaction design: how the user interacts with information and the tasks that occur around this relation.

If we didn’t have a Windows Phone Metro Design language available then we’d have to figure out interaction metaphors from scratch. In a future post we will talk more about how to push Metro forward and give you some ideas for how you can innovate on top of it but in this post I will focus on defining interaction design with the out-of-box Windows Phone Metro Design Language as our ally.

Design Patterns are our friends here. Having a solid IA helps translate information structure to Metro controls. Information Structure and Tasks will give birth to Pivots, Pages or Panoramas. Information Hierarchies and Structure will give birth to Content Views. Relations between Information and Information, Tasks and Tasks and Information and Tasks will give birth to Navigation (think App Bar). Everything in our IA document will translate into specific Windows Phone controls. There’s no ambiguity here and when there is then we have a couple things we can do: we can customize design patterns or create our own.

Let’s review this again, first, based on your IA document, select some of the out-of-box Design Patterns in Windows Phone, for example search, or maps in local scout, or email, playlists, or contact cards in the people hub. Then, if you do not find a design pattern that fully or at all satisfies your IA needs then you can customize a close enough design pattern or even create your own. When it comes to customizing or creating your own design pattern, you have 3 good tools you can leverage: 1) the Windows Phone Design Grid 2) different weights and sized Typography to convey structured information and 3) using out-of-the-box UI Metro controls. While these 3 are certainly not all the weapons you have at your disposal, they are the most essential ones. Certainly the Windows Phone UX Guidelines will cover all there is at your disposal.

Am I proposing a Design Pattern approach to design Windows Phone apps? Yes! It is not the only way to design Windows Phone Metro apps! As we’ve mentioned before, we’ll talk more about how to push Metro beyond the baseline design patterns in future posts but in this post and the next few ones I want to focus on mastering the Windows Phone Metro Design Language. If we nail this down, in my opinion, we’ll be ready to start creating our own design patterns that might look nothing like what the out-of-the-box control library and metaphors look like (but still based on the Metro Design Principles).

You can find some List view design patterns in Photoshop format (ListView_PSD.psd), panorama panels (Panorama_PSD.psd) as well as other controls here. We’ll be rolling out tons more of these.

After you’ve selected design patterns, customized some and created a few, you will basically have your app designed. Sounds too easy! - it is… not The reality is that selecting the right design patterns and then customizing them is the bulk of the work. One thing I’ve discovered is that the Windows Phone Design Studio has invested 2+ years crafting and evolving the Windows Phone experience and UI. The design patterns found in the phone are SO flexible and comprehensive. After reviewing almost 200 apps during the Windows Phone Design Day Tour last Fall I realized 90% of them could have been solved using existing design patterns OR with customized design patterns. When I first started my job in the Design Studio I wasn’t familiar with Metro and my impression was that it was beautiful but that every app looked the same. Now I’m here writing to you about re-using existing design patterns to design your entire app Has something changed? Yes! - My impression 6 months ago was that everything in Windows Phone was Pivot or Panorama period. But what I’ve found after these months is that Windows Phone apps are way richer than just using one Pivot or one Panorama. Windows Phone apps are made out of Pivot(s), Page(s) and Panorama(s). Many of them. All interconnected. In turn these 3 types of screens host an infinite number of layout possibilities for apps. This is where differentiation comes from between apps (a common question from developers). The possibilities of customization of Panorama panels, and Pivot pages is infinite. Windows Phone apps using the Metro Design Language can be very rich and unique. Myths like “if the background is not black then it’s not Metro” have been around for some time but this couldn’t be further from the truth. Check out this article by Mike K or the winners of the Core77 Windows Phone Design Contest.

One of the big rocks in our list is to produce tons more design patterns for you in different formats: Photoshop, Illustrator, Expression Design and XAML. Right now, there’s not a lot of design patterns out there and the ones I’m recommending you use are inside of the phone so we have some work to do there here on our side to expose these in a ready-to-use format for you. Sign me up!

Back to the process, your design pattern selection, customization and creation stage will render in wireframes. Wireframes will be grayscale. No colors! No branding (yet)… No panorama backgrounds! These wireframes would ideally be created in Expression Design, Visio, Photoshop or Illustrator (makes me think we should also provide design patterns in Visio format… hmm).

We are ready to move to the next couple stages of the Interaction Design phase: we want to define Motion Styles and UI Control Specs. In reality most of these concepts will already come along with the design patterns we previously selected. After all, design patterns in this context are interaction design patterns and not just visual design patterns.

Motion Styles will help us specify on top of the wireframes, the motion we’ll have when transitioning from A to B screen (like a Turnstyle) or when displaying details of a list item (perhaps using Continuum). Motion is an important part of a Windows Phone app so it’s critical that our design establishes specifically what motion styles to use. At the same time UI Control Specs are also needed on top of the wireframes so that when building the app, the developer knows for example, the type of keyboard we need based on the user experience we are putting together. Or when it comes to Notifications, we would also show the specs for the content of A, B or C Notification and where these notifications take you to inside the app. Same thing with Loaders… do we want a % loader or a wait cursor?.

At the end of this stage you will have a solid set of wireframes for your entire app made out of out-of-box, customized and self-created design patterns. These wireframes will include motion styles and UI controls specifications. Ready to the next phase: Visual Design!

Visual Design

By now many of you (and probably even me) would go like: what, no visual design until almost the end!? - Kind of. Like I mentioned before, the design process (of anything) is not linear. If you are like me I would have opened Expression Design (well, you’ll probably be using Photoshop or Illustrator) and would have started working out some comps right away I just love that - just going to my favorite tool and start nailing the app down. No sketching, no wireframing, just nice and pure visual awesomeness! - most visual designers think that way (like when developers jump directly to Visual Studio to code!).

I must admit I’m more of a visual designer than an interaction designer. I definitely guide myself more by how it looks so I gravitate towards visual design at the very beginning of the project but I have to control myself and remember there is a design process and if I skip steps, my design might end up being beautiful but will not faithfully represent the Information Architecture and Interaction Design required for the app to work. That said, we know looks sell and we have all been asked by clients to send them a comp of their app early enough in the process. Doing so has nothing to do with nailing down the visual design from the beginning (though some clients love to think that’s the case) but more with being able to “sell design”.

As much as we might love Information Architecture and Interaction Design, to clients, business decision makers or marketing managers, an image is worth a 1000 pages of IA. A beautiful comp of a Windows Phone app will help the people funding the app to get more funding, to give progress reports to their teams and to look good with their bosses :). That’s just the way it is. So this is where visual design oriented people like me have our do early enough in the process when the IA is not fully nailed down or the Interaction Design defined but we do our best to envision something that will eventually realize. Many times people think this vision is THE final product but no, it’s just an attempt at showing where we are going to. The problem is when the team or the client embraces this early visual design attempt as THE direction. Expectations should be set so there are no disappointments later in the project because it is only after IA and Interaction Design that you can fully realize Visual Design.

So, now that we have our IA and Interaction Design nailed down it is time to take care of some fun Visual Design activities like defining our color palette, designing custom icons, backgrounds, incorporating branding to our experience and designing live tiles.

You know how there’s always the typical conversation about whether developers should be doing design or not? Well, all the way to this point I’d say a Developer with no formal training on design could have arrived here with success. Information Architecture is a very systematic and structured, logic driven discipline. I personally think Developers have the right mindset to nail down IA. Interaction Design requires more experience and this is where interaction design experts can excel in the process but if a developer follows the Design Patterns approach, I think he/she could definitely get it right. The challenge at this stage is the current lack of design patterns and the right tools to accomplish this method, challenges that increase the level of difficulty for people with no formal design training. Finally, this Visual Design stage is where I do think you’ll be better off hiring someone trained as graphic/visual designer or illustrator. While there’s a number of ways to learn design or even license icons, photos and other elements from places like istockphoto.com - it will never be the same as hiring a trained designer. That said, I’m hoping we can provide some practical tips for developers to better craft some visual design elements based on stock material in a future post.

Redlines and Greenlines

What are Redlines? And What are Greenlines!? Simple answer. They are the blueprints of an interaction experience. Just like in architecture there are blueprints where you can see floor plans, side views, facades of houses our buildings, with dimensions, how big is this door, this window, how thick is this wall, where are the water pipes running through, the electrical outlets positions, how high from the floor, what materials are you using in the floors, paint color etc etc… well, in interaction design we also have our blueprints called redlines. I’m not sure why they are red and not… magenta… but I think it’s because red is usually a color that really stands out so it’s easier to read UI dimensions and other specs this way. Redlines are screens that show the different screens of an app with a bunch of measurements laid on top. These numbers define margins, padding, dimensions of elements and transient elements like the status bar on top of the screen in Windows Phone. Why do we need redlines? I thought Expression Blend was the solution to our problems! So far in the design process we have not used Expression Blend at all. I know this could trigger a long discussion so I will leave the details for the Tools for Designing Windows Phone Apps post in this series. I will say however, that redlines represent the best mechanism for designers to hand of UIs to - “whoever” gets to put together the UI in XAML. This person might be the so called Integrator (real heroes in this world), another designer with XAML and Blend knowledge or even a Developer. Whatever the case might be this other person will not be the same person who designed the app. That’s just how teams work. So this other person needs a way to produce the UI in XAML and redlines help accomplish that. With redlines there is no ambiguity (there are always questions though) but if this button is 30 x 150 pixels, located 24 pixels to the left of the screen and 427 pixels from the top, then that those are the dimensions and that is the position. Period. No discussion. In the past, without redlines, designers would design web sites and hand off JPG comps (never use JPG for comps, always PNGs! - no compression) to someone else to generate the HTML and CSS. This process would always break the design and the results would be different than the original vision. Redlines represent a “contract”, a written document that both parties can agree to literally! We’ll talk more about redlines and how to create them in a future post as well.

What are greenlines? The Windows Phone Design Studio learned that defining touch areas is fundamental. Some buttons will have say, 10 pixels in diameter, but their touch area will be 20 pixels (to make it easier for users to tap them). Greenlines specify these touch areas, whether these match the size of objects or like in many cases, represent extended dimensions to the objects they would trigger. Greenlines are delivered separately from Redlines.

The End

At the end you deliver Redlines, Greenlines, full quality polished visual design comps and the IA document. When the app has been designed, it goes to the Integration team which will build the UI in the platform of choice. In the case of Windows Phone it will be XAML. In the case of Windows 8 it could also be HTML/CSS. But independently of the platform you are building, your design now is so solid, your screens so clear, your panoramas and pivots so well laid out that it is ready to be transformed to code. In the real world, the development team won’t wait for the design team to be done before they start working… development and design teams work in parallel. In some cases where the project schedule is long or relaxed enough this might be the case but in general you will always have design and development going parallel. Designer/Developer collaboration is a whole topic of discussion on its own. I believe I don’t currently have a topic on this but I should probably add it.

Well, this is it. Long read again. This was a high level overview of the process but beginning next week we’ll breakdown the process in detail.

Next Post | #3 Ideation & Concept

In our next post we’ll discuss the Ideation and Concept stage in detail and talk more about brainstorming techniques as well as sketching, paper prototyping and storytelling.

I’m working on this week’s post #2 Windows Phone Design Process. I hope you enjoy it. I should be able to post it tomorrow Sunday PM.

As I mentioned in the first post, I’ll do my best to finish the series before 31 weeks I know the 31 number in “weeks” is now arbitrary - the goal of the 31 Day format as I learned this week is to post everyday for a month (duh!). I thought whether I should scale down my posts and make them more like little design tips so I could post daily vs longer deep articles and I’m opting for the longer/deeper articles that just take more time to craft but that at this point I think will be much more helpful for everyone - I think deeper design guidance is needed vs just little tips. At the end we’ll end with a super solid end-to-end series on Windows Phone design.

Also, after 31 weeks I might just even pack all posts together and publish a free e-book for all of you to download How’s that?!

Metro Design Principles

We usually refer to “Metro” as the UI design style Microsoft is using in their platform and the one Microsoft is exposing for developers and designers to create apps for Windows Phone (I’m focusing on Windows Phone in this series). But let’s delve a bit deeper into the term “Metro” and explore what it really means. To begin with, Metro is defined by two things: Metro Design Principles and Metro Design Language.

The Metro Design Principles are the pillars (usually abstract concepts) that guide the creation of experiences for Windows Phone.

The Metro Design Language is a set of concrete user interaction, visual design, motion and application flow elements and rules.

An analogy of the relation between Principles and Language could be an abstract concept like “Love” (… a Principle) which could be expressed by a concrete symbol like ♥  or the combination of four characters “l-o-v-e” which give birth to the written form of the abstract concept “love”. I’m sure you could come up with an infinite number of other concrete ways to express the concept “love” including the sound of the word itself, photos or other metaphors.

The tangible manifestation of a concept is called language.

If we had a Principle like Glass and I need to manifest it with three icons: a pencil (Edit), a star (Favorite) and a cross (Close) and a control like a button these could manifest in a visual language like this. If I give you these, I’m certain you could derive other icons or even controls.

The same icons and button with Metro using a Principle like Fierce Reduction (Light, Clean) would look like this:

So different Principles give birth to different expressions or Languages.

I found this video sometime ago and I think it explains well what Design Principles are (Architecture). In our case Architecture refers to Design Principles and the different cups in the video represent the Design Language.

In the examples above and after watching the video you will realize that you could also define or create different Languages from the same Principles. For example, if I had just given you the Glass Principle, I’m sure everyone would have expressed the icons and button in different ways - all matching the Glass Principle but still different. That is because there’s no single way of manifesting a Principle - their abstract nature means they will be represented or interpreted in different ways by different people (more about this below under Metro Design Language). It will be a matter of design execution to achieve a more (or less) successful interpretation of the Principles.

The Windows Phone Design Principles are:

Light, Clean, Open, Fast (Fierce Reduction)
Content, not Chrome
Typography
Motion
Authentically Digital

 
Jeff Fong is a Principal UX Lead in the Studio and one of the three designers (along with Jae Park and Bill Flora) in Microsoft that started exploring Metro before it was known as Metro in products like Media Center, Zune and others. If you want an in depth review of all the principles please watch this fantastic session from Jeff. He covers all the Principles in detail.Also, here are some ideas and observations of my own about our different Design Principles - hoping I can share these in a practical way for you guys to use on your daily practice.

Fierce Reduction

We usually think this applies only to visuals and to making things look minimalistic but that’s not all of it - in fact, first, when designing an app, apply this Principle to the application flow - then, after that apply it to visuals. We usually work hard on making our UIs nice and clean but we don’t clean up the flow or the process the user has to follow to accomplish tasks in our app. It’s not enough to have a very nice Metro looking UI while at the same time asking users to navigate to screens they shouldn’t need to go to or have them get lost in the app because the application flow is not straightforward.

“Fierce Reduction starts with the application/experience flow - only after that it goes to user interface design.”

Content, not Chrome

This inherits from Fierce Reduction but it is more focused on the user interface and the visual design - the way things look. The key here is to acknowledge that the star of the show is information (aka content) - both from a consumption and production points of view. We usually showcase Metro in content consumption scenarios but Content, Not Chrome applies also to content generation. People use some apps mainly to consume content, and use other apps mainly to generate content. Content, Not Chrome reminds us that no button, slider, background or layout is more important than the information we are presenting to the user. The content *is* the UI. You will find other design styles where sometimes it would seem the designer wants to be the star of the show, the borders or drop shadows, the adorners, the complex backgrounds - in Metro we believe content (consumption and generation) is king.

” The star of the show is information/content, not UI controls or interface.”

Typography

Typography, typography, typography… when it comes to Metro everything seems to be about typography. Metro is not all about Typography. Typography is no more important than photos or images or icons or motion or sound. Remember the first two principles: Information is the star of the show. If it makes sense to express information with typography do it - otherwise don’t force it.

Typography can be beautiful when incorporated with design skills. For example, in Metro, we use typography in different sizes and different weights to convey structured information (beautiful example below). And this is exactly the thing that makes typography stand out from other media - it’s not typography for the sake of typography but typography as a particularly efficient and flexible tool to convey structured information. It beats icons, photos or other media on this particular area: structured information - structured information is information that has hierarchies, that shows an order, and that helps the user prioritize consumption of information. This is the reason we don’t use “bullet points” in Metro - they are not needed if you give the right size/weight treatment to text.

“Metro is not 100% about Typography. Typography in Metro is just another way to convey information. Typography however, offers unique visual design possibilities to convey *structured information* to the user.”

Beautiful use of typography to convey structured information.

Motion

We’ve talked before how Metro was inspired in printed media design styles. How Print Design is the Future of Interaction is a terrific post from Mike Kruzeniski, Principal UX Lead in the Studio about this topic. When the world moved from printed information to digital information a lot of things changed. Our medium is not static paper anymore. It is screens made out of dynamic pixels that allow us to convey motion. So the question is how to have Motion contribute to make information the star of the show? First is to acknowledge like in other cases, that Motion is there to serve - to make information stand out. Gratuitous motion effects would represent noise and would distract the user from consuming information. In Windows Phone we use Motion to emphasize application flow and to provide depth to the experience. For example, if we take a use from one app to another we use a Turnstile motion which is a more aggressive effect that helps convey the idea that we are taking the user “to another place”. When we want to simply display new information within the same context we could use something like a Continuum motion. It’s a more gentle, less aggressive/dramatic motion that sells the idea to the user that they will be presented with new information while staying in context.

Watch this session by Jeff Arnold, our Sr. Motion Design Lead in the Studio. He describes Metro motion in depth.

“Motion is there to serve and contribute to making Information the star of the show. Use motion to emphasize (or de-emphasize) your application flow.”

Authentically Digital

Jeff Fong describes this principle the best way: “It’s about being honest with the fact that we are designing for a screen, made out of RGBA pixels, and for a screen with a specific dimensions”. For example, imagine we were creating an application to sell books (oh oh here I go :)) so we have to expose the cover of the books to users in a menu. A particular design style like iPhone’s would recreate a metaphor from the physical world (like a bookshelf) to solve this scenario. The bookshelf is gorgeous, well aligned, book covers fit nicely and it even uses wooden texture to make it feel more “real”. This design style Iconographic. It uses metaphors from the physical world in a digital world. In Metro we are Infographic. The Authentically Digital Principle would question the need of a “wooden bookshelf” to hold “images of book covers”. After all, wood is not wood in the digital world - it’s pattern made out of pixels - it’s “fake”. If you take out the “bookshelf” the “books” will not fall down because there’s not force of gravity. So no need for a wooden bookshelf. Instead remove the chrome, the unnecessary, respecting the fact we are talking about pixels.

Let me be clear with something: I’m not saying one style is better or worse. I’m just drawing the difference. It’s simply a different Design Style based on different Design Principles. Nothing wrong with that. I can understand how translating metaphors from the physical world to a digital media has been a hot trend in the last decade - after all, when masses of users went digital in the 2000-2010 and migrated quickly into PCs (Windows and Macs!), tablets, smartphones - the feeling of preserving your “wooden bookshelf” was comforting and familiar. I can totally understand that (and relate in many cases). If you look at Windows XP or even 7 or the good ol’ Windows Mobile 5 or 6.5 - well, Microsoft was also using this Iconographic style - recreating metaphors from the physical world.

In Metro however we believe users care more about being able to consume information than having “representations of physical world objects” inside their phones.

“Design for screens that are made out of pixels, pixels that in turn convey information. Law of gravity doesn’t exist. Sorry Newton… :).”

Examples of iconographic style user interfaces. Recreating objects from the physical world in a digital screen.

Windows Phone Metro Design Language

To empower developers to create Windows Phone apps, Microsoft could have just announced/talked about the Metro Design Principles but of course this would have meant developers had to create their own Design Language and spend hours and hours doing so. Creating a Design Language for a modern device like a phone is a big deal and requires of many hours of design, iteration, reviews and user testing. The Windows Phone Design Studio crafted a very solid Language that everyone can use.

Based on the Metro Design Principles, Microsoft provides the Windows Phone Metro Design Language. Using it will set you up for success to craft beautiful, compelling and consistent experiences for Windows Phone. The Windows Phone Design Language is determined by these categories:

Navigation. Layout.Composition Typography
Motion
Iconography
Images & Photos
Themes & Personalization
Touch Gestures & Targets
UI controls
Hardware
Services
Marketplace and Branding

 
Compared to the Principles that are abstract, the Language is concrete. So there is a concrete navigation system in Metro called Hub & Spoke (more here). There’s a concrete set of gestures like tap, double tap, tap & hold, flick, pan. There’s a concrete typographic style using Segoe in different weights and sizes to convey structured information. There’s a concrete set of UI controls like buttons, radio buttons and checkboxes, sliders and others UI metaphors. There’s concrete application interaction metaphors like Pivot, Panoramas and Pages.

All these set of concrete elements is what makes up the Windows Phone Metro Design Language. It’s a comprehensive, end-to-end, flexible and extensible design language.

But, is this out-of-the-box Design Language the only way to manifest the Metro Design Principles? No.

For example, could I use Helvetica or Swiss fonts in my Windows Phone app and still be Metro? Of course! As sans-serif fonts these and other fonts could be used instead of Segoe.

We will talk more about how to take Metro beyond what comes out-of-the-box in a future post but check out this article on Lessons from Swiss Style Graphic Design to  explore some print design examples that follow the same Design Principles as Metro (other than Motion and Authentically Digital). They look pretty different from the out-of-the-box Windows Phone Metro Design Language (to be clear those are print examples…) but they are based on the same Principles. This could give you an idea of how the same Principles could be expressed in different ways beyond what we provide out-of-the-box.

The 3 Sources

The Metro Design Language for Windows Phone is defined via three different sources:

1. The Windows Phone UX Guidelines

2. The Windows Phone SDK Control Library (and the Silverlight Toolkit for Windows Phone)

3. The out-of-box apps and services in Windows Phone (email, text messages, people hub, music/video hub, phone app)

These three sources should in theory communicate the same. We are aware of some  differences between them and we are working on them.

The Windows Phone UX Guidelines are the “Bible” of Windows Phone design. It is reference material and we continue to work on them to keep them updated and to maintain the spirit of them being used as a solid reference source.

The Windows Phone SDK contributes to the definition of the Metro Design Language by exposing a number of UI controls for developers and designers to use in Visual Studio and Expression Blend.

Now, here is one thing I think you will find really valuable. The third way we express the Metro Design Language for Windows Phone is in Windows Phone itself! - the out-of-box apps and services we all use like email, text messages, people hub and local scout. We call these Design Patterns. This is something I don’t think a lot of developers and designers are aware of: you can learn from and use these Design Patterns to craft your own applications. Ideally these patterns should be documented in the Windows Phone UX guidelines (we have this in our to do list :)). I’ve done this myself many times, launch the Phone, go to People hub or email app and see how they are solving search or list sorting or other patterns - then I go to my design (Expression Design, Expression Blend, Photoshop, Illustrator) and reuse those design patterns.

Next Post | #2 The Design Process of a Windows Phone App.

There’s many ways of approaching the creation of a Windows Phone app - I’ll share with you the one I’ve used and hope it helps you craft good experiences and good design from the very beginning of the process.