About Scott Barnes

Strategic, multidisciplinary designer – Coder & User Experience Architect with an eye for innovation and pixel perfection. Not only as a former Product Manager for Microsoft .NET, Scott also has worked the breadth of clients (Microsoft, Billabong, Nike, Google, Adobe to name a few) and although my skill set is vast, my greatest expertise revolve in the worlds of Future User Interactive Design (FUI), User Experience Architecture, 3D & 2D design, Industry Analyst, Game development (worked on Teamfortress in the 90’s) and of course programming in over 9 different languages since he was 13 years of age (now 35yrs old). Scott can be contacted via scott @ this domain (hint riagenic.com)

Xamarin & Microsoft merger may yet prove useful to designers.

The .NET community has been fractured for quite some time when it comes to mobile development, and a large amount of hate debt has been banked as a result. Products like Xamarin have been given the appropriate amount of adoption because they have a more agnostic vision of how .NET could work in a truly x-platform / x-device arena.

However, the approach to date isn’t an easy stroll down success lane, as to develop a mobile app even with Xamarin you’re faced with two decisions to begin with. Xamarin “native” or Xamarin “Forms”, each having their own set of pro’s and con’s attached from a pure “developer-centric” perspective.

Next decision after that is how do you design for three platforms (*maybe two*) and still retain constancy – yes I said constancy, not consistency. On one hand designing apps to work inside iPhone is different to how they work in Android – but only up to a specific context (as tradeoffs and split thinking naturally then occurs).

In order to achieve this, you have to essentially begin the same set of compromises you would make with the web, forking your feature design/development vision to accommodate and absorb the various limitations imposed on each platform in accordance to the restraints Xamarin imposes on top (ie there’s an element of decay implied).

To compound issues further, you then have Xamarin not really adhering to the previous iterations of XAML (aka Avalon) and whilst it looks kind of like XAML, it’s really in many ways just XML with limitations (ie you can’t really animate with it using the same Storyboard composition as you once had with Silverlight/WPF and so on). Xamarin’s XAML is the panacea we want but isn’t the same.

Now you have to programmatically design your composition with either a designer’s comps on your second monitor as a guide or worse, the designer is over your shoulder offering feedback loop hell.

Xamarin failed thus abandon it?

Hell no, Xamarin has all the ingredients one would need to really get the .NET x-platform / x-device story going, in fact, I’m more frustrated at the post platform execution than its original foundation itself. The secondary parts above can easily be fixed provided there’s some stronger thinking imposed about how “creative influence” applies to the composition of design – that is to say, at what point does the designer have free control over composition without haggling with a developer on limitations artificially imposed due to what i can only guess at being resource allocation issues on Xamarin’s part.

This, in turn, means that one would need to approach the composition of a Xamarin vNext with the idea or intent of using XAML/C# marriage the way .NET gods intended. What that means to say is that if you took the same conceptual develop/design pipeline that .appx or .xap has today and applied this to Mobile development this, in turn, unites the developer & designer workflow under the one constancy based banner, which in return reduces less feature editing / design cut-aways.

Why is this important?

In 2007, we were faced with a mission to get Designers more engaged with Developers, and that’s why Silverlight/WPF was born. We had small amount of success but in truth, we were side-tracked on conflicting priorities and poor management to really dig in on that same set of problems. Today, the various technical platforms have shifted but the core fundamental issue hasn’t gone away, in fact, it’s gotten smarter about how the two worlds collide – sadly, Microsoft has never really gotten an invite to that discussion due to its retreat positioning.

Microsoft’s answer, in general, has been to remove the designer from the equation given its complexity, instead, they gave developers a cookie-cut style template titled “metro/modern UI design” (aka Paint by numbers developer art) thinking that if you reduce the composition of design to basic minimal aesthetics, you, in turn, reduce the burden or need to have a designer influence the creative process.

That strategy is an utter failure and I’d promote the theory that the reason why Windows Phone has failed as a product is solely due to the UI (given the phone hardware is perfect, development SDK is the easiest by far but the design integration .. too boring, too hard).

Xamarin merger with Microsoft now has the potential to reboot a company’s mobile strategy in a way that it needs more than ever before, however, if the two worlds continue to solely double down on “developers, developers, developers” that don’t factor in “designers, designers, designers” all we really have achieved now is a license model reduction, better Visual Studio support, stronger echo chamber but still a designer stalemate, resulting in continued “developer-only” circle jerk sessions.

Related Posts:

What I have learnt being a designer, developer and product manager.

It’s approx. 19 years now since I first earned payment for my ability to use a computer. In that 19 years I’ve had a vast number of different roles and some of them have been mentally draining whilst most have been constantly built around growth (i.e. learning from failures etc.). In this time I’ve come across a few things that we seemed to be destined to repeat over and over no matter how many places I work and how experienced my fellow computer horde members are.

Before I outline these let me start by saying I have been programming more in my life than at times I get to design and when I can’t get the designs I want from the design team, well, I always end up doing the actual designs anyway. I often find people that I work with can’t compartmentalize the idea or notion that someone can do both equally well as another, in that you’re always defending your position in the developer vs designer discussion. In reality you’re always nearly often asked “pick a side and stick with it” or face career penalties should you try and sit idle in the middle.

That’s however until I discovered the role of Product Management and what better place to learn that role than when I was at Microsoft. I mean I had some wins for sure but I spent a lot of my time watching absolute brilliant minds at work. In this role working others in this field, I learnt being a developer & designer had benefits as I was now able to look at both sides of the equation and get a sense of what my audience (.NET developers & designers) needed the most from us.

What have I learnt overall in 18 years?

Humans and Chunking.

