24 Weeks of Windows Phone Design Index

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.

24 Weeks of Windows Phone Design Index

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.

24 Weeks of Windows Phone Design Index

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.

24 Weeks of Windows Phone Design Index

 

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.

Hello! - Thank you so much EVERYONE for the amazing response to this series! - it just shows how much more design guidance is needed out there and we in the Design Studio will continue to put together articles and design resources for you. Thanks for all the articles, retweets and referrals to this series and for all your feedback!

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?!