What is User Experience Design (UX Design) ?

An article I wrote for Media Magazine:

Many people including you probably have no idea who I am and frankly sometimes I don’t know who I am but sufficeth to say my name is David Kelley and I’m a UX professional. Am I a graphic designer? Well no not really. Am I programmer of some kind? Not exactly but I can write some code. My title is ‘Principal UX Architect’ and typically I don’t even find myself dictating ‘architecture’ of any kind albeit I’m passionate about that too. My job when it comes down to it is communication, to bring people together and more or less be the chief Kool-Aid drinker.

What? Now you’re more confused than when we started?

Ok let’s dial back a bit then. My job is to help my team design an experience that fills a need and tells a story. To understand what that meant you really need to understand ‘User eXperience Design’ commonly called UX Design. If you look up what UX Design...

read the rest here:
http://www.interactseattle.org/?p=919

What I tell Designers to give me... Integrating and Digital Zen

Having composite teams with designers, integrators, dev's and the like on staff on the same time and working all in a unified set of tools like say, Expression Blend, Visual Studio, Silverlight etc etc etc for most of us is a luxary that we don't have. I have worked on teams like that and its awesome and all but not realistic all the time. Wirestone (the company I work for) is a great example what I would call the best interactive experience design firm in the world especially in the public facing/retail space (kiosks, touch walls, media marketing integration, social media marketing etc). We are truely awesome... But amazingly enough even though alot of these experience we build are based on some XAML related technology it doesn't mean that we have a zillion designers in blend for example. Like us it is not cost effective from a business standpoint to retrain all the designers out of Adobe, nor are most designers eager to switch...

Your response probably depends alot on your background. If you a ms zeolot you might think, why the heck not? if your a designer you might think 'dah' and there is a spectrum in between but as it turns out the biggest reason that its not cost effective is that there is a way... a straight and narrow path to a User Experience 'Zen' like team that works much like the above w/o using all microsoft coolaide (*gasp).

shhh... don't tell the ms ninjas...

As it turns out Microsoft did a bang up job with expression blend and probably the key thing is that blend does a wonderful job of importing adobe assets so well in fact that with a little bit of communication and learning to work together we still are able to achieve that zen state of designers, developers, IA's and the like working together at the same time on design and implmenetation. But there is a bit of a list I like to give my designers :) (don't worry there is another list for dev's;) for work on digital experiences

item 1. a pdf of everything they send me showing what they see looking at the assets (wiresframes, comps, redlines etc) native format is awesome too.

item 2. all typography with any font of any element that could maybe ever be dynamic as part of a digital experience I want a PSD typographic red line.

item 3. TTF's for all the special fonts that didn't come over in the PSD typographic red line.

item 4. all the UI elements are in AI (Adobe Illustrator). why? because it comes into blend almost as native XAML as its all vector based.

item 5. make sure all the elements are grouped in illustrator and named with something meaningful to humans... :)

item 6. illustrator elements must be inside the illustrator canvas or they don't work at all.

item 7. communication, communication, communication. talk about it. lets design together, walk me through the vision.

item 8. be nice to developers, not all of them understand the difference between Verdana and Helvitica nor do many of them appreciate the difference between padding=5 and padding=5.56793845. they are handicapped that way frequently.

now we can build some hot and sexy ui which is the only way I like my ui. if I don't have an emotional experience when I look at the ui the first time its not good enough.

From a business standpoint its not cost effective to re-train and re-purpose when we can do the same thing and still keep people in the tools they enjoy.

note: there is also a rumor aobut FXG files but I haven't tried yet but promises to be better the AI files.

Performance Optimization on Phone 7

A preview of an article I wrote for Code magazine. For the rest you'll need to wait for the magazine to come out. (oh and this is the unedited version so don't get to upset about things like passive voice or other what I call minutia)

For those of you that know me, you might wonder why I would be writing an article on Performance Optimization for Phone 7, I mean sure it’s Silverlight; and phone 7 has this coolness factor but I always talk about User Experience right? So what gives you ask?

Well when it comes down to it, without performance you don’t have much to experience. The dirty little secret is that performance optimization is a critical often ignored part of good user experience design more so when we are talking about a device barely bigger then a pocket calculator. Time and time again I’ve seen user studies where users see nothing changed for 2 seconds and they navigate away or otherwise assume the application is broken or the device is broken or the web page is broken. Users have no patience and the worst part is that 99% of performance optimization is… wait for it… managing user expectations or in other words ‘perceived performance’

Perceived Performance