Some would call this Agile but at the end of the day we humans tend to break things down into small pieces as way of coping with scale (kind of like Neurons in our body aren’t complete end to end cycles, they are really just iterative linkages of energy). Sure we build ceremonies around the problem and often swear “this is the winning formula” but in truth all we are doing is taking a really big lumpy problem and breaking it down into manageable pieces. There is strength in doing this but there is also problems that often outweigh the positives.

For instance in software I’ve noticed teams always almost get caught up in the idea that once you break an object into small pieces it becomes more manageable. In reality this often leads to context or peripheral awareness of the problem being lost due to the fragmentation.  That’s the issue it’s not the idea of breaking things down its when the breaking things down gets obfuscated or leaves others out it in turn gives the developer or designer a small amount of information to work from. This in turn creates problems as without context of the problem, intended audience or even why the problem should be worked on… well…. More problems emerge. To put it bluntly you always almost end up doing keyhole surgery – some can make it work others, end in a painful career stunting failure.

A Product Manager is like a Military General.

We often in the delivery teams (developer/designer) roll our eyes at times at the role of Product Manager. We at times have this distrust for anyone that can’t develop or write code to therefore be in charge of the products direction. Then on the flipside I’ve seen teams punish a Product Manager for having the development background because that person can’t resist from checking in on their code base and outlining solutions to problems before they arrive (oh btw, Scott Guthrie used to check name spaces on code before the devs could release…so don’t fault people for that!)

A bad or good product manager is like a General in an army, should they give you bad orders or send you down the wrong path you can easily take a winning high performance team and run them into the ground in under a month. It’s very easy to kill the moral of a development team under the vision or guidance of bad product management (including release management).

Release Management is the same as horoscope reading.

I’ve seen way to many teams be held hostage to a deadline they have little or no control over. Sure Agile processes get placed on a pedestal that is until the business throws a tantrum and says “I need it now” in which case agile will not be a safe haven to hide behind if it even hints at being a reason for delays.

Agile however is often used to manage this and it can work to hold back the release date demons but I’ve also seen Agile become this lumpy carpet in which bad product design or strategies hide under. It’s easy to bury a team with no thinking or strategy behind feature development as all you have to say is “We’ll iterate our way out of this” and unless someone in the room is sharp enough to catch them in the act (empowered as well), guess what…that beloved agile just became that noose around your career necks.

Agile also is a funny and interesting thing I’ve noticed in probably 8 years or so travelling around Australia/World. I’ve honestly never seen teams actually do it right to the letter of the law. I always see them cherry pick it to death and I’ve lost count at the number of times I’ve seen teams argue “well we like to keep it simple” as their rationale for its adoption hackery. I’ve also seen teachers of agile rant “You’re doing it wrong!” to which I now wonder if the builder blaming the tool is the right course of action here?

Suffice to say Agile + Release Management is always an amusing sociological experiment to witness. It often is in many ways like watching the TV show “Survivor” + “Amazing Race” inside the cubicle.

Design is on a pedestal until pressure builds.

As a UX person now (also now studying psychology), I’ve come to learn that we humans are actually quite adaptable to change and experiences. We often place ourselves in compartments and use personas as a shield to hide behind the various matrix’s that we assume or intend users to uphold. It’s as if we assume out loud that our users will self-divide into sub-tribes that fit in with our mental models around usage & expectations.

It’s an ongoing science HCI without any hint of complete understanding but in the mean time we’ll continue to evolve design in a way that hopefully proves probabilities and our internal monologues about what users like or don’t like in designs.

Design is the term though as at the end of the day despite all the research it comes down to the hand of a designer either using a mouse or Wacom graphic pen (most designers I know don’t use a mouse). We can craft the ideas or belief system but its not until these folks grind the pixels out that we have a well formed output that the users can appreciate and be drawn into.

Marketing also play a role in this and they’ll often want more influence or say into what the design composition upholds – in fact everybody wants input as because its visual this means everyone gets a say!. Yet nobody volunteers to have input in that line of code you wrote or even that decision you made around a campaign.

A designer is Queen/King that is until he/she accidently and stupidly shows the rest of the business what they made and then you watch a positive or negative feeding frenzy take place.  The feeding frenzy often however is used by developers as now they to have a safe haven to also hide behind as all they have to say out loud is “I can’t do design, so I can’t finish this until the designer finishes”.

Hiding behind that means they have to take no risks or never fail in both their execution of an idea or worse keep their efficiency returns high (i.e. why bother trying to do a design ahead of the designer when all it would mean is wasted time, time…in agile….time…you say)

What have I really learnt?

That despite all the knowledge and experience I’ve acquired over the years it’s really rare I see the business, technical and design equation balanced. Almost every company I’ve consulted with, worked in, contracted for and observed have always managed to have an imbalance in these three areas. If the balance tips in say technical favor it usually means business & design are at a loss and likewise if the other two do the same. You may find one or two areas where the balance stays true or looks balanced but it usually is a false positive as seemingly its usually the “design” that’s the one bluffing (ie crap design experiences being palmed off as “good enough”).

My theory or something I’m going to devote I guess the rest of my life to is finding a way or rhythm to debunk this equation in that there has to be a way to balance the three without cubicle combat.

Today I’d simply say this, if all three parties aren’t sharing the risk of change or failures, then that’s the starting point. In 20 years I’ve rarely seen all three take that on willingly and accepting that failure has rewards as well as losses. That giving a deadline to a developer is like yelling at a tornado to turn around, it may feel good to do so but you will always most certainly get creamed anyway.

A designer is the user advocate and they have instincts built in that are well honed towards how people deal with vast amounts of information & cognitive load. An Engineer can work in literal form better than lateral but a designer has only lateral so the balance has to be struck (form vs function wars begin).

Lastly a Product Manager without a 2+ year roadmap isn’t a product manager, they are just the business development suit running around pretending they are in charge of an empire that has enormous of opportunity that continues to go wasted. If you haven’t got a forward thinking General then maybe the competitor does and that’s why you seemingly keep looking at what they did for visual cues on success vs fail (Microsoft we agonized at Apple/Google/Oracles growth. I doubt it was a two-way process hence the huge leads they have gained in 8 years).


