Prototyping Fresh Paint for Windows Phone

painting-close-up

In the World of prototyping there are many possible outcomes. Sometimes the prototype becomes an application, other times it becomes nothing. The prototype I’ve chosen to discuss is no exception. Sure it’s an application made for Microsoft, but they have changed much as a company in the past four years. I’ve found that the agile development process has been making the rounds on Microsoft’s Redmond Campus like never before, leaving everything up in the air. Not that it has ever been a walk in the park as a designer here at Microsoft, but the ship cycle used to be 3 years and now it’s every week.

The feelings of desperation, anxiety and uncertainty make for an exciting workplace indeed. Not to mention the people for whom I created this prototype are part of Microsoft’s research organization known as the start-up business group. The point being that I had a mere 48 hours to make the prototype and provide the development team – two guys – with the assets and the code necessary to move forward into production. Somewhere around the 14th hour I handed-off a rough prototype to be served as a demonstration to the stakeholders who would make or break the application as far as funding was concerned. Luckily for me as I was coding another designer was kind enough to generate the assets needed for the controls – from the composites. Kind of backwards, eh?

My experience building the Fresh Paint application prototypes reveal the difference between ideal app design process versus actual app design process. Let’s break the two down a bit, shall we?

An Ideal App Design Process

The business, design and technology triad come up with an idea for an app and a strategy

Sketch the UI’s golden path – what are the goals and personality? – and discuss it with the team

Create an app-flow diagram and discuss it with the team

Create wire frames of the UI, smoothing out the UX with functional specifications – functional “specs” cover what the different controls do, their behaviors, events actions and such and discuss these with the team

Create a few personas representing the apps intended users using models from Getty Images and give them names based on character from HBO’s “Game of Thrones” so colleagues chuckle and love you for it then seek compromise with the team

Design a few versions using sexy software like Sketch, Marvel, Pixate, Illustrator, Photoshop, 3D Studio Max and Cinema 4D and discuss them with the team

Put together a deck for presentation to the broader team, usually known as a stop-motion or “paper” prototype to solicit ideas and buy-in

Create motion comps using Adobe After Effects that demonstrate the physics of the UI and give context to the app flow diagram, sometimes using the personas as contacts within the app and discuss animation with the team

Start using the integrated development environment (IDE) of choice like Visual Studio, Eclipse, Source Insight or xCode, using a well-documented and intuitive software development kit (SDK) to generate the code and UI with regards to front-end development resulting in a draft of the prototyped application representing the culmination of efforts of the UX design team by yourself

Iterate and refine based upon feedback from the team

Present a bug-free prototype to the business decision makers within the company

Give high-fives all around when the app is approved for production

deliver the prototype, assets, functional specs and its source code to engineering

Listen to engineers throw chairs at each other whilst shopping for new fonts created by House Industries

FreshPaint_Mobile_App-01-472x266

Actual App Design Process (the order here doesn’t necessarily apply)

Come up with an idea for an app and a persona representing a fictional user, find a cheap stock photo or use family members to represent the user avatar.

Hastily draw the UI’s golden path on a white board and leave it up to serve as the app-flow diagram and wireframe adding as dead-ends occur and discuss it with the team as you code with the available IDE, using an under-documented and under-intuitive software development kit (SDK) as the design composites that will also serve as asset slicer conduits are created by you or a fellow designer

Put together a deck for presentation to the broader team, usually known as a stop-motion or “paper” prototype to solicit ideas and buy-in, use this as a functional spec for the prototype and make changes every day to adhere to good ideas that come from the team meetings

Add assets to the prototype as they become available, but use for placement only (FPO) assets in the meantime

Participate in way too many discussions with engineers and assure business decisions makers that the FPO assets aren’t the ones that will ship as they occasionally help and look over your shoulder

provide a prototype to be presented to the team and make changes based upon everyone’s feedback a couple of times

Give high-fives all around when the app is approved for production

deliver the prototype, assets and its source code to engineering and help integrate the markup

Listen to engineers disagree with each other whilst starting the next prototype with your team

I guess you could call the above comparison a good summary of what it takes to create an app from a design perspective nowadays. The prototype ended up serving as collateral to the PowerPoint presentation as it was more hands-on and could be toyed with as the presenter spoke to the stakeholders. Once we had the green light to move the prototype to engineering it served as a head start for the front-end UI as I coded it to be scalable for the devs – it was far from perfect, but at least they didn’t need to worry as much.

My part of the process involved not only creating the prototype, but all facets of the design process. It was a true team effort, with my main focus being the prototype. There were four designers involved and we worked together to bring Fresh Paint to Windows Phone. That was a busy week and one of the greatest experiences of mine at Microsoft!

Wireframing A Website

wireframe-650x421

What is a wireframe?

A Wireframe is a visual representation of content layout in the application.

Developer Perspective
Wireframes help developers visualize the entire product in a non-opinionated way.

Client / Business Perspective
Wireframes are an initial-stage deliverable that ensures both parties agree on the UX.

What are the benefits of wireframing?

Designers / Developers Perspective
Wireframes may inspire the designer, resulting in a more fluid creative process.
Wireframes give the developer a clear picture of the elements that they will need to code.

Client / Business Perspective
Wireframes provide the client an early, close-up view of the application (or a chance to get it re-designed).
Wireframes clarify any misunderstandings in the requirements

 

Storyboarding Short Videos for Microsoft

intune

Anyone considering making videos for Microsoft should take note of a few things I’ve learned. It’s good to be prepared to wait patiently as the stakeholders make revisions, meet legal requirements and give other feedback regarding design, audience and the message. The paradox is that as one waits for these crucial bits of information it’s important to keep moving the project along. The way I manage to do this is with the help of “For Placement Only” assets that I manipulate using Adobe After Effects, creating iterative versions of the video. The most important deliverable turns out to be a detailed storyboard representing the final product. This not only breathes life into sometimes banal scripts, it fosters buy-in from the client. The average amount of revisions for the entire storyboard seemed to be around ten. Where the average amount of revisions to the video should be about half of that of the storyboard, but not nearly as broad. It’s easier to make changes to a drawing than a video.

About Those Motion Studies…

Whenever I work on motion studies I rely on Adobe After Effects, but I’m just now discovering the power of Cinema 4D. Whilst researching a couple years ago I found this awesome blog called Greyscalegorilla. This group of 3D experts help keep me aware of current trends. Please watch the video tutorial about how to make a 3D app icon above to see what I mean. More tutorials may be found here, enjoy!

Some Advantages of XAML Versus WinJS in UI Development for Windows

I’ve worked on application prototypes for Microsoft using both XAML (C#/C++) and WinJS (HTML/CSS/JavaScript). While XAML has a tremendous advantage regarding MVVM (Model View / View Model), custom properties, explicit tags and XAML Storyboards, WinJS has the advantage of div abstraction, CSS and JavaScript’s seemingly limitless capabilities, not to mention jQuery support.

Let’s scratch the surface a bit into why both have benefits in an agile development processXAML’s gesture capabilities allow for quicker overloading of touch-based controls, especially if those controls are nested within other controls that have manipulations similar to their children. These types of behavior are somewhat difficult to manage in WinJS and can take hours to debug. I’ve found WinJS animation capabilities are quicker than those of XAML if the intent is to quickly apply event-based tweens, easing and transitions. Using XAML I often find myself searching for, cutting and pasting storyboards whether they are in XAML or in code-behind, but WinJS is convenient in this way – no need for storyboards here! I also find HTML divs easy to work with, as a div may be anything and everything.

While these benefits are good, there are also pitfalls. The more advanced the MVVM framework is in XAML, the less efficient it becomes – bugs arise everywhere and if a design change wasn’t considered from the beginning, then it becomes sluggish. Common controls are a bit convoluted in WinJS, something as ubiquitous as a list view becomes a bit mysterious and non-symantic because it’s a div too! Performance is also an issue with WinJS.

It’s hard to choose a winner because both are great tools. At the same time once a UX designer leaves the safe haven of the provided SDK code samples for each, things become a challenge. That’s why we’re here though isn’t it?