Perceived Performance, what is that all about? Perceived performance is the difference between letting the user know that your app is doing something (by say using a loading animation) verses just a black screen. In fact much of the requirements around getting Windows Phone 7 applications into the market place are about perceived performance. Take the preloaded image that is included in your default project, if you don’t have one of those preloader images in your application then your application had better be bleeding fast or no market place for you. Applications only get a few seconds before they have to be up and loaded. For building ‘perceived performance’ and a great user experience start here with a custom preloader. Don’t just go with the default from visual studio either:

Figure 1: Default Splash Screen Image From Visual Studio

Start by building anticipation on phone 7 for your application with making this default preloader screen cooler or more ‘engaging’. You’ll note that in the default project this file is called ‘SplashScreenImage.jpg’. When you edit this file make sure it stays a ‘JPG’ too. JPG rendering on phone7 is much faster than PNG’s and certainly don’t stick other formats on your phone. The one exception to this would be using PNG’s when you need transparencies for example when making app bar icons. Here is an example of a great preloader that builds anticipation:




Figure 2: Customized Splash Screen Image

In this case the user is so caught up in the preloader that in this example the user generally wants to figure out how to get back to this preloader screen. Not only does this build anticipation but the user is generally so engaged that they don’t even notice the slow load and even might complain it loads to fast.

Perceived performance is about engaging the user quickly even if you app isn’t ready and this was one example. If you expect to sell your app your UX (User Experience) needs to be more than just a pretty face it needs to be highly optimized even if that just means perceived optimization. Let’s look at other ways we can make our apps scream.

9/10s of the law

Perception is 9/10s of the law figuratively but after the splash screen what is next? After your splash screen or preloader is thrown up on the screen next your app has the chance to load. Making sure you app loads quickly is critical again to over all perceived performance. In practice this means that your constructor should not execute more than it needs to quickly get something up. If you start some doing some huge work in your constructor then you are going to quickly start blocking your UI. Don’t do real work in the constructor as this will slow your UI loading. The less code between your preloader image and the app the better, but you ask what if I have a real app that needs to do real work?

Ok fine you’ve written a real app that needs to do some real work before it start working. Again part of managing user expectations is about ‘perceived performance.’ This doesn’t mean your app can’t do real work on such an under powered device (compared to my dual proc quad core 64-bit, liquid cooler desktop dev box), it just means you have to do it more intelligently. Our first real trick in learning to do this other then learning what not to put in your constructor is to use elements that are pushed onto the composition thread to keep people waiting.

What? Composition Thread? What is that about?

Threading on Phone 7

A big part of performance on the phone 7 is understanding the threading model. On the phone 7 we don’t get back ground process’s that we can run when our apps are not on the screen but we do get a few tricks that allow us to do some simple threading in the app. Basically on the phone you have 2 threads, the UI (User Interface) thread that is basically your app plus you have can some user defined threads but you also have this idea of a composition thread which you don’t have direct access to but you can take advantage of.

What is cool about the composition thread is that it is not blocked by the UI thread. If you have work that can be done on the composition thread it can continue even if your app is completed blocked via the UI thread doing some huge work. Typically you might have a waiting animation or a progress bar when something like this happens.

Say our app is loading something and we block our UI thread so we and the default progressbar control that is build into the Phone 7 Silverlight framework like this... (the rest will be in Code Magazine)

Why Use the MVVM Pattern with Silverlight Applications?

The probability of hearing or reading about the title question of this article if you are either a Silverlight or WPF developer is substantial. However, there are significant problems when searching for a proper answer to this question.

To begin with, there are numerous and varied ways in implementing methodologies like MVVM, most of which are used based on personal preference. To a novice trying to educate themselves, this leads to disparity in information. Complicating this factor is that many of the articles or videos that attempt to describe the MVVM pattern also include components of other architectural patterns. This adds unnecessary complexity to understanding the MVVM pattern because of the inconsistencies in the pattern being described. In this article, I will elucidate only the MVVM pattern - nothing more, nothing less.

First of all, let me answer the title question succinctly. Silverlight (XAML) and the Model-View-ViewModel (MVVM) architecture evolved together, thereby affecting each other. In effect, this means that inherent in Silverlight's framework elements and CLR objects are the mechanisms to implement MVVM's loose coupling and separation of concerns. I will go into greater detail on the specific classes and objects in .NET that are primarily involved in hooking everything up further on in this article.

The loose coupling and separation of concerns translates to the ability of large developer teams to work independently on different parts, bringing the pieces together at runtime utilizing classes or object interfaces (as opposed to user interfaces). Another enormous benefit of this is that not only can multiple developers work on different parts of the application simultaneously, designers - for the first time in the history of .NET development - and developers can work on the same code at the same time. Having designers "speaking the same language" as developers solves the longstanding dilemma of a developer taking what the designer gives them and having to rewrite everything to work with the applications. Furthermore, designers - for the first time also - can see what they are doing with data driven controls in the design view in Expression Blend. It's evident that the workflow between professional graphic designers and application developers has been monumentally improved.