Related Posts:

Creating a designer & developer workflow end to end.


When I was at Microsoft we had one mission really with the whole Silverlight & WPF platform(s) – create a developer & designer workflow that keeps both parties working productively. It was a mission that i look back on even to this day with annoyance, because we never even came close to scratching the surface of that potential. Today, the problem still even with Adobe and Microsoft competitive battles in peace-time hasn’t actually been solved – if anything it kind of got slightly compounded or fragmented more so.

Absorbing the failure and having to take a defensive posture over the past five years around how one manages to inject design into a code-base in the most minimal way possible, I’ve sort of settled into a pipeline of design that may hint at the potential of a solution (i say hint..).

The core problem.

Ever since I think 2004, I’ve never been able to get a stable process in place that enables a designer and developer to share & communicate their intended ideas in a way that ends up in production. Sure they end up something of a higher quality state but it was never really what they originally set out to build, it was simply a end result of compromises both technically and visually.

Today, its kind of still there lingering. I can come up with a design that works on all platforms and browsers but unless i sit inside the developer enclosure and curate my design through their agile process in a concentrated pixel for pixel way, it just simply ends up getting slightly mutated or off target.

The symptoms.

A common issue in the process happens soon after the design in either static form or in prototype form gets handed off to the developer or delivery team. They look at the design, dissect it in their minds back to whatever code base they are working on and start to iterate on transforming it from this piece of artwork into actual living interactive experience.

The less prescriptive I am in the design (discovery phase) the less likely i’ll end up with a result that fits the way i had initially imagined it to begin with. Given most teams are also in an Agile way of life the idea that I have time or luxury of doing a “big up front” design rarely ever presents itself these days. Instead the ask is to be iterative and to design in chunking formations with the hope that once i’ve done my part its handed off to delivery and then it will come out unscathed, on time and without regression built in.

Nope. I end up the designer paying the tax bill on compromise, i’m the guy usually sacrificing design quality in lieu of “complexity” or “time” derived excuses.

