31 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 (4th 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.
- as well as her walkthrough the creation of the end-to-end prototype in Expression Blend.