Let me back up a bit and give an overview of what MVVM is and does for those of you who aren't familiar with it. MVVM, as architecture, is the mature, successful version of what n-tier attempted to accomplish: quarantine the user interface from the program logic and data. Where Model-View-Controller (MVC) may sufficiently accomplish this goal for ASP.NET applications, MVVM is a refined evolution custom-fit for Silverlight.

There have been intermediate patterns between n-tier and MVVM, all with the same goal, but none of them truly accomplishing the objective until the advent of MVVM and XAML. XAML, being an extension of XML, is inherently tool-able, resulting in the ease of building visual and other editors for those who use it.

If a new Silverlight developer were to dive into a new project without knowing better, they might attempt to put all logic into the codebehind of the MainPage.xaml.cs, as typically has been done in ASP.NET pages. Not only would this lead to difficult testing scenarios, but this methodology doesn't lend itself to long-term maintainability or extensibility. Testing code built like this needs a user interface (UI) to run and a human to debug, which adds to the complexity of finding errors. On the other hand, by using the MVVM architecture, only the "ViewModel" (which will be explained in the next couple of paragraphs) need be tested and verified before ever being bound to the UI.

Properly using MVVM, there is much less codebehind in MainPage.xaml. This is simply pure UI. Each entity in MVVM has its unique tasks, and they do them extremely well with complete separation. MVVM is an acronym for Model-View-ViewModel; let's elaborate on the functionalities of each entity.

At the uppermost level we have the "View". Ideally, the view consists only of the XAML UI and related UI logic. These are the Silverlight screens that are presented to the user. The View's responsibilities are to present data to end users and collect data from end users, period.
At the lowest level we have the "Model". This represents the entities that live on the server as well as the objects that are responsible for interacting with the data stores the application uses along with data persistence. Data interaction in Silverlight can be anything from RIA Services to web services or raw XML. Any CLR-object can be the binding source.

In between these two entities is the "ViewModel". This entity's responsibilities are numerous, but can be summarized as aggregating data that will be bound to the View, retrieved from the Model. This includes methods and states. Since Silverlight doesn't databind to methods, just properties and dependency properties, most of our data logic needs to be in property setters and getters in this ViewModel.

As previously promised, now I'll explain the specific objects in the .NET Framework that are involved in making MVVM and Silverlight work together. The binding mechanism in Silverlight links the View and ViewModel through primarily dependency properties and data context. Each framework element in the View (controls, UI elements, etc.) has a dependency property. These properties can be bound to instances of exposed public properties in the ViewModel. The ViewModel can update the View via the INotifyPropertyChanged interface in the ViewModel base, which is used to discover if the value of the properties have changed by raising the OnPropertyChanged event. This is a two-way conversation that extracts all of the data and logic from the View, but doesn't alter the UI's normal functionalities.

Lastly, I'd like to describe one last tremendous benefit of utilizing this pattern. Because all the logic is in the ViewModel, this entity can be copied from a Silverlight application and inserted into a WPF or Surface application, for instance. This cross-platform extensibility greatly increases return on investment (ROI) for companies that target multiple platforms.

- By Kim Schmidt, Guest Author from the Silverlight Group

Windows Phone 7 UX with David Kelley (thats me)

Had a great time talking about phone 7 ux this morning on MSDN Radio doing a podcast. Here are some great phone 7 resources related to touch and UX:

Phone 7 Links:
http://developer.windowsphone.com/windows-phone-7/
http://www.windowsphone7.com/
http://www.mobileappmatch.com/?fbid=IzTBJbx-cNj

Josh Blake as a great book on multitouch: http://manning.com/blake/ or http://nui.joshland.org/

http://www.Silverlight.net/
http://www.SilverlightCream.com/

user groups:
http://www.interactseattle.org/
http://www.SeattleSilverlight.net/

Other UX blog links that are cool:

teasers and trasitions

early ux phone 7 concepts

Windows Phone 7 Series User Interface (UI) codenamed “Metro” Design and Interaction Guide

Metro UI The Windows Phone 7 Aesthetic

Its Ok to Think Out-Of-The-Box

It is ‘Ok’ to think out of the box, at least we keep telling ourselves that. I know we always talk about thinking out of the box but frequently this tends really be ‘think out of that box as long as it’s not too far out of this box’ so just use a different box and stay in it. Begs the question how to really think out of the box and how do we let ourselves know its really ok to do that?

Case in point was a project we did recently where we were tasked to build a touch wall for Nike Basketball and the World Basket Ball Festival in New York City. One of the key elements was this idea of helping people (ie targeted demographic being male ages 14 to 35) connect with the history of basketball. The idea of the ‘history’ of anything in most ideation processes is going to bring up a time line. How boring is a timeline though, been there done that. This story is abit about how we broke out of the mode of a stereo typical timeline but still be a timeline and not some other metaphor that is been overly used like the carousel or something like that and therefore how we really thought out of the box and allowed our selves to do it.