I can sit here as most UX`ers typically do and wave my fist at “You don’t get us UI and UX people” or argue about “You need to be around the right people” all i want but in truth this is a formula that gets repeated throughout the world. It’s actually the very reason why ASP.NET MVC, WPF and Silverlight exist really – how do we keep the designer and developer separated in the hope they can come together more cleanly in design & development.

The actual root cause for this entire issue is right back at the tooling stage. The talent is there, the optimism is there but when you have two sets of tooling philosophies all trying to do similar or close to similar things it tends to kind of breed this area of stupidity. If for example i’m in Photoshop drawing a button on canvas and using a font to do so, well at the back my mind i realise that the chances of that font displaying on that button within a browser is less likely to happen then inside the tool – so i make compromises.

If i’m using a grid setting that doesn’t match the CSS framework i’m working with, well, guess what one of us is about to have a bad day when it comes to the designer & developer convergence.

If i’m using 8px padding for my According Panel headers in WPF and the designs outside that aren’t sharing the same constancy – well, again, someone’s in for a bad day.

It’s all about grids.

Obviously when you design these days a grid is used to help figure out portion allocation(s) but the thing is unless the tooling from design to development all share the same settings or agreed settings then you open yourself up from the outset to failure. If my grid is 32×32 and your CSS grid uses 30% and we get into the design hand over, well, someone in that discussion has to give up some ground to make it work (“lets just stretch that control” or “nope its fixed, just align it left…” etc start to arise).

Using a grid even at the wireframing stage can even tease out the right attitude as you’re all thinking in terms of portion and sizing weights (t-shirt size everything). The wireframes should never be 1:1 pixel ready or whatever unit of measure you choose, they are simply there to give a “sense” of what this thing could look like, but it won’t hurt to at least use a similar grid pattern.

T-shirt size it all.

Once you settle on a grid setting (column, gutters and N number of columns) you then have to really reduce the complexity back to simplicity in design. Creating T-shirt sizes (small, medium, large etc) isn’t a new concept but have you even considered making that happen for spacing, padding, fonts, buttons, textinputs, icons etc etc.

Keeping things simple and being able to say to a developer “Actually try using a medium button there when we get to that resolution” is at the very least a vocabulary that you can all converse in and understand. Having the ability to say “well, maybe use small spacing between those two controls” is not a guessing game, its a simple instruction that empowers the designer to make an after-design adjustment whilst at the same time not causing code-headaches for the developer.

Color Palettes aren’t RGB or Hex.

Simplicity in the language doesn’t end with T-shirt sizing it also has to happen with the way we use colors. Naming colors like ClrPrimaryNormal, ClrPrimaryDark, ClrPrimaryDarker, ClrSecondaryNormal etc help reduce the dependency of getting bogged down into color specifics whilst at the same time giving the same adjustment potential as the T-shirt sizes had as well – “try using ClrBrandingDarker instead of ClrBrandingLight”. If the developer is also color blind as in no they are actually colorblind, this instruction also helps as well.

Tools need to be the answer.

Once you sort the typography sizing, color palette and grid settings well you’re now on your way to having a slight chance of coming out of this design pipeline unscathed but the problem hasn’t still been solved. All we have done really is created a “virtual” agreement between how we work and operate but nothing really reinforces this behavior and the tools still aren’t being nice with one another as much as they could be.

If i do a design in say Adobe tools I can upload them to their creative cloud quite quickly or maybe even dropbox if have it embedded into my OS. However my developer team uses Visual Studio’s way of life so now i’m at this DMZ style area of annoyance. On one hand i’m very keep to give the development team assets they need to have but at the same time i don’t want to share my source files and much the same way they have with code. We need to figure out a solution here that ticks each others boxes as sure i can make them come to my front door – cloud or dropbox. That will work i guess, but they are using github soon so i guess do i install some command line terminal solution that lets me “Push” artwork files into this developer world?

There is no real “bridge” and yet these two set of tools has been the dogma of a lot teams lives of the better part of 10 years, still no real bridge other then copy & paste files one by one.

For instance if you were to use the aforementioned workflow and you realize at the CSS end that the padding pixels won’t work then how do you ensure everyone see’s the latest version of the design(s)? it realises heavily on your own backwater bridge process.

My point is this – for the better part of 10 years i’ve been working hard to find a solution for this developer / designer workflow. I’ve been in the trenches, i’ve been in the strategy meetings and i’ve even been the guy evangelizing  but i’m still baffled as to how I can see this clear linear workflow but the might of Adobe, Microsoft, Google, Apple and Sun just can’t seem to get past the developer focused approach.

Developers aren’t ready for design because the tools assume the developer will teach the designer how to work with them. The designer won’t go to the developer tools because simply put they have low tolerance for solutions that have an overburden of cognitive load mixed with shitty experiences.

5 years ago had we made Blend an intuitive experience that built a bridge between us and Adobe we’d probably be in a different discussion about day to day development. Instead we competed head-on and sent the entire developer/designer workflow backwards as to this day i still see no signs of recovery.

Related Posts:

I think therefore I know.

When you’re in a role of UX you tend to have contested territory marked out around you. Everyone around you has an opinion on something that fits within your charter so you in turn have to be the guarded diplomat constantly. I don’t mind heated exchange of ideas, when people get passionate about something they always stand their ground on a topic and make sure their voice is heard clearly and loudly (often without politeness attached). In these situations what I typically have echoing at the back of my brain is a question “do they think or do they know”.

I think something instead of I know something takes on a whole new set of discussion points because if you think something then its just an idea or assumption. If you know something, well chances are you have data points filled with confidence attached, this is good, this tells me straight away there are more clues to be found.

“..The only way you win an argument is if you get the other side to agree with you..”

Is what my dad would say when he & i used to get into the thick of it. Its a fairly simple statement as in the end when you have two opposing ideas on the same problem, well it comes down to either compromise or an impasse. If its an impasse then it probably will come down to the title you have on the day, in my case being Head of User Experience. A title like mine carries some weight that means i can ignore your opinion and proceed onwards without it, but doing so means that i need to qualify my arrogance more.

Being the top-dog in UX land isn’t an excuse to just push past people on their “I think” statements and supplant your “I thinks” ontop. Instead what it means is we have to be more focused on establishing the “I know” statement that absorb the two opposing ideas. My way of thinking is this, when I reach a point where there isn’t any data to support the opinions / ideas its now a case of writing multiple tests to get them fact checked and broken down until we do have the ideas transformed into behaviour facts.

I think the users will not like the start menu removed so don’t touch it.

Now lets remove the start menu is my immediate thought, screw the statement what happens when we do it. I’m assuming there will be some negative blowback but can you imagine the data we can now capture once its removed and how the users react. The users will tell us so much, how they use the menu, where they like it, why they like it there, who they are, what they use and so on.

That one little failure in Windows 8 is a gold mine of data and online there are discussion forums filled with topics / messages that centre around “ I think “ but nobody really has “I know” except Microsoft.

My point is this. If you’re not in a role that has User Experience in its title then fine, knock yourselves out with the back and forth of “I think” arguments. If you are in UX your job is to not settle with “I think” and instead hunt for “I know” for you will always get rewarded.

Related Posts:

How UX & Ethnography mix.

Inside most organisations you’ll likely see a marketing team distill their customer base into a cluster of persona(s), which in their view is a core representative of a segment of their audience in a meaningful & believable form. These persona(s) are likely to be accurate or moreover a confirmation on a series of instincts that may or may not have supportive data to underpin their factoids. The issue with these personas is that they are likely to be a representative of the past, that is to say using them isn’t really about transplanting their behaviors into the future, instead its a snapshot in time of what happened at the time they were documented.

The definition of Ethnography basically distills to what i’d class is happening in the persona research space, especially when you commission design agencies to do the research. They are usually quite thorough in their research and often don’t miss a step in cataloging the series of data points needed in order to build a picture as to whom they are looking at and what the behavioral traits the persona(s) in question are likely to have in a range or clustered form.

Downside for UX people like myself is there’s no real jump off point for this type of data, as for me, it’s not really about whether or not “Max” is prone to water-sports or is in the age bracket of 25-35, i have really no need for excessive metadata. The challenge for me is to map these series of personas back into a timeline of graduation both in simplicity vs complexity but also around how their confidence levels are organised in a way that outlines the cold/hot spots within a feature(s) experience needs.

If you were to take a feature, break it down into its intended audience, complexity required to use it and lastly its overall metrics that help define its success/fail  – well you’d likely end up with a lot of moving parts that don’t offer up any tangible qualitative value that helps you at the very least sniff out “what just happened”. What if you instead take the marketing personas, take a guesstimate around who you’re targeting, the features likely markers that trigger the metric and infer based on this data, the outcome – this would in turn be called confirmation bias.

There’s the uppercut with Persona(s) as you can easily set out to build on a solid foundation of healthy data but it’s only when you transfer or map these series of data points to the actual set of features & content within an experience that it starts to unravel and threads of its truisms get caught up in a lot of inferred guesstimates.

The root cause for this failure in qualitative data is simply due to the past being used to dictate the future, again remembering that at the time you interviewed and inspected your persona(s) it was based on either “what if” or questions that point to competitors or existing experiences that are already set in stone. Today and tomorrow you’re not keeping those experiences locked like that, in fact you’re probably looking to move the needle or innovate in a different direction which means you have small to large impact on their behavior, so thus the experiences can often involve dramatic or not so dramatic change(s). The only way to test or baseline the change is to have this continuous sampling that keeps checking & rechecking the data points in the hope of change makes itself prominent.

Problem – change isn’t always obvious, it can be subtle, the slightest introduction of a new variable or experience can often lead to adjustments that go unnoticed. I’ll cite an example in abstract form.

A respondent is asked to walk on a path through a forest from A to B. The respondent is asked to count how many “blue” objects are lined along the path, and the said respondent’s heart rate will be also monitored (also base-lined / zeroed out). Before the respondent takes off the testers place a stick that has similar shape to a coiled snake midway on the path.


The respondent is then asked to proceed on the journey, and they begin to count the blue objects and at the end of the path when they arrive, they give an accounting of their blue object findings. Their heart rate was normal in line with normal physical activity.


Respondents were less likely to notice the stick.


Next round of respondents are asked to the same, only this time the seed of fear is planted in their subconscious with “oh others noticed a snake a few hours ago along the path, be careful and if you see it sing out, it should be gone by now and we couldn’t find it earlier so just take note”.


Respondents begin the journey on the path, they notice the stick initially and a lot of messaging between the optics and brain are moving at lightning speed trying to decipher the pattern(s) needed to place a confirmation on “threat or non-threat” levels. Heart rate is spiking and eventually they realize its a stick and proceed, as they walk past the stick still keeping a very close eye and proximity buffer between the stick and them.

The point of that story is this, that with an introduction to the standard test of a new variable (fear) you’re able to affect the experience dramatically to the point where you’ve also touched on a primal instinct. In software that “stick” moment can be anything from moving the “start button” on a menu through to moving the way a tabular amount of data has been traditionally been displayed.

As a User Experience creator, we typically move the cheese a lot and it’s more to do with controlling change in our user(s) behavior (for the greater good). Persona(s) don’t measure that change, all they measure is what happened before you made the change. All you can do is create markers in the experience that help you map your initial persona baseline back to the new in the hopes it provides a bounty of data in which “change” is made obvious.

It doesn’t… sadly… it just doesn’t and so all we can do is keep focusing on the past behavioral patterns in the hope that new patterns emerge.

Persona(s) aren’t bad, they aren’t good, they are just a representative sample of something we knew yesterday that maybe still relevant today. The thing i do like about personas from marketing folks is this, it keeps everyone focused on behaviors they’d like to see tomorrow re-appear and that in the end is all i ever really needed.

Where do you want to head tomorrow?

Last example – NBC Olympics were streamed in 2009 to the entire US with every sport captured and made available. At the time everyone inferred that an average viewer would likely spend 2mins viewing time. In actuality they spent 20mins average viewing time and sent massive ripples in the TV/Movie industry in terms of the value of “online viewing”. If we had of asked candidates back then both as content publishers and consumers, they’d probably have told us data that they asserted to be relevant at the time. In this instance the Silverlight team were able to serve up HD video for the first time too many people online, and that’s what changed peoples experience. Today, its abnormal to even contemplate HD video streaming online as anything but an expected experience for “video” … 5 years ago, it didn’t exist. Personas compared to then and now are all dramatically different now, so while change can in some parts be slow… they can easily expedite to days, months as well as years.

I don’t dislike Persona’s, i just remain skeptical always of the data that fuels them – but thats my job.

Related Posts:

When a Product Manager of legacy confronts UX.

 UX meets Product Management...

I’ve been sitting on this blog post for quite some time trying to articulate how I see the two sets of roles interacting and co-existing with one another. I’ve been in both these roles both separately and collectively and it’s really a puzzling uncomfortable experience.

The problem today, is simple – UX has traction and before we all start high fiving each other on this victory, we still need to reconcile how this whole thing is going to work.

Today, typically UX is a huge challenge for product teams to invest in, especially if they are deeply entrenched in legacy solution(s) that range in age (5-10 years old). The challenge isn’t about providing “reasons” to go full UX, as anyone who’s picked up a tablet/smartphone will get the reasons immediately.

The real challenge lies in the “how” do we move away from this old way of doing things to the new way of doing things that are often filled with “excuses” or “nostalgia” fuelled ranting. Moving forward with the times is hard enough but even more so when the reaction to UX is to just “hire” some UX person to dig everyone out of the hole they are in without a strategy being in place to begin with.

As a UX Architect it’s somewhat more of a challenge for me than it was being a Product Manager, as in this role my job is to provoke teams into taking an introspective look at how they have arrived at where they are at today – chances are the very people in the team haven’t always been there through the whole journey either.

If you ask a team three simple questions “What features do you have right now?”, “What’s working and what’s not working” and lastly “what do you want to do tomorrow?” well you get some pretty awkward frustrated looks (greenfield projects obviously it’s not the case). As really what I’m asking is “do you even know what you’re doing right now?” and it’s a pretty intimidating question as it forces people in that space to admit “well…not really..

As a Product Manager you’re really there to help steer the ship in a direction that has usually momentum attached and having some upstart UX guy make you sit down and account for what you have usually isn’t an appealing process given well “that’s the past lets talk about the future!” is the vibe at the time.

We don’t ask these questions of status quo to weaken the position of the team or detour them from the future, it’s really there to give us all a platform to build up from. If they can answer the questions that means they are ready to start attaching “features” to “personas” so then we now have a better understanding of who owns what feature and why, which then leads into how you can take the said features and distribute them around various flavours of devices/desktops etc.

Product Management and UX go hand in hand and the danger of a UX role is they could very easily become a Product manager, as its very easy to slip into this role especially if the current status quo doesn’t have a strategy on where they are going or how they arrived at the point in time they are in today.

In summary – A UX role has to sit down unpack his tool kit, and simply break down the product back to its grass roots, force the team to sit down and focus on what they have right now and what they want to take from the past into the future while at the same time create “new”. It’s not as attractive at times but it’s the reality that must be faced otherwise you end up like Microsoft did in the past “oooh look shiney object, let’s go make it and screw what we have right now” (aka Silverlight/WPF strategies to date! :) )

Related Posts:

Windows 9 – replacing it with a triumvirate of products

This morning I saw a question posted to the local OzDotNet mailing list I subscribe to (i love me some DL action).  I thought I’d keep this response on my blog for two reasons – I love the sound of my own voice (dah) and this is starting to become a default response I keep giving over and over privately and in parts publicly?

I have noticed in a few places discussions comparing the UI and API of WinRT with Silverlight, and suggesting that it (WinRT) is preferable. Mostly, these were quite old posts (a series of 6 or more at SharpGIS was my first sense of this).  

It does raise the possibility that Windows / Microsoft will rebirth or rethink some technologies.

Related (in my eyes, anyway), apparently there is a wider discussion about Windows 9 (based on leaks and conjecture) suggesting that there is to be a complete rethink of Windows market segments in Windows 9 “Threshold”.

It’s summarised here in InfoWorld (December 2013) in an article by some bloke named Woody Leonhard.

He sets the tone in his first sentence:

“If independent leaks are to be believed, Windows chief Terry Myerson appears to be dismantling the Jekyll-and-Hyde monstrosity that is Windows 8, instead replacing it with a triumvirate of products that people and companies will actually want.”

I’ll be interested in Scott’s comments on the triumverate of products, including the quote that refers to Terry Myerson’s supposed intentions.


My thoughts/Reply

I don’t know much about the future of Microsoft because I suspect not many INSIDE Microsoft themselves have a clear definitive handle on that (not to sound jaded, i honestly do believe they are still haggling over how to raise the broken into fixable solutions).

I would say this, the company has built up enough equity in the past to make a full focused run at Consumer adoption for products that would typically sell reasonably if not better in enterprise/smallbiz but they in the end hit a wall. I think it was mainly they didn’t understand the consumers needs and were to busy trying to graph compete strategies they have used on Enterprise into the same space as consumers (Internally Microsoft can be quite aggressive and paralysed with fear around competitive events – its a huge weakness imho).

If you were to unpack Windows 8 today and really take a step back from it all, there’s not a lot of negativity associated with what they have done. I look at Windows 8 as the parity release between Silverlight/WPF and all the fixes customers (devs) wanted but it was delivered in a way that traumatised the base. It could have been delivered with a softer approach to change management in that instead of holding a gun to our collective heads with the intent of “upgrade or else” simple things like namespace / sdk related issues would have been enough to build confidence with the developer base around migration / roadmap. A developer would be fine with with Windows 7 WPF/Silverlight development today provided they know eventually with a Windows 8 upgrade the performance and scaleability issues would naturally resolve themselves (ie devs dont spend to much time haggling over the rendering pipeline).

If you then combine Windows Phone 8 (which is really still in many ways the Silverlight behaviour) you again then tick the other box around reach on mobility devices. You are still locking them down into a world called “windows” which doesn’t piss a lot of enterprise companies off, especially with the current turbulence in the device market we see today. Enterprise companies right now are a little paranoid or scared about their mobility adoption strategies because its one thing to say “I want breadth” and another to say “i want breadth and depth’ when it comes to User experiences that count. If a company wants to get their “mobility” story together, they often associate mobility with web because breadth is far more attractive story than a depth discussion. Breadth means HTML/JS because it means I don’t have to have specialist teams (Java, ObjectiveC, C#/Mono etc). Depth requires the opposite because you can only put off that problem for so long before someone within a team suddenly comes to work wearing his/her “Java Conference 1998” t-shirt and smells funny because they do Android development.

Microsoft had an opportunity to do a simple rinse/repeat on the “Embrace/Extend” model with Windows and like I said, Enterprise would likely have been fine to play in that sandpit (of course they’d keep pushing on the “make my C#/XAML apps work on all” angle every step of the way).

In keeping Enterprise bellies full that would have stabilised at the very least their largest piece of the profit share pie, in that they would have bought themselves another 2-5 years to focus on Consumer more without having to pay the tax on losing hearts/minds of business grade solutions. This would have also given them more adoption metrics around the mobility + desktop upgrade story because if a company buys 10-100 units of one piece of hardware because it was easier to develop against well thats 10-100 forced adoption(s) on users which after a while could turn into positive/negative evangelist for those products (Forced adoption is not a bad strategy …its just ethically horrid).

But.. sadly none of the above has happened, instead Sinofsky wen’t rogue, went aggressive not just internally but externally and let his own self-inflated arrogance steer the ship in a direction of aggressive change management which has backfired. Now the new heads of state have to figure out how to salvage what they have left into meaningful pieces that can essentially tap into the above behaviours.

The article is right, you have really three options – fade out you core business (enterprise) and go full retard on consumers adoption, reverse the namespace/SDK engines and build a bridge between old and new but lose what small foothold you have on consumers  – or – abandon consumer focus and retreat back to safety around enterprise/small business.

I’d place my money on the 2nd option, bridge building but that’s going to be filled with a lot of apologies and the only way they can even attempt to make that work is to ramp up their DPE practices beyond where it is today (that is a lot of people on a lot of planes, apologising and seeding a new/existing audience with solutions). The head of DPE (former CEO of Skype) is a business development numbers guy who clearly has no real passion for DPE, so i don’t see how even if they find a way to build that bridge can make that happen (it’s an attitude issue as well as a technical one).

Building a bridge between old and new is not as scary as one would assume (well i don’t anyway), there is a lot of positive work put into the Windows 8 SDK’s .. i don’t think anyone can say out-loud that Microsoft doesn’t get their shit together technically when given the chance, there is and has always been more positives in their technical abilities than negatives – it just always always always comes down to the way in which they deliver the message and react to developer/customer issues of the day.

Is it really a case of just refactoring Windows 8 namepsaces or proxy classes of some sort to convince Developers to continue on WPF/Silverlight path? … Is it a matter of just investing more in that “devigner” tooling problem (Expression Blend makes a comeback but with less reliance of “reflection” based property grids).

*shrug* .. i can personally see a way they could rebuild and get on with the Windows 9 approach and I don’t think it requires a radical overhaul but more architectural common sense.

Related Posts:

A lesson in humility from my son.

I had one of those moments this morning on the way to work. It was a moment that I’m still trying to fully unpack in retrospective because at first It was me trying to teach him how to be a man, but what really happened was he taught me what it takes to be one. It was one of those double wins.

My son has a really rare condition called Trisomy 8 – 128 kids have it world wide last count and usually about 100 of those don’t make it. Every day we have Corey with us is a day that I’m reminded how lucky and grateful I am to have this kid in my life, and moreover how despite all things he has going for him he still isn’t out of the woods yet – this each day is a gift.

This morning he saw a disabled man hobble across the road and despite all the surgeries, difficulties and social issues he faces daily he still looked at this man as being a lesser – not in a malicious way but in a way of empathy and pitty. It initially made me a little angry because my dad always taught me that a disability is extra weight on a person, much like a racehorse gets in a race. They still face the same challenges as us, but they are weighed down with extra to make it harder for them but we’re never to treat them any different. I wanted to pass this kind of thinking onto my son, to push the idea that you remember that people aren’t normal, some just hide it better.

This is my best moment with Corey to date..

Corey and I

*Corey watches disabled man with shorter leg than the other and hooked arm walk across the crosswalk on the way to school this morning*

Corey: Dad… what’s wrong with that man ..

Me: Well ..his body umm..his body isn’t the same as other peoples so he’s got some difficulties in walking so that’s why he hobbles. His arm probably wasn’t made the same as yours so it hooks in like that.

Corey: oh… poor man dad.. you should help him by like giving him a lift or something.

Me: …hmm… Let me ask you something, do you think that man is strong?

Corey: umm…strong like you …no…

Me: Well.. the thing is buddy, that man is probably the strongest man you’ll see all week. Think about it, he has all these problems with his body but he still gets up every morning, gets dressed, puts his backpack on and walks to the bus. He then goes to work and keeps doing that day in day out. That’s pretty strong.

Corey: ohhhh ok…

Me: Corey you have only one eye left you can see out of, you find it hard to speak your mind because your brain works faster than your mouth but you still get up every morning, try and sneak in a computer game or two before mum & i catch you and you go to school like that man. Does that mean both of you are now not strong?

Corey: No… I guess… i didn’t see it like that..

Me: Remember this moment mate, because people may look at you like you looked at him at times but remember that being strong isn’t about lifting heavy things or being able to fight people.. being strong is about getting up and facing the day by not using excuses on why you shouldn’t do something.

Whenever a kid teases you next time at school remember that they have all those abilities you and that man don’t have but they still aren’t happy and think that by making you feel bad is a way to be strong… when..well they aren’t, they are weak and lazy.

Corey: So …they are losers right..

Me: kind of, they are ignorant..

Corey: what’s that mean.

Me: it means they don’t know better, so next time it happens, just remind them of the difference but at the end of the day remember you don’t make excuses, you just get on with it.

Corey: ok…

Corey: I like this redstone book you bought me…

That pretty much happened word for word, and the thing I love about my sons attitude to life is that despite being dealt a really shitty hand he’s like a rhino, thick skinned and focused..nothing really gets him down, he just see’s life through the eyes of curiosity… and minecraft… mostly minecraft..

Related Posts:

  • No Related Posts

I refuse to believe that the entire planets best idea of the day is JavaScript.

There isn’t a day that goes by where I stumble into some random blog post, comment, remark, argument that involves JavaScript lately. It’s as if the entire quagmire of its existence is trying to ambush me with wave after wave of interpretation of why it’s important… i’m under JavaScript siege and now it’s time to go all Die Hard on it.

Here’s my notes

* Plugins were evil, JavaScript is the web’s future.
Plugins made a strong point to the interwebs, it said loudly “Hey browser’s stop trying to hijack developers to your greedy needs and if you want to sit around waiting for a committee to make a decision, fine, but me.. i’m going to give that guy over there HD porn…”

Fact is products like Java, Flash and Silverlight (the “evil three”) were the service pack the web needed, it needed to prove the point that developers aren’t getting their fill of API  / multimedia needs with the slow latency filled migration patterns we (sadly) still have today. It wasn’t until Silverlight and Flash punched each other to death and in turn created this competitive annoyance in the market both externally & internally – that is – internally inside Microsoft it reminded the Windows team that “plugins” could very well hijack the beloved desktop SDK’s if their pace is left unchecked (cannibalizing Windows potential offerings). Externally it also reminded the web that browsers haven’t being doing their jobs, the fact that these two brands duke it out so publicly was the fresh reminder “oh by the way browser, what the hell are you actually doing!”.

Google was the disruptor in that equation as well, Firefox made a good run at trying to keep rising with the demand tide but it wasn’t until Google got its hands in the mix that we started to see a change. Not only did they push the JavaScript angle loudly than any other company but they also baited Microsoft IE Team constantly to meet their needs, it was actually a beautiful thing to see how they worked that team like a puppet via the whole “You need to focus on fixing JavaScript runtime perf levels”.

So plugins are evil? without them you’d probably be still hacking away at some crappy codec or trying to find more hacks to get around memory issues in browser(s) – or worse – writing Java Applets (probably extreme).

* JavaScript is different than it was, its awesome!
Yeah, i’m calling bullshit. Majority of the frameworks today exist to abstract you from focusing on writing actual JavaScript because whatever reason. When you have a JavaScript framework as being the excuse as to why a language should be considered then that’s probably your first clue we’re dealing with a dumb ass response to a problem that needs attention.

Some might argue “well that’s the power of JavaScript, you can write frameworks to solve problems” which to me rides along the same logic as how painters in the old days use to make their own oil paints in order to paint… today you squeeze it out of a tube and you’re now focused on painting less about sourcing various ingredients to make “red”. Abstraction is fine if you are looking to allow a developer to feed instructions into a compiler that then gets distilled into another language (cross compile etc). I simply raise the bullshit flag when that same concept isn’t applied at the compiler but is instead this extra memory footprint at the actual runtime instance itself. As now you’re just putting extra layers of ductape over the corpse that which is JavaScript in order to hide its inherit stink.

* Yeah but JavaScript is what we have today, so we should just deal with it
You can’t really argue this point beyond “yeah but I’m overweight and I can’t stop eating, so just let me die of a horrible death”. I hate mediocrity with a passion and I find anyone who compromises with JavaScript as a solution to a problem they know at the deep core as being a bad idea to be “enablers”. If you are that person and you’re writing JavaScript to pay the bills, cool, but you’re also not helping the industry and if anything you feed the whole ecosystem with more crap to deem “acceptable”.

* Stop using JavaScript isn’t an option, we just have to wait and see what’s next
Which brings me to my next train of thought – what the fuck is taking so long with ECMA6 or whatever its replacement. At what point do we declare fail on these “committees” and rally behind the idea that this shit has to stop taking so stupidly long (are they meeting every 2 years? are they even still alive…are the 90 and need time to watch Matlock before energising the base around their decisions???).  TypeScript for me is “fine, lets just get on with it” or I’m open to anything that hints at being not freaking JavaScript.. i’ll write python in the client if I have to, but get this stuff sorted out and stop wading it down by this agonising death by democracy attitude. Break the web, its broken anyway at least this will be the event that freaks everyone out long enough to come up with a better idea than what we have today.

I refuse to believe that the entire planets best idea of the day is “JavaScript” (aka ECMA3). If that’s the case then the various education systems are teaching the wrong classes.

I have been doing this thing you kids call today “web development” since 1995, I’ve watched the entire internet move at an agnosing slow pace. I got hands on with VRML and watched that crash dive, I got hands on with Adobe Flash which then lead me to Adobe Flex and then later I as most know got hands on in Silverlight/WPF. I keep chasing the idea or potential that we as a human race have, in that we know that multimedia is a medium that can convey so much importance at a pace that’s exciting – when the technology platform allows it.

Today, by keeping JavaScript as being the “best” of the entire plugin wars as a solution, you have to be an absolute idiot if you believe that’s a step forward. It’s steps backwards not just small steps, but large steps.. steps that will take us another 3-5 years to recover from again. Look at the historical patterns around Prescriptive vs Descriptive design languages…

JavaScript is the digital age’s version of herpes, every time you think its gone a new outbreak occurs – DHTML, AJAX, “HTML5”




Related Posts:

Being Playful with Industrial Software

I’ve been sitting in the Enterprise space as a UX mercenary for probably around 5+ years. In every team, sales meeting and brainstorming session I’ve always encountered resistance around “maturity” in terms of design. The more money that is being spent on the software, the more “serious” the design should be. This line of thinking I think typically comes from the concern that if the design is not serious therefore the trust around it’s ability to do the various task(s) will be eroded.

The thing is, the more sales meetings I’ve been in or participated in the preparation for the more I’ve come to the conclusion that “design” isn’t even a bullet point in the overall sales pipeline. Sure the design makes an appearance at the brochure / demo level but overall nobody really sits down and discusses how the software should look or feel during the process. Furthermore the client(s) typically have invited the sales team(s) into the selection panel(s) based off their existing brand, known or rumoured capabilities and/or because they are legally required to.

To my way of thinking, being “playful” with your design is a very unnerving discussion to have in such a scenario. The moment you say the word “playful” most people respond with some word association positive or negative (usually negative) as the word may take you back to your childhood (playing with lego or dolls …I didn’t play with dolls..they were called G.I. JOE’S!). It’s that hint of immaturity with the word that makes it more appealing to me, as it forces you to think about maturity but with the constraints of immaturity (cognitive dissonance).

Playful however doesn’t have to be immature, there are very subtle ways to invoke the feeling of making something playful without actually being obvious about it. For example, Google+ and most of Google’s new branding is what I’d consider “playful” but at the same time the product(s) or body of work that goes into their solutions are quite serious.

Playful Mood Board

Playful Mood Board

Why be playful? My working theory is that the reason why users find software “unusable” has to do with confidence and incentive. If these two entities don’t’ fuel their usage furnace the overall behaviour around their usage decay(s), that is they begin to taper off and reduce it to an absolute “use at minimum” behavioural pattern. This theory is what I would class as being at the heart of invoking “emotion” or “feeling” into how software is made and often why a lot of UX Practitioners will preach as to why these two should be taken quite serious in the design process.

The art of being playful in a way regresses adults back to their childhood where they were encouraged to draw, build and decorate inanimate object(s) without consequences attached. As a early teenage child, you were encouraged to fail, you were given a blank piece of paper and asked to express your ideas without being reprimanded. You in short, “designed” without the fear of getting it wrong or for that matter right (although right was usually rewarded with your art piece being put on the fridge at home or something along those lines). A playful design composition can be both serious but inviting, as a good design will make you feel as if you’re “home” again. A great design will make that temporary break away into using other software and then back again an obvious confidence switch – as if you’re saying out loud “gah! that was a horrible experience, but I’m’m back to this app…man…it feels good to be home and why can’t other software be like this”




Related Posts: