Got an email this morning from one of our talented designers who has a ton of Flash/Flex experience and is interested in joining our “UX Integration” team. He wanted to know what was the most important stuff to be learning.
A bit of background, at IdentityMine we have 4 major roles contributor roles in the app development process. Information Architects, Designers, Integrators, and Developers.
The UX integrator is the guy who sits between the Developer and Designer and can talk both languages ( design “geek” and developer “nerd” ). Unfortunately as of late this has been called the “Devigner” or “Deseloper”. Both don’t really work for me on my business card and since I lost the arm wrestle to get my title to be “User Experience Ninja”, the title User Experience Integration Developer or User Experience Integration Designer is what stuck.
Along the axis of the skills spectrum from Creative Designer > Technical Designer > Creative Developer > Technical Developer, the Integration Designer is the Technical Designer and the Integration Developer is the Creative Developer.
A UX Integration Designer typical comes from a design background and knows some code (enough to be really dangerous). These cats are usually the best candidates for facilitating workflows in a Designer to Developer Direction. Meaning they can take design assets from the standards in the industry and convert those to XAML or functioning Expression Blend projects.
A UX Integration Developer is the dude (or dudette) who usually has a Compute Science background but has a strong empathy for users and a passion for good user experiences. (Coincidentally this is pretty much the criteria for working at IdentityMine… Love your software! ) This person excels in the Developer to Designer communication. In other words this is the guy who knows how to take Dev created UI and make it beautiful.
On the UX Integration team each role strives to get better at what they are good at and to aim for the other side of the spectrum. An Integration Developer should want to be a better Integration Designer and should be learning those tasks. And vice versa.
Ok enough already… So what did I tell the designer who wanted to know what to learn to become an Integrator?
1.) Start to gain a holistic understanding of the platforms… Know the feature set and be ready to see where the dots connect when you are looking at solutions.. (Designers are typically connecting the dots without this context and it’s a huge shortcoming). Try to discover every control in both Silverlight and WPF that you have never used before… They are all there for a reason because some customer wanted them… usually we end up working with those customers at some point and knowing about these controls is an ace up your sleeve. Knowing about Flow Documents and Annotations might not be something you use today… But if you know it tomorrow you are ready.
2.) Once you know of all the controls in the platform the next step is learn to “style” them. This means learning to do simple styling as well as deep “templating” where you completely reconstruct the visuals. Its really important to get your head around the concept of “lookless controls” it’s the magic of WPF/Silverlight and basically means that a control has functionality but not visuals… so that any visuals can be mapped to that functionality later on. The goal of learning to style the controls is to get you to a point where you can see a control and confidently say I can style that one… For example scrollviewer is complicated… it usually takes a day to learn how to style it the first time… The next time… about an hour.
3.) Start exploring different workflows from designers and IAs and Devs… This means to be ready to accept a handoff from these folks in a myriad of different ways… The key is to learn to be flexible. Everybody works in different ways and I’ve found more success in just accepting people’s hand off as is and providing key tips to those people rather than getting frustrated and expecting those assets to come “just the way you like them”.
4.) Learn to prototype fast… A key to our position is our ability to communicate interactive ideas really fast… These are the ideas that don’t communicate well on paper or in static mediums… As well 25 cent usability is our secret sauce. If you can test something out really quickly against real people and against “real” data you will be able to make alterations to the user experience on the fly that correct mistakes that are made at the envisioning stage.
5.) Learn from the other guys There is so much great thinking happening in the Adobe/Apple camps that it would be a tragedy to unplug from those worlds. Without being cliché lets do what they do and learn from their mistakes… It’s incredibly valuable to not reinvent the world.
6.) Of course learn your tools and learn the syntax.
Tools – Learn Blend… Learn it like a hammer… You don’t build a house with only a hammer… But you can’t build a house without one. The point behind tools is to be able to do things you couldn’t do before, and do things you could do before faster. Don’t expect your tool to be a silver bullet or holy grail. Once you accept that you will realize how amazing Blend is… warts and all. I crash Blend all the time and it never bugs me… Crashes usually make designers write Blend off as a tool. Don’t go there.
Code – (as in C#) is probably not as important as learning markup (XAML) is. But I still stand firm that learning code and XAML is akin to Michelangelo learning the technologies behind paint and marble… Had he not figured these things out he would not have had a lasting impact.
7.) Try to understand the concepts of different patterns like MVVM
This will give you a greater understanding of why apps are architected the way they are from the development side and give you some expectations.
8.) Learn to make decisions and measure success by asking yourself if you or your audience will “Love their software”?
If the answer is no start over again or keep iterating. Look for holes and incompleteness or hard edges in the experience. Try to soften the hard edges and fill in the holes. Learn how to simplify things by being more explicit or via reduction. This is the true value add of the integration role. (It’s also the hardest to define and learn)