So how can we let ourselves think out of the box ‘more’ better [yes yes I know English, it’s just more fun this way]? With that let us talk about 3 points on how we can better enable real life out of the box thinking without limiting out selves to preconceived notions and build really sexy User eXperiences (in this case all about basketball) and be ok with it.

Emotional Connections

One of the biggest problems we have as User eXperience professionals is: understanding our users. Do we really understand them? Have we bothered? Do we think we understand them but not really? Being open to the fact that you might not, as a team, really know your target demographic is a good start to not just thinking out of the box but being able to let yourself think out of the box. In doing so how then to you really know your users and in that how do we know we know? I would argue that we must always be in a mode of trying to better understand our users as they are diverse and ever changing and as soon as you think you know them you don’t, so therefore don’t stop getting to know them.

More than anything then you need to learn to connect with them emotionally and through constantly working on that connection emotionally you can better use that connection and cater to it. Working with emotional connections with users gives us a basis for building UX that takes it to the next level and we can vet those against our users to gage how well we connect and we can see if our out of the box ideas will fly. The user then is the judge of our ideas and not our perceived notions about them.

When we are building UX it is important to keep this process of emotional connections with our users as this is how our ideas will be connecting and how our ideas fail. To really get out of the box that emotional connection is critical. Now the reason I chose to bring emotional connects up first is that this idea of emotionally connecting with users helps us in the other two points I wanted to bring up.

Communication, Communication, Communication

Remember when building awesome UX it is not just you. It helps me and my team at Wirestone to think of ourselves as a single unit. It is not the developers vs the designers, it is our team and us including designers, developers, information architects, UX architects, PMs, the customer, and even demographic representatives. Its all of us working together and as I’m sure you’ve heard if you have studied group or team dynamics at all the trick always gets down to communication. When we communicate and ideas flow freely in a positive non critical way where we can talk about them and try them out we always come out of with cooler better ideas. No idea is bad it’s the degree in which it is awesome that matters. When a group or team then understands the business goal, understands the ROI, the technology, the information and content and are passionate about what they are doing and then fully communicate openly freely and often then things always, always go better.

Let’s get back to that Nike touch wall thing I mentioned earlier. As it turns out this was a case in point where brainstorming with the entire team was really a key defining moment it this projects success. With content we clearly had a demographic that was passionate about the content but really we had 2 kinds of elements to present and the typical time line was just so over done and not unique and some one other then the designers and developers in the room suggested why don’t we just have two lines one for this and one for that… of course at first much of the team scoffed but it was the most unique idea and no one could think of a reason not to at least try it. Getting a sample of the content together and putting in to a dual timeline that would expand and grow depending on which elements were of interest was an interesting idea and when put in front of users it worked much to many of our surprises. Further with a slight bit of gratuitous movement we found that it made it easier for users to wrap their heads around the content and learn to explore making the new dual timeline metaphor easier to understand or in other words more ‘discoverable’.

Let the Users Decide

The key then to the Nike touch wall success turned out to be putting it in front of users and letting the user decide if it was cool or not. Frequently we jump to conclusions about our users that may or may not be true and truth be told nothing is better than putting the UI in front of the real users to see if a UI/UX works or not.

Part of putting your ideas for UI in front of users is for the team to understand who the user is. One of the key tools a lot of people find successful is to have personas or virtual people that personify your typical user. This method also makes it easier to help other understand the user your team is targeting and help is finding real life version of the user. Even informal UX testing helps and in fact in our case we use some informal UX testing up front and additional more formal UX testing at all phases of the project to help let the user’s guide our creativity and our thinking. When we put our ideas in front of users it helped us focus on what worked best and in fact find the out of the box ideas that really worked.

Summary

That all being the case, letting ideas flow and putting all of them or the most unique ones in front of users can help bring focus to the out of the box thinking, where the entire teams is involved and no idea is left un vetted in front of users. Why is it ok to think out of the box? The reason is you will find the next best idea waiting for you and through that idea and the emotional connect with the user that you understand your UX will more likely hit the mark, be out of the box and a home run metaphorically speaking. Thinking out of the box requires that you let yourself as a team be open to all ideas, to give them serous configuration and let the user decide for you. Go forth and think out of the box (well at least head in the right direction). Like anything it takes time for a team to get up to speed and a willingness from everyone on the team to work together with novel techniques like ‘communication’, ‘brainstorming’ and the like. Here is hoping to see your next Hot and Sexy User eXperience…

also published at: http://www.interactseattle.org/?p=704