Inserting the UX into an existing Agile Project.

Posted on March 3, 2013 by Scott Barnes

It is a Wednesday afternoon in Sydney North Ryde, humidity is quite hot and I am walking up a fairly steep hill panting and cursing to myself about getting to the gym sooner rather than later. I glance over to my left and I see this person riding a unicycle up a hill whilst listening to music and moving at a pace that is faster than my walking (yes that is how unfit I am).

I simply stopped in my tracks and first chuckled at how amazingly insightful that was to witness as I immediately thought “that basically was the visual for my role as a UX Architect” – which was to say, “Poor me, how hard is my job as only an idiot would ride a unicycle up a hill”.

Sometimes life is like riding a unicycle up a hill.

As I continued to walk, I started to think about how much effort that person is putting into attacking the hill before him. Firstly he has to balance whilst at the same time maintain a steady forward momentum (too fast he falls, too slow he falls). Secondly, he is listening to music while he attacks the hill that I can only assumes helps him focus on the mission ahead by blocking out distraction(s).

That encounter inspired me, it gave me a renewed sense of energy at facing down the biggest problem I have today – “how do you integrate UX into existing Agile projects cleanly”. I mean to say the task before me is not easy, it is filled with many uphill battles such as balancing between function and form, whilst at the same time not spooking stakeholders into cost blow out panic attacks. I also am required to have a concentration level that simply at times feels inhuman given the unchartered territory ahead.

The difference between that role and the actual guy on the unicycle is well at least he gets to see what’s ahead of him whereas a UX in Agile world is typically doing the same thing blind folded.

Discovery vs Delivery.

I spent over three years travelling around Australia in every capital city visiting “developer” teams for all types of companies (enterprise, startups, government etc.). I have seen the same thing happen over and over, whereby each company swears by their agile manifesto and how important it is to maintain “agile” discipline. I also notice they cherry pick agile each time to make sure it fits in with their culture and more importantly to not take it as an absolute but more a relative approach to designing software.

The part that often sticks in my craw is not the sprint cycle(s) or the sprint backlog creation. Nope, the part that I immediately notice as being the fatal flaw to why User Experience is often the sacrificial lamb in the development process is well the discovery of the said feature(s).

For instance, a team will often sit down in a room with a whiteboard and then begin coming up with some stories around what they are hoping to achieve with the software. They then will likely document these stories with the usual “As a User I want the ability to do X so that I can do Y” style sentences. After that process they, would likely then unpack these at a later time into developer task(s) along with success/fail criteria (tests, definition of done blah blah)?

I would guestimate that 90% of the hundreds of developer teams I have visited do pretty much the above. Furthermore, I would often be invited into some of these teams at around the last few sprints to help “make it look UXy” as if there was some way I could just “Integrate” into the team(s) development process, fix the UX problems, low impact to the code and do the aforementioned in a timely manner (Usually I say: “You don’t need a UX Architect, you need a priest as this thing is dead and all you’re after is a lot of prayers to reanimate the corpse”).

Let me simply say this, as a contractor I would love nothing more than to have you do the above, especially if I am charging you per hour. I could simply tread water and extract large amount of free useless work hours knowing either outcome still does not result in a successful delivery.

Ethics 101 aside, today, I am not that contractor, I am a UX Architect and I have a queue of other products waiting in line for my same attention. I do not have time to drag the timelines out so I have to instead get the above optimized.

The flaw in this aforementioned process of white boarding features is the part that you first make your biggest and ultimately largest mistakes when it comes to making a software product (which is a general argument to make, but hear me out). As when you sat down to the feature, you did not document whom you are making the product for. In addition, how much time did you spend on refining the process other than the first bunch of fragmented ideas? Lastly, how do various stories influence one another?

Agile is not an excuse to just deliver a project without planning and planning doesn’t mean you have to spend the bulk of your time in “waterfall” delivery purgatory either.

It is probably a good point to say that if you are focused on delivery and you spent little time on discovery, well you are basically in for a lot of turbulence and “UX Tetris” in the coming sprint cycles.

Unpacking the Discovery phase.

Take an existing project you are on today, now look at the User Stories you have (ignore your tasks). Now grab these stories whilst grabbing some pens & notepads. Now take some of these stories (does not matter where you start) and begin drawing a comic book of your product, that is “how would you draw an activity from the moment the user clicks on an icon to the splash screen and then to what they see first”.

Example – If I was building Outlook I’d say scene(1) is user clicks on icon, scene(2) splash screen loads, scene(3) outlook opens in default folder view, scene(4) user creates new email etc.

The objective behind this in the first part of the discovery phase is to illustrate that your story whilst at first sounds perfectly fine is not really “done”. How many UX Personas did you draw in the comic? I would wager maybe one? Moreover, how many times did you redraw this process before you exhausted the steps into what you would consider “simplicity”.

How much influence did iPhone, iPad, Microsoft Office, Outlook, Windows 8, Adobe Photoshop, Adobe Illustrator, Visual Studio etc. all play in the mental model you had for the software(s) design?
How many DataGrids and Tree controls did you “assume” existing in the UI as you drew the comic story?
Did you draw the UI as a wireframe or just abstract shapes? (If you did wireframe, stop, rub it out and keep it abstract).

A Definition of a Story is “An account of imaginary or real people and events told for entertainment” – the key words from that definition are “An account”. That is to say, it is your own personal bias coming through on how you foresee the event taking place based on existing ideas or experiences from the past.

Now, to bake your noodle, grab three or four of your colleagues and get them to do the same process on the said story but be very careful not to lead them on the same path you just took (e.g.: “draw a comic book for how our customer can create a new email. STOP. No more information”).

I have done this a few times and usually what happens if done correctly (i.e. everyone is in isolation) is the story typically has similar patterns but the ordering and approach taken often has mixed result(s) (especially if its domain specific to your companies problems and not generic like email checking).

First lesson learnt here is that we all approach the design with a bias in mind and yes, we feel that if we all share the same pattern in design it will in turn invoke less agitation on the end user(s). Agitation such as this is still good and most of the time the behavior of the said end-users will likely follow the approach defined.

Problem is you are not in the business of “good enough” anymore. Software today is expected to rise above mediocrity and everyone is under pressure to deliver products as “simpler” and less “dense” in terms of feature(s) and/or layout design(s).

With that, it is your job to put this entire story design on a very strict diet that should take more time than you probably anticipated. Typically you will want to time box this process as it can drag out and I highly recommend you grab a healthy mix of developers, customers (trusted), sales, marketing and if possible receptionists (i.e. people who aren’t your target user) in the creation process. The more diverse the background the more likely you can feed of each other’s ideas of “simplicity” without having blinders on. Lastly make sure it’s in a room where everyone can draw their ideas and do not break these sessions into hourly mini meetings – make them days, in that spend five days in a room fighting, crying, swearing, hugging and so on (as you will take two days to get everyone in a relaxed mode whereby failure won’t be seen as embarrassing – humans are funny like that).

ProTip: Simplicity can be measured.

A Comic style slice of all your user stories can feel like a complete time waste, especially if you have pressure to deliver. In order to do this you have to justify how this can improve cost of delivery whilst at the same time it looks dangerously close to “Waterfall”.

Truth be told, in under a week or maybe two you could potentially visualize your entire current story catalog in a way that would likely reduce countless hours of communication issue(s) around design which in turn would without a doubt reduce communication costs. That being said, that is a very loose “return on investment” pitch to make.

For giggles, take the existing slice you have designed and then unpack that into tasks with forecasts attached. Record that number and cost it out in terms of effort.
Now, for giggles again, take your team and tell them “make it simpler” that is refine the story further, squeeze it to the point where you automatically feel it is not as “Powerful” in terms of feature design.
Once that occurs, run your costs against that.

If done in a way that I am assuming you should see a fluctuation between the two cost(s) and it can be either higher or lower in terms of cost.

You have the first measurement to add to the “simpler” cost center, in that if it’s lesser in terms of cost – awesome, see we just reduced a lot of excess coding time!.

If it is higher then well how badly do you want a better user experience for the product you are making? (Sneaking this past people usually ends badly, so be honest and if executives do not subscribe then you have an answer on how they feel regarding “experience matters”).

Often when I do it, the cost initially increases (i.e. short term loss, long term repeatable win) because as I am refining the stories I am looking to make the behavior of the user less effort for them. That is to say I am thinking how the software’s job is to make their life easier and that it should do 90% of the work for them and that means at times decluttering the task from the usual user interface design and being context specific (i.e. isolate the user to carry out a task that’s reduced of distractions).

An example.

If you mapped out Outlook comic story you would probably have imagined outlook as it is today, whereby you have the tree of folders, you click “new” and prompted the same way it does today.

I think of it differently, I think that whatever behavior I invoke that triggers “new” is initiated, the entire user interface goes into “new mail mode” that is the existing chrome/HUD is screened back and all the specific requirements I have for “new email” is in front of me. To my left there is a smart way to access my contacts, especially given I’m in a large enterprise and often have issues between first/lastnames and aliases”. To my right I have a different way to create an email in that am I creating just a text email or am I creating something that I want to insert media into for all to visualize my point?.

My point here is I could easily increase the development cost in order to assemble the user interface in a way that for me puts all the necessary pieces the end user will need in order to carry out the said task. Simpler doesn’t mean minimal (as that can often be misleading) it means how does one make the life of the persona simple in carrying out the task – given software is made to make our lives easier right?

UX Personas are not what you may think they are.

Having redesigned the new email some may declare “..hang on, you didn’t specify the feature criteria fairly..” which is true, I did not. The next thing one needs to learn is my idea of a user and your ideas of a user are highly likely two different types.

Example of Useless “UX Persona”

A UX Persona discovery will fix the assumption failure(s), whereby if you sit down and you unpack the word “user” to the point you exhaust your collective knowledge of that means. A UX Persona is not a story about “Jim who is 22, likes fishing and blah blah” as bottom line who gives a shit who he is or what he likes. A Persona designed like that is used for marketing purposes to help sales teams position the messaging & roles the said product will likely excite.

A UX Persona typically needs to focus on two simple areas, that is what behaviors they are currently exhibiting (AS-IS) and what behaviors they should be exhibiting (TO-BE). The word “User” needs to absorb the fact that sure, a user is doing xyz today but you are in the business of innovation so you in turn need to move them to a new set of behaviors!

Eg: When Apple sat down to design the iPod touch they were not pandering to existing behaviors user(s) were exhibiting on mp3 players. They moved us all over to the touch interface and it was initially confusing but today I see five year olds queuing music & playing games.

Defining a UX Persona for me is mainly about breaking their behaviors into four categories

Influence (low to very high). Take training, mentoring, buying power, optimization etc. as categories you can help shape the low to very high score. Basically how much influence does this persona have over the adoption of your new product, the training burden required in order to use your new product and lastly the output of the product (i.e. are they the end customer for your customers customer).
Usage (low to high). Similar to influence but now how much of the actual product are they going to be using? Specifically which modes of the product are they using (e.g. Visual Studio – Build time, Debug & Runtime). If you are writing software for both an executive assistant and their boss, then basically it is likely the assistant is going to have a higher rating then the boss depending on the scenario (vice versa).
Form Factor. What are they using to access the product? Given tablets, smartphones, laptops etc. are all evolving technology what is the likely input of choice. Do not just isolate this to device/platforms but also are they using stylus pens, are they using modified keyboards etc.
Environment. What is type of environment are they using the product in? Is it inside a coal mine where it is dark (i.e. white vs. black colors are a safety issue), is there many hazardous issues nearby? Is it noisy (distraction and cannot hear sounds), is it inside an office? Is it inside an operator building where your product is one of sixteen screens?
Environment is really an important amount of information that gets lost in the “Story” creation. As we really need to pay attention to how much duress, the user is under in order to make their life simpler.

Notice I never discussed usability issues such as their age, sight quality, gloves vs no gloves, color blind vs non color blind and so on? Well, if you did not now you have. Usability is a completely new chapter on its own, suffice to say I typically design for extreme in mind that is I assume the worst and hope for the best, make the process accessible and it in theory should put you in a position to refine for specific usability & accessibility scenarios (ie design garden sheers for people with arthritous and in theory you will design for both people with and without in mind).

Keep breaking the UX Personas you design down until you simply cannot come up with new ones. Then go grab some customers you have today or want to have tomorrow and play a game of “Guess Who” with the existing ones you have defined. If you cannot line them up with what you have or you end up with orphan UX Persona(s) then consider how to merge or separate until you reach a “best guess” group of personas to attack with your new product.

The trick here is also to focus more on “TO-BE” not “AS-IS” as the moment you release your product to market you are changing the rules of usage. You are invoking change in an area where existing mental models are either hard wired into the users or have no concept of said feature(s) even existing.

Once you have the list of Persona(s) grouped in a way you feel make sense (make tribes if it helps with the grouping) then I want you to divide into two piles – first being 80% and second being 20%. Dividing these personas into the 80% and 20% piles gives you two options going forward.

The 20% pile could be the first target users, these are the ones you want to launch version (1) of your new product with. It means you have a much simpler feature set to attack but it also means you can iron out the kinks in this new process whilst illustrating the value of “simplicity”.

The 80% pile could be the same as the 20% or it can be the persona(s) that are distracting you from simplicity, which is they aren’t as important for the first round of delivery? Either way you choose to approach this just settle on one of these piles as your “target” user base.

The truth is you will never hit 100% of your persona(s) needs in your ongoing deliveries, and once you make peace with that, the pressure of being everything to everyone will be reduced. It means that over time, you will have to work harder to regain the lost personas back but that is fine, provided you stick to that mission and remain calm.

Example – When Silverlight was being built, the first version pretty much took the 20% path with a focus on video persona(s). As more and more versions of the product where released it then would take the missing 80% pile and subdivide that into 80/20 and again, take that 20% and chip away at those personas that wanted more than video.

ProTip: Consider putting these personas into a deck of “Cards” and hand them out to all members in your team. As when you are discussing problems in your day to day development get into the habbit of keeping them in view when you say the words “Customer” or “Users”.

You are in the patterns business.

Do not fool yourself into thinking the software you are working on is unique and never been done. There are elements to the software you are making that is fresh in terms of features here and there but ultimately you are highly likely re-using existing UI patterns found in software today.

The question is what UI patterns are you using and why have you changed them? That is to say which Color Modal are you going to use and why don’t you like existing patterns out there should it be different?

It’s at this micro level you isolate your users actual behavior and can be majority of the time field tested with customer(s) to establish what is “usable” and which isn’t. It is also at this point you can attach “who” the UI pattern is designed for.

If you catalog these UI patterns you can also begin the “visual” treatment process before any code is even written (in parallel) as its really about which assets are missing, which you already own and when they can be queued for delivery.

Lastly and the most important point of all is that you can identify which Patterns are “Fresh” and begin your patent application(s) for retaining your intellectual property rights whilst at the same time ensuring that you’re not infringing on other existing patents out there.

(i.e. have you read the terms & conditions of Office Ribbon, Adobe vs. Microsoft legal case around panel snapping etc.?)

Discovery integrates with delivery.

To recap, you have taken the simple “user stories” and you have mapped them into visual stories that help illustrate the “before” and “after” in terms of refining them down into “simplicity”. You have also identified whom the actors or “user” actually are finite detail that even talks to what, where and how.

So, discovery phase is done right?

No. This is the easy part as now you have information and you have a sense of possibilities. What comes next is the part where you often will lose the executive owners of your team. It’s the prototyping phase of discovery, that is take your ideas and come up with some wireframes or small time boxed interactive prototypes of how the comic stories can be achieved.

I say you lose them as if you do not handle this carefully you will position this phase as being “wasteful” or “not as important – function vs. form”. The trick is to factor this phase as being part of your “delivery” but knowing it is actually more to do with “discovery”, (it is as if you Jedi mind tricked the project management & executive fears).

Prototypes, Wireframes and Comic Stories are deliverable that works the same as actually writing the code itself in a normal agile scenario (i.e. they too can follow sprint cycles). You can do it parallel (if you are in v2 of this process) or you can do it sequential but the key is to deliver something that shows the investment is not wasted. You also iron out the unknown and can often deliver drops to candidates for the software(s) release to get a sense of what success/fail will look like had you spent months coding it for real.

Remember Windows Longhorn? Yeah most of that was Macromedia Director. Remember Silverlight on the Nokia N9 back in MIX keynotes? Yeah that was kind of a mini PowerPoint style animation! Point is when you demo something, nobody 99% of the time asks to see how many lines of code it took to make.

This approach builds confidence that your development has balanced the feature(s) required with market readiness/attractiveness whilst at the same time maintains a disciplined delivery schedule. It also allows you to really validate your UX personas against the features that they are attached to, as then you can start to formulate a fairly accurate understanding of what feature(s) are going to make the release and who they are being targeted for. Having just this alone can improve your “feature” cutting when the time for reducing scope occurs; again, you know more about the impact than a general “user” statement.

It also helps to know this when forecasting costs for a new products development, which is how much this will cost to produce and who the first, second, third round of releases will likely excite. It also helps training / documentation teams begin preparing their work streams on how to manage change management issues. This also helps testing teams understand how to attack their tests to ensure the said quality gates are kept intact and aren’t being approached from “generic” scenarios (i.e. play the role of the UX persona not the roles like “let’s see how much of this I can break”).

Finally, it helps Marketing/Sales teams get actually ready for the “launch” in a way that hits your target market squarely in the places it should. I.e. they know who to avoid making eye contact with during launch time should that UX Persona group not make the cut).

Sunlight is the best disinfectant.

Before I close out this poorly written tomb, let me say that no matter what choices you decide to make, ensure you keep it all open and transparent. There is nothing worse than having all the discovery and delivery processes being locked up in the hands of a select few or worse making it available but displayed in such an abstract format that it simply holds no clarity around what just happened.

The combination of UX and Code delivery needs to happen clearly, there needs to be KPI’s set and lastly you need to ensure everyone in the room has a visual simple display as to what is being worked on.

An executive does not care about your “Done” board in agile and they do not care about how many stories you have to write code against either. They also do not care you have unpacked a generic User persona into five sub personas and lastly they do not care about how you have improved the “AS-IS” comic style user stories into the “TO-BE”. The assume you do this normally, so don’t expect an “Adda boy/girl” pat on the back as well it’s like being asked for a high five for knowing how to check email?

The mostly care about progress reports – where is their money being spent and why. They will care at times when visiting peers or their power brokers come by for a visit, in which case bring all the above out for a full show & tell (factory visits is what I call them).

If you can justify the costs in a meaningful way that does not involve reading text then you are miles ahead of other teams who assume that just because a Story is written down that everyone “gets” where they are heading. Visualization of your products early often gives everyone in the room clear communication around what the vision will end up looking like. There is less pressure for demos to be at a fairly high standard given comic stories, prototypes & wireframes will paint that end point in a much more cleanly digestible way (which ultimately will mean memory recall – which is what you all want).

Lastly, before I close out, can I just say aloud – everybody relax. The agile movement is simply about taking a lot of big lumpy problems and breaking them down into really small bite sized pieces that are easier to manage. This is a strategy that is not unique and exclusive to software development; other industries do this daily and without as many issues as we often create.

An Example of this process is grab 3-4 unique small “beads” and drop them into a bucket of sand. Mix the sand up, then using just a small scoop, plastic bags and a scale come up with a strategy on how you can sample the said mix evenly.

Solve that problem and you can have a future in geology but at the same time, you will also be in a better position to understand how Agile + Forecasting actually work.

Agile reality check–what if Jesus was female?

Posted on December 6, 2011 by Scott Barnes

Twitter stream caught my attention, as the conversation came up around how Agile maps to the doctrine meets reality.

What the..

I like to think I’m a guy who’s travelled around to a lot of teams and tried many things, I’ve been in quite a number of teams world wide and have seen some great projects succeed others I dare not mention for their curse alone may bring bad karma.

Throughout my travels, the concept of Agile has always been this mutated religion that often gets thrown about but really doesn’t cement the virtual “it should be done as this” to “this is how it maps to reality”.

In all the teams I’ve been in one thing always was consistent, that is there is usually one or more person(s) in that team that are often the weakest link – you know, the one that if we were playing survivor they’d be the first to go.

That person often is also one that has a degree of influence and whilst a democratic philosophy is one we should aspire to in an agile setting, reality is usually there’s an alpha in the room and they often are the ones who approve your timesheet – thus, you suck it up and give way even if it’s a dumb decision.

I’ve heard often that “Well the reason that failed is you had the wrong person” followed by how the role was given to a jackass who typically had no business making decisions other than “would you like one or two biscuits to go with your hot beverage?”

That’s the problem though with this whole agile philosophy, we aspire to working with a gang of people that make you feel as if you’re coding along side a crew that have similar skills to Oceans 11. Yet when you look around often the case is you’re dealing with a crew that came from Billy-Bobs 12 and its often the 12^th man is usually the cousin twice removed but was forced to be in the team due to Billy-bobs wife being a royal pain in his redneck side.

Ok, that metaphor fell to the wayside but my point is I often find the reason why agile/scrum fails is simply due to the aspirations around the said doctrine not mapping to the reality of a commercial environment.

The amount of customers I’ve had to create solutions for often have no clue as to what they are doing and its usually why they hit the panic button, allocate budget and socket in a development team to solve the said problems. If you’re lucky you get the business ownership in a place where they feel competent enough to say out loud “I actually understand my business problems and desire software to solve them” …if you’re lucky.

Do you as a developer look at the said impending car crash and simply yell “we should really stop what we are doing and look at who’s driving this car and why” or do you simply lock onto the weakness that which is a business out of control but with a really big wallet thus as a contractor exploit this until the wheels come off. Once the wheels come off you simply throw your hands in the air and do what everyone does when agile fails “You had the wrong person….”

Here is my creative thinking on a way forward.

What if you had your team divided into two parts, that is you have TEAMA working on the grind, as per design think on your feet reactive feature development whilst TEAMB looks at iteration two, figures out the weak/hot spots and devotes more time to just R&D (spiking the big issues).

Once they have that mastered or time boxed them then switch gears, own iteration two and then iteration three is then put into R&D mode followed by a rinse/repeat formula.

Would this not also include user experience?

Anyone tried this? Or did I just declare Jesus was really a female and not a guy after all thus a war breaks out and I’m likely to be crucified for challenging the status quo.

No Related Posts

How much would you invest in a pixel?

Posted on June 15, 2011 by Scott Barnes

I am a massive fan of World of Warcraft again; yes, it is sad isn’t it? Last night I was playing my usual allotment of time watching pixels update on a screen vs. interacting with real humans and something I witnessed struck a chord with me.

The ‘flash of genius’ for me was when I was playing a typical Player vs. Player (PVP) round of Battleground(s). This is a part of the game that essentially randomly aggregates a group of people spread throughout the entire WoW realm(s) into a 10vs10 etc match.

It’s basically unbridled chaos and it really highlights some components for me that I find fascinating as to watch the herding mentality of us humans in an avatar driven game is kind of predictable. For instance, I was the first out of the gate when the match started, I rode my horse towards a spot that was the second closest and because I was the party leader, many other players followed me. I arrived at the spot and just waited. Out of the six other players, three stayed after 20sec has or so of making decision whilst the other three grew what I can only imagine as being bored and rode off in search of a fight.

What is so profound about this is how easily I convinced others to wait beside me in a place that had no real plan other than "well, if the sh*t goes down, we defend with our lives" as the core plan. We had no vision of what was about to happen beyond that and we had no clue as to how we would all work together as we just met each other in game only 5mins beforehand. Here we are armed ready to fight and hoping we can figure it out as we go.

We died.

This is much like most teams I’ve been in over the past few years, I keep hearing about a good team is one that is in sync with one another but in the end that only lasts for the first flag/waypoint as beyond that a lot of variables occur that in turn causes a de-synchronization from occurring.

In the above example had I been paired with a healer and another tank/dps (tank or dps are basically characters whose sole job is to hit hard and often as a healers job is to keep everyone alive while they do so) we may have stood a chance of survival. As we all had a role to play and whilst the plan was distilled into a core class structure, we still have a series of objectives that must be upheld.

A healer must be protected at all cost, as well that character is your tipping point between living and dying but at the same time a healer must keep back from the fight – as much as possible. A tank/dps job is to draw fire and get deep into the melee as much as possible and the more you can tie up your enemy’s focus the greater the chance of a win.

In software, this concept has not entirely lost, as a UX/UI person(s) job is to figure out how to keep this software from dying of bad usability death. The coder’s jobs are to underpin it with large amounts of code to keep structural integrity intact if they do not do their jobs rights, it can in turn create more work for the UX/UI person to go fix. If the UI/UX person does not do their jobs, right they can in turn suffocate the work of the coder – so it is a partnership.

A great software release respects this partnership to the end. Good UI/UX and Good Code = Good software.

If you randomly put together a team of mixed classes and pin your hopes on the agile a way of life then well you are no different to my WoW example. An assumed leader leads a group of you into a spot that has no agenda or plan other than "don’t die please".

How you live or die is based purely around how fast you can communicate with one another about what tactics you can deploy to uphold this basic principle of preserving one’s life.

All it takes however is one person to break ranks, to be the Leroy Jenkins (See Video below) and well it comes unstuck and fast. We all die of a horrible humiliating death – (aka miss our deadlines etc.).

Agile is not enough, is my overall point. I think agile works if you are solely focused on being a tank/dps class (coder). If you mix in UX/UI then that is where it keeps coming back with mixed results, there appears to be no right or wrong formula here.

The one concept I think – and it’s only a theory – is that you need to at times stop fighting the code and give enough time for the healer (UX/UI) person to catch their breath, to drink some mana potions if you will to figure out how to navigate the next fight.

Lost in my metaphor?

What I am trying to say is that UX/UI in a sprint equation needs to occur every other sprint, meaning at some point in the process you need to arrive at a point in time where you the coders will have to refactor your UI / UX to accommodate the new direction in the design.

It sux.

It is however, the realistic way to accommodate the reactive design you have put in place and to be clear it has little return in investment other than user efficiency and satisfaction levels.

Now comes the question – how much do you invest in a pixel?

Answer that and you will have a better understanding of Agile, UI/UX + Code than I currently have. As you now need to think in terms of how it all comes together and what value you place on the UI/UX component. Agile won’t necessary work in the way you think when it comes to intgerating your healer (UX/UI Person) into your battle group. At times you may not need them – that is until your hitting a wall and soon realize it would have been better to have them at the start of the fight vs end.

I can think of some rebuttals here – ‘well you are doing agile wrong’ or ‘your team sounds like it wasn’t assembled correctly’ to which I simply respond – welcome to reality. Sometimes you have to play the game with a randomly aggregated team and it is not always a case of Greenfield project management.

Now, your move, how do you accommodate these variables.

THELAB: User Story Management – think beyond cards.

Posted on April 16, 2011 by Scott Barnes

As a Hybrid I want the ability to create user stories into clusters so that I can isolate ideas into more finite pieces.

The Problem.

Seeing that most are probably likely to ask what the heck I mean? A User Story by SCRUM standards is just a small two-sentence tid bit that gives one clues as to what one should develop in software vNext? The problem with this line of thinking is that it goes against the nature of human phycology in that to isolate streams of thought into abstract finite forms does not work.

Want proof?

Ever sat in a Story planning session and as the stories begin to flow you immediately start to cluster these in your mind into groups? You visualize them into clusters when you see them that are because we as humans are massive fans of chunking information so that we can process them in more digestive formats. Is this a problem? No, it is just a natural primitive instinct to encourage you, as an entity that has grown opposable thumbs into ensuring the thing in front of you is both learnable and adaptable to suit what happens next.

Today, if you were to look around on the inter-web you would see a bunch of SCRUM friendly software and most of them try their best – and fail – to re-create the experience of User Story capturing. The approach they often take is to create a rounded rectangle and display them onto the user’s screen as:

"this is a card and therefore it’s like the one you have in your cubicle in paper form. Please use this the same way in which you would that..”
Signed Software Designer.

Recently I learnt a very important snack of UX goldenness and that is we do not use software, we work with it. Software should reflect who I am and what is contextual relevant or albeit synchronized to suite my needs vs. having to ask me to adapt to its needs. Handing someone a virtual card on screen does not offer anything of value, all it does is remind me the constraints put forward – I need to cram an idea in under two sentences in abstract form so that I can break it down further into sub-forms in order to generate software feature(s).

The Flash of Genius.

I sat down today to tackle what I call the "Opening Act" in my UX magic show for an upcoming application I am making in WPF debut titled: IWANT – Weaponizing Agile. As I sat staring the blank canvas, I began to panic a little, as I did not want to just re-create a grid of cards and declare victor to do that is to admit I have not thought about who the end user is. Instead, I went for a walk and asked myself a simple question – Why does it have to be card and what else could it be? The more I thought about the form of media given to every SCRUM disciple out there the more I started to question its sanity – more to the point, who the freaking hell said a card was the best solution to this problem? A group of people who conjured up this religion we actively calls SCRUM today?

The SCRUM founding fathers if you will have some brilliance, but I’m not sure user experience or human phycology was at the forefront of their minds when producing this thing we call User Story management via card sorting. I would however put forward the theory that they were thinking of ways to force we humans into the existence of tearing down our natural instincts to cluster / chunk information in forms that are more isolated / streamlined.

Armed with this moment of brilliance, I sat down and began grinding pixels. I began to think about the problem in the fashion of idea clouds, just like as if we were about to read these stories in comic book form. Yes, comic book form – as name any child today that doesn’t find reading more enjoyable in such format and I put it to you that we adults need to recapture our lost youth as much as we can.

The Objectives.

Like all good experimenters, I need to assign some objectives to this newfound awareness. They are along these lines:

I want the ability to visualize clusters of user stories in ways that respect my primitive instincts but at the same time respect the existence of SCRUM.
I want the ability engage the experience with a sense of depth that is not flat, lifeless and typical response to visual grid ways.
I want the ability to get in and get out when I need to resurrect a User Story of a specific type.
I want the ability to just create in a fast responsive manner and I want the said creation to have dependency links throughout that are of contextual relevance.

The solution.

Armed with this tall order, I bring you thine creation.

The Terminology

Story Clusters. A Story cluster is a group of user stories that fall under a theme / category. The idea is to allow teams to partition their ideas into taxonomy of their choosing but more so to ensure they can feed the idea threads around a particular concept – Security? Customer Management? File Storage etc as but examples of "theming".

User Story vs System Story. They are one in the same the difference however is to give developers or engineering minded people a free pass in terms of allocating some ideas to either a person(a) or a technical agent of their choosing. An example of this is

"As a User I want the ability to save my blog posts so that I can share it with others!" – User Story.
"As a UI Client I want the ability to CRUD a blog post so that I can allow users to manage blog posts" - System Story.

Some SCRUM masters may have a mental seizure at the sight of this – deal with it you jackasses. The reality is when someone sits down to write a User Story majority of the time the person is trying to force themselves out of a cycle of developer eyes and into something, they are not. The purpose in my opinion of this exercise is to tease out the idea; we can break it down further later but get the idea captured!

The UI Teardown.

View Finder. It’s here you will find the User Story cluster(s). The clusters are grouped into a cloud like existence and the more stories found within the cluster the larger it becomes. I choose to enlarge these to enforce dominance for one and secondly to attack the end user in a subliminal manner by encouraging those to break it down into a separate cluster if it is getting to large. This is exactly like a container of any kind, if you keep cramming it with stuff it gets bigger and eventually you start to think about the problem again but now are already looking at ways to fork its contents.

Notice also, how the clusters are blurred and have a sense of depth. This is to ensure the end user does not take what is in front of them for granted, I want them to focus and I want them to explore the data. I do not want "at a glance" viewing; I want interaction and comprehension around what is in front of them. Explore, interact and adapt.

Search Box. Given the end user for this product is someone who’s stuck in the mental model of "As a blah I want.." style thinking, it’s important for me to not interrupt that conscious thought. If they are looking to find a specific task, user story or note of any kind then it’s here I expect them to take a leap of faith and search. Important thing to note here is I am not relying on this massive data grid or tree control to allow my users access to the data. Why not? It is important to not give them a crutch to lean on; I want them to think about what they are asking and how they ask it. Providing a DataGrid or Tree Control is encouraging them to embrace perspective memory way to much (i.e. they will next want the ability to pin that area of navigation, taking up valuable real estate simply because at the heart of it they don’t want to have to collapse / scroll to that sweet spot again). Instead get them into UX Rehab, ask them to treat the software as if they were turning to a co-worker and asking "hey, where did you put that file.." – behold the power of search!

Create Only. Notice I do not give much in the way other than "Create" options at first. I do this deliberately as I want the end user to build first tear down / fix next. Find the thing you want to do other stuff to but here, all I am interested in is giving you ways to add to the web of data.
Some of you may notice I used a Skull as the icon to represent the User Story. The reason I choose that icon instead of a typical silhouette head of a human is simple – we are creating digital Shakespeare. You are telling a story, so it is fitting – that and this is the spot where good ideas may go to die.

Stats. I am a sucker for fun facts or a sense of proportion but more importantly, it is about keeping a score of what is going on. Too many times software hides data to the point where you either underestimate or overestimate the complexities of a given problem because of such things as software hiding key pieces of information. I choose to keep a cycle of statistics around Story telling within iWANT so that as users are working on the feature catalogs of tomorrow they are also getting some fun facts so that they may turn to one another with stuff like

"oh shi.. We have like 300 stories added this month..man, we are never going to get this done in time.." (Invoking maybe a rethink in customer expectations?) etc.

The Conclusion.

My concept is unproven and untested. It may very well fail or it could succeed but right now any feedback or questions around this approach is simply "I think" and not "I know". What I am confident about is that it will spark a different round of thinking in terms of how one approaches user story telling. My objectives are clear enough to outline the overall intent that is to provide a safe haven for undisciplined and disciplined thinking around what goes into software of tomorrow. SCRUM is a little too religious in tis procedures and I find at times it goes against the grain of human psychology thus forcing a practice into place that at times is unnatural.

iWANT is a solution I am to challenge this thinking but at the same time allow development teams of all sizes the ability to get the administrative overheads out of the way fast, cleanly and smoothly so that they can focus on writing code, grinding pixels and marketing their product(s).

UXCAST–Making Isometric Workflows inside Expression Blend–Part 1

Posted on April 4, 2011 by Scott Barnes

I did it! and I feel exposed. I sat down tonight and put together my first of what may or may not be many (depending on how badly I get crit) screencasts around UI / UX + Microsoft Technology.

In this video, I show folks how one can take a workflow design concept and inject it into your canvas of choice but in an Isometric format. I like Isometrics simply because you can get more of a spatial view than most screen angles that and it derives from my old Pixel-art days so..yeah..Isometrics are the way!

Hope you enjoy, and feedback welcomed.

RIGANEIC – UXCAST – Isometrics in Expression Blend from Scott Barnes on Vimeo.

In this screencast I show how one can take a Isometric workflow map and transpose it into Expression Blend 4.

What happens when you bring the UX person in last.

Posted on February 2, 2011 by Scott Barnes

How many of you have been to a conference that has a UX/UI Person on stage discussing the mystic art of software development and design? In that said session they at some point raise the slide that outlines you should engage a UX person early and think about UI/UX from the start.

How many of you then go back to your respective cubicles, nodding in agreement but then immediately go into a new project ignoring the said suggestion?

Don’t lie, I see you looking back in a nervous manner and shouting out reasons like “Well, we didn’t have the budget” or “My boss wouldn’t …” etc.

Meet Mr Wolf

Just like in Pulp Fiction, a guy like me is called in after the crime has been committed. I’m the guy you bring in after you accidently killed someone and its my job to navigate the mess in order to get you back to your life without prison time. If I succeed, you don’t’ spend the rest of your life in jail if I fail, well, learn how to fight using prison rules.

When I come into a team in this situation, the thing that I notice the most is they are looking for guidance around a plan, in that it’s a case of me analyzing the situation, asking a series of specific questions relating to the said scene and then giving them a task list to execute on – whilst being clear to stick to my rules or well, good luck in jail.

The problem with this approach at times is that you have usually one or two people in the room who ask for your help but at the same time are giving your orders on how to clean the mess up quicker – each time they do this they in turn increase their chances of prison time.

It’s a hard balance to participate in from my perspective as I have to figure out a way to firstly give a design and experience to the software’s targeted end users in a way that isn’t just a screen after screen of tree controls and datagrids whilst at the same time having a low impact to the codebase and lastly but more importantly doing it within a very tight timeframe/budget?

Its hard work and you know what, its going to cost you so don’t whine about it.

Had you called me from the start, it would have been a completely different outcome and yes, you’ve heard this thousands of times at whatever conference you last attended – engage a UX person early and let them direct the screens overall compensations – design first engineer second.

I personally have been pulled into over 30+ projects in the last year that have this exact situation unfolding before me, in that it’s the last two sprints of a project, I’m playing a massive game of UX Tetris with WPF/Silverlight or Wp7 and I’m constantly being harassed on time/budget questions.

It sux but that’s the reality of the role I play in this business, the guy who can code and design at the same time. Its why I charge the amounts I do and sure the price attracts attention but in truth If you follow my rules and approach you will come out with a finished result. If you interject along the way with the way you think it should be done, fine, I’ll do it your way but if it fails – given the inexperience so far, it will – then to be fair, you were warned.

My way or the wrong way.

The way I approach situations where I’m brought in at the last hour is via the following routine.

The Primitives. In every application you have what I call the primitives, in that these are the buttons, modal windows, textbox’s, scrollbars, checkboxes etc. .. the stuff you get out of the box for free with .NET. My first attack posture is to start building out a resource dictionary library for you to bootstrap your UI against. In that for example TextBox and Button controls I start putting into what I call the UI-Shirt-Sizes, Large, Medium and Small. If your form in question requires the user enter 15chars min/max, who cares, the end user is open to the idea that this textbox is a small one that magically doesn’t let me type more than those pre-defined characters.

If your software has a large sentence like “Find a users profile” labels on buttons – guess what I’m going to do, re-label that as “Find..” keep it simple less extraneous cognitive load and more assume the user has used software before they picked up yours.
The Layout. Chances are you’ve probably put together a UI that I can only describe as a DataGrid orgy followed by copious amounts of Modal windows and screens that probably looks like the dashboard of a Qantas Jet in terms of fields/inputs etc. Just for giggles, I’m also likely to find a TreeGrid control because of some random hierarchy based navigational weird mutation of a need (you know who you are, there’s no shame in admitting that)
I’m going to simplify this down to the point where the data flows in a fashion that makes sense to the outcome of the screens purpose. I’m also going to look for ways to make use of a party trick called “progressive disclosure” as you do want the user to feel like they stand a chance at success should they use your software don’t you?

This is what I call the hostage negotiation in that chances are there is an entity in the room that is locked on the way it works at the moment and its my job to find a way to get you to release parts of the UI so I can find a happy resolution to the situation. I’m going to ask you to give me a little control over how the UI comes together and in return I’ll turn the lights back on followed by some pizza. We need to build trust and you got to work with me on this one, I can make good on some promises if you do!
The Validations. I have seen some crazy ways that developers have approached the simplistic concept of alerting the user that they did something wrong. What I have noticed the most is its kind of OnChange vs OnSubmit mode of approach. The reality is validation isn’t that, as you have the “Hey before we show you this form, here’s where you need to focus”, “Hey I just noticed you filled out that field wrong, can you fix it”, “Hey I am about to send this data off and noticed the form isn’t really done yet?” and lastly “hey I know at the time you sent this the form felt like it was good, but the server just called me and told me its wrong, so can you go fix” .. point is, IDataErrorInfo implementation is only going to work so far.
I focus on this area is this is where at times bugs tend to get brought up and it can be a case of where the most effort can be spent trying to undo user fail. Its important that one approaches this in a way that makes sense to the end user and you also find ways to decode the error in a meaningful way – not one that aims to reduce the user to a dribbling mess of “I don’t speak computer geek?”

Validation styling and alert states are crucial.
The BackgroundWorker. Its not about just fixing the UI look and user experience fail points its also about shift the work into areas that make the application feel snappy. In WPF the UI Thread is an absolute pain in the butt when you at times talk to WCF – in that I have seen a lot of apps that keep the entire workload under the one thread only. In Silverlight this can be a fairly low risk situation given Async works ok, but in WPF it means your application grinds to a halt until the service layer comes back from the dead. It also isn’t just a threading issue its also a latency issue as well.
Latency is a buzz killer in making the user feel like the application is responsive, it creates this effect in which the user punishes themselves and attempts to pay their debt by trying again and again etc if left unchecked. Its situations like this I look for ways in making the user aware that they did a good job but at the same time finding ways to NOT remind them of time – as time is the enemy given each millisecond you are banking hate debt with the user?

This is where I look for ways to use some slight of hand techniques to convince the user there isn’t a problem and everything is fast / efficient in the software. I also may lie to the user if I can eg Please wait while Security authenticates you” – damn those Security Nazi’s I agree, it sux but what can you do – its actually an effective way to pacify users as you all collectively shake your fist at IT Department for always riding you about security – when I reality I’m waiting for blah service to wake up from its slumber?

Point is, find a common villain to throw under a bus or find a way to keep peoples attention away from their watch (eg: Now herding llamas for the great stampede …< MAXIS do this in their games, it works)

I’ll leave there as this is turning into a tomb of gospel around how I approach my job, but the point is that I do have a process and there is a method to my madness. I’ve been in a lot of fire drills with WPF/Silverlight and WP7 and I’ve now settled on some patterns that have produced results around nice UI/UX and customers happy.

The reality is this though, you could of saved yourself minimum double through to quadruple the amount of money it cost by bringing me in early instead of late. I can’t say it enough, engage early and upfront you will save, you may be skeptical htats fine, but either way a person like me gets paid – its just a matter of how much?

Windows Phone 7 – Where is Don Draper when you need him?

Posted on October 13, 2010 by Scott Barnes

I’m looking at the latest in many of bad experiences found on Microsoft.com regarding the new improved Windows Phone 7. My first thoughts are, I guess the budget was low this year for the website but then thinking on it i’m probably going to wager that around $200-$500k USD was probably spent on this site via some internal global vendor.

Let me deconstruct the site so you can maybe get a sense of what I see (Lots of visuals). I’ll also compare it to the already entrenched and spark of creation for this phone – the iPhone and its respective site.

Value Propositions.

If you’re taking a product to market, you pretty settle on what you would call the “Value Proposition” in that its your initial promise that you want people to remember the most – it’s what I call the impact / aka upper cut. Windows Phone 7 isn’t clear on what its main value proposition is, its a phone OS which is fine, but what does this phone do that all phones don’t do. More to the point, why did Microsoft spend so much time and energy getting this phone ready for market – what’s the secret sell or sizzle that I’m about to be knocked over in its sheer awesomeness?

Comparison.

Microsoft

The very first entry page of the site (assuming I come in from here) puts me through approx 5sec animation of what the introduction to the phone is. The first parts are a bunch of squares or tiles which overload me with brands ranging from Bing to Zune (care factor, as these aren’t a household name as yet world wide)?

Secondly I’m hit with what I can only describe as Dr Suess style messaging.

…Say hello to Windows phone
the only phone with live tiles.
less stop and stare more glance and go
less out of touch more in the know?..

I don’t even know what that means. Live tiles? stop and stare? is that even a problem? its less out of touch and more in the know? what do you mean?

It’s one thing to open with a question to trigger an action, its another to completely ignore you and confuse.

Looking beyond the animation and assuming you can read the sequences fast enough, let’s assume the user scans down to the bottom, where I can only guess as being the main hubs of navigation.

Explore my choices.
I’m guessing this is a good start for me to shop for the said phone, important if i already know ahead of time about the phone and i just want to jump straight into purchase mode.
Make Windows Phone Yours.
Demo area, good, so you have a virtual phone I can play with. I’m liking this, as rather then sit through silly marketing speak, i can just play. I click on this, boom, Facebook.com – guess what guys, most corporations around the world specifically block Facebook as a URL given the ample amount of time waste that goes on there (hey i disagree with this but it is what it is). Furthermore, why am I now on facebook? and why aren’t i able to just play with this inside the same website? what If I want to explore what else you have to say? where are my options?
The place to shop?
Oh so this is Microsoft’s “AppStore” ok, I’m seeing some potential here, but can we first establish what the phone is first? I’ll get to that a bit later maybe?

Where is the navigation? oh its the small text above in vertical stack formation with poor spacing.

Apple

The first thing you see when you visit the iPhone website is a highly impact visible slide show presentation on the value proposition of the iPhone4. Its bright, its impactful and no branding overload. They could of went to town here on Google maps, iTunes, eBay, Safari etc.. they didn’t, they kept it on point and you focused – here’s what the phone can do that we think is important upfront.

They also underpin the value propositions with clear well spaced list and palatable enough read around what the said slide show probably just told you should you still not pay full attention. The point is, they are reinforcing what they think you should be focused on and not distracting you off the site. They are making the pitch to you, and are working hard to retain your full attention.

Looking below this page, notice how they break the navigation into areas of interest. It essentially is attacking the user from a matrix of context as in for those who just want to know what;s inside the phone, features is probably a good bet. For those who are interested in the design of the phone, again, feast your eyes on that link called – Design. OS itself your cup of tea? here you go, here’s whats new and old in the operating system. Apps, Gallery and Technical specs again clearly partitioned and you can at a glance get some deep understanding of what this phone story looks like.

Apple are very good in their website design comparison to Microsoft, but my points above here is that you are immediately left with a sense of both what’s potentially inside this new gadget as well as given a sense of spatial awareness around finding out ways to find more information should the value propositions still not convince you to go into a store and play.

The main important piece here is getting you into their stores, buying online is fine but lets face it, you will most likely want to play with this phone physically first before you buy. Once I have you in my store i can attack you from all points via customer service reps through to convincing you my promise (value prop) is true. Trust.

Less is More.

Moving beyond the initial sell, let’s go deeper into the site and explore true functionality of the phone. Having a sense of awareness of the depth of the Windows Phone 7 is important but at the same time you don’t want to overload them with excess information. Let them play with the phone in store or virtually if you can will answer a lot of that excess data but the most important thing is to attack them in a way that they will appreciate in that – give me the basics, give me what i get that i normally wouldn’t get and lastly how does this look visually!

Comparison

Microsoft.

If you click on Discover you are given what I can only describe is a list of random points that dont seem to have a sense of grouping and lastly a sudden need to cram branding overload into the pitch.

Why do i care about XBOX Live? Bing? Windows Live? Facebook? and more importantly where is Twitter? hey since we are in the mood for name dropping why stop with these.. point is, it’s Microsoft teams pitching themselves first customers second here. It’s obvious and shallow and unnecessary.

The headings are ok, I’m fine with the three (3) sections of break downs, but keep it simple stupid?

It gets worse, I can’t even click on the phone it’s inviting to me that the phone looks virtual, but wouldn’t this be a great opportunity for me to play around with it? explore it? go deeper? ignore your sales pitch and play? as you’re probably not helping me anyway?

As I click on each of the “Discovery Points of Interest” I soon realize that i am first meet with a tagline followed by another click on reading more? I’m all for white space Microsoft but really, this forces my reading habits to slow down to a pace that I’m probably not as comfortable with. Give me the opportunity to speed read through the areas I think could be interesting vs the ones I probably think aren’t? instead I have to go through a 3 click uninspiring process of both reading text and keeping an eye on animation(s) at the same time – i think this may actually qualify for cognitive overload.

More importantly, what is a hub by the way? (I know because I’m an early adopter and its my job to know) but have we clarified what a Hub is on the website btw? I can’t seem to find out the story behind that? Ignoring the Hub definition if you then click on the Music + Videos Hub you will be meet with the similar looking tagline followed by a more action..clicking on the more action you are then given a fairly reasonable looking paragraph about the story of Music + Video. It however still wants me to click more on finding out about this thing called Zune (living outside the US, Zune isn’t known, so wtf is a Zune?). After that click, I’m now taking to a different area of the site with really what I call a “Well good luck, hope you figure the rest out” purpose. There’s no elegant hand off to this part of the site and more importantly you just broke my concentration.

Shallow experience here in the discovery of this phone. Microsoft are being lazy and not really delving deep into an immersive experience that gives me clear precise clarity around what this phone has or hasn’t got. I can’t skip ahead and i’m reduced to a pace that probably isn’t going to make impact.

Apple

Let’s not muck around, Apple are good at their feature break-outs, but the thing I liked the most is you can watch a video on the phone itself (Good entry point to watch that expensive advertisement you put into TV/Online no?)

Furthermore, the page asks one thing of you, and that is “Are you happy to scroll down?” and to be fair its a habitual ask meaning its already baked into all users on the web as part of their day to day muscle memory.

The more you scroll down the more you see what’s inside the phone and its simple, Tagline, paragraph, big visual and a learn more point which takes you to a deeper insight into that feature. They position the phone well, they treat you with respect as a potential consumer and they are working hard to entice you into areas of your interest and less Apple’s.

Apple also won’t burden you with brand overload here and when they do, they do so in a way that is digestible. Constant re-use of the phone and screens within the phone that highlight areas of interest. Clicking on iPod you get a good sense of what Music will look like under the iPhone regime and yes they introduced the brand iPod – but they are allowed to, know why? iPod is ubiquitous around the world its an established brand. Zune isn’t.

Conclusion.

Microsoft Marketing need to wake the hell up, get back to basics and find a Don Draper style character to head-up their online presence. Loose the Barney & Friends commercials and treat this product like it was the first time in the world you’ve told people about the story of Microsoft and Phones. Stop playing a game of hide and seek with information and more importantly down-play other brands if they aren’t as well seeded.

Everyone in that team needs to pick up a book “Don’t make me think” and learn usability 101 mixed with marketing 101. Get people to stores to play with the phone, make them promises online but make sure you can back them up world-wide. This isn’t a US focused product, its a world-wide one and you need to entice the consumers in a way that makes sense to them as well as keep up to speed with your competitive issues.

This phone needs to beat iPhone and Android, and it needs to win.

UX Creator Tip: Fear the surrogate user.

Posted on July 13, 2010 by Scott Barnes

Ever sat on a project and heard someone give their account as to why the user base won’t like xyz feature or UI change? Ever sat in a cubicle and listen to someone rail against the idea of change for fear it would upset the user base to the point where the helpdesk would be flooded with “Please Explain” calls.

Surrogate User – people used as a substitute or representative for users, in order to provide information in design meetings, user testing, and so forth.

The reality is this, end users are surprising beasts and often will surprise you in what they can and can’t do. The end user especially in enterprise is so used to crap-tac-ula software day in day out that anything really that you do as of today onwards is highly likely to be much simpler to what they are used to (especially given the consumerism within Enterprise these days). Furthermore should they dislike the software they aren’t likely to all abandon their jobs simply because of a bad UX decision – as 9/10 they are under duress around crappy software decisions made by other teams anyway.

Instead, the end user is probably thirsty as ever for software that feels simpler to use and actually looks like someone took the time to think about them and their needs instead of how it solves one finite problem only. Software’s job is to react to the end user, not make the user react to it!

End users are also making use of a variety of software so whilst one particular UI pattern that has been adopted is “the way they are used to today” doesn’t necessarily mean they are ignorant of all other UI patterns out there on the market.

The key is to leverage existing muscle memory as much as you can today and less showing off on what you can and can’t do with some of the UX Platforms at your disposal. Be creative but don’t be overly creative, you get no points for showing off.

Layer-in complexity is what I always tell people, as it’s much harder to reduce complexity later than it is to bring it in slowly. It’s also the best discussions to have, as if the business or end users are complaining that the software is too simple – which let’s be clear, I dream of these discussions – then you have more of a baseline to draw from going forward around feature weighting and selection (which plays into UX + Agile in a way).

The surrogate user is someone you should fear in all software projects as they often bring pre-existing bad habits forward and lastly suffer from the “I’m in touch with my audience” arrogance (sometimes without realizing. I’m told that a Surrogate User when done right works, i’m yet to see one of these unicorn beasts, but i’m told just the same.

Whenever I hear someone say “Users don’t like..” my first instinct is to respond “Oh? Did 1 in 5 housewives tell you that or is this something you’re just making assumptions on?” – Meaning is this “I think” or is it “I know”.

Surrogate Users are dangerous unless they are moderated by someone who has the “UX” somewhere buried in their resume, as they can often decode the “personal bias” from the science of what these entities represent.

Project Salvaging is Microsprinting

Posted on June 24, 2010 by Scott Barnes

Microsprinter

Situation is simple, you’re someone who has been brought into a project at its last witching hour, there are not a lot of project management fundamentals in the room and everyone is constantly emphasizing the “we have to get this done, no time” analogies and metaphors at you. What do you do? How do you navigate this and salvage what’s left of the project to turn this around into a productive and usable solution.

Answer is Microsprinting.

The past 6 months now, I’ve been constantly brought into projects that have gone off the rails for one reason or another and it typically comes back to scope creep and lack of discipline in terms of leadership or more to the point communication.

This is why SCRUM is a concept that every developer should borrow ideas at the very least from, it’s not so much a rule book but a communication protocol that all can agree to and figure out ways not to bump into one another.

That being said, setting up sprints that go for week(s) are great but when you’re faced with a deadline that is measured in hours whilst having to also work back from an unmovable deadline you simply need to calibrate your effort to a micro format.

The List.

The way forward is this. You first analyze all the features that were expected to be in the release for the project, don’t worry about who did what wrong or where it went pair shape. Sit down, take a deep breath and focus on getting a list together that outlines all the features needed to be done. Take this list and break it down to a point where it’s not to finite but at the same time granular enough that all can accurately see what the effort ahead looks like.

The wireframes aren’t the spec.

A lot of times I see wireframes and folks are looking at these and going “Ok, I need that wireframe to be designed” which is a perfectly valid request, in reality though as an interactive designer your job is to not just paint pixels here but also decide on how the moving parts become interactive. More to the point, you’re also analyzing each of the boxes that say “news” and thinking about how the data template will look per item in the ListBox and so on, you really need to map this out per screen and come up with a fairly comprehensive list of both the interactive specification as well as a list of visual states that need to be designed end to end.

I say this as a box on a wireframe can turn quite dramatically into 2-6hrs worth a work depending on which direction the interactive designer decides – “Ok this box when clicked now will go to this screen and the transition needs to be fade along with a loading of individual boxes to lead the user as to what’s change in an elegant fashion etc”

Break the wireframes into detail as again the project is off the rails you don’t have time to sit back and create high fidelity prototypes for each wireframe around its interactivity. You simply need to outline what’s likely to be the effort and do the best you can to not screw up given the constant variables of time/budget is much shorter than you’d ideally like to work towards.

8 is the number, not 7 or 6 or 2…

Break your day into 8hr segments and these are effectively the Microsprints. Every 8hrs regroup and triage what needs to be done and what has been done, agree and move onto the next microsprint. It’s also important that you work with a stack ranked list, keep it simple, rank it from 1 to whatever and attack the list one by one until you get to the finish.

Chances are you may have 100 items but in reality given the timeframes are short whilst the budgets are tight; you’re effectively likely to end up with 70 items done at the end of the deadline.

It’s time to start sacrificing and yeah it sucks but if the project had of been mapped out properly from the start you’d have the full 100. The reality is its off the rails, you got to start triaging in a cold but fair way sort through the items that are going to have a chance of life and simply send flowers/apologies to those who want the items that aren’t likely to have a chance at life in this project.

Tough decisions but necessary ones.

Stakeholders are likely to be suffering from denial. “I wanted that box. Can’t we just..” the moment I hear “can’t we just..” is the part where I stop and think to myself “ok, is this a new idea or is this simply a creative way of trying to get agreement on something that just can’t be done”.

It’s now a point in time where you have 6 things on the table and you can only have 3. Choose as if you fail to make these tough decisions now, you will end up having less – it’s a reality and fact.

Don’t shoot the project manager.

At some point the project is off the rails, someone steps up and says “ok, I’m now leading this band of misfits”. It’s important that someone lead, but it’s also equally important that all understand that this is probably one of the worst positions to be in now. Projects off the rails remember, someone just stood up and said “I’ll now assume responsibility for this delivery from here on out” – give them the benefit of the doubt as they just did something you weren’t willing to do yourself.

They may say no more than yes, they may ask you to sacrifice your core beliefs on how things should be done in order for a Band-Aid or two. It sucks, but deadline is looming and having a 115 lines of code to do something that can be done in two may piss you off, but ship it. Ship it is the goal, refactor later.

Learn from your mistake.

Typically after I leave everyone has that exhausted look on their face, chances are some of the folks in the team will vow never to work with one another again. Emotions were high, we got it done, it wasn’t great but we got success.

Put your pettiness aside, understand this, it was a group failure that later turned into a group success. You just accomplished something that not a lot of teams can do, you made the deadline.

The thing is also, that whilst you know there is around 30 items off the list, and chances are the end users have no clue as to what those 30 items were. You’re just beating yourself up over a quality issue vs. an actual specific requirement.

Should that requirement manifest into a missing feature, you have the next round now ahead of you only this time, PLAN it.

Get the interactive designer into the planning meetings early; don’t leave the design to last. The interactive designer is responsible for the look, feel and way this user interface is going to interact. The UI designer is the person who will paint the pixels per state and lastly your user experience / usability rock star is the one who will navigate the cognitive science associated to the UI.

If you find a person who can do all three, lock them in and don’t let them leave. If you can’t find a person to do any of the above, start hitting Amazon and start researching as one of you needs to assume that position and take responsibility early for it.

Developers need leadership, someone needs to be the Program Manager, make them accountable for features getting to developers hands early. Project / Release managers are there to co-ordinate what should come first and lastly when.

You can have SCRUM approach, but democracies are only as good as its people. If the people aren’t clued into its virtues, see the above.

Learn from what you did wrong, don’t nail people to the cross for it..just learn from it.

Embrace MVVM.

If you’re doing Silverlight/WPF no excuses use it now. Don’t screw around, get onto it now. A friend said to me yesterday “..Dude, saying MVVM is half the understanding, once they’ve said it then they now know it..i mean Model..View…ViewModel whats the mystery?”

It’s a basic foundation for all to work towards and it’s just easy to set things in order in a solution.

RIAGENIC is a UX/UI Business.

Posted on June 17, 2010 by Scott Barnes

It’s been a couple of months now since I went full time into focusing on growing a UI/UX business for myself. I thought I’d share my thoughts / notes and adventures along the way so far in the whole Microsoft UX/UI space as a freelancer.

Which are you? a developer or designer?

How far we have come and yet how so little we have learnt! As someone who worked in/with the Silverlight/Expression teams to make sure the message that Microsoft has entered the UX space and that we’re essentially building a mutated Developer meets Designer and vice versa pixel ninja type person, the reality is people still need to put you into a category.

I often find myself torn between which side of that fence line I sit. As to be blunt i can do both, I know every single API inside Silverlight/WPF like the back of my hand, I can code in 9 languages outside of .NET and aren’t script kiddy languages either. I can do 3D and 2D design to the point where many have commented on my abilities here as being “eye for design” or “you are freakish good” but still i’m tormented by having to pigeonhole myself either category.

The reality is people aren’t ready to accept the person who can do both just yet and it takes a lot of proof to build trust that you can do both. I’ll let you know how I go with this journey over time but for now suffice to say, its new territory for me and yet still profitable as I can easily pick left or right and just swim in either pool where needed.

I need a UX guy urgently.

I’ve seen this a lot in the past 8 months. I get called in at the last sprint or towards the end of a project and find myself having to triage features vs design vs engineering constraints. It’s the worst time to engage a UX/UI person(s) as in the end you’re asking for a Hail Marry – “can you make this UI look good and functional oh and don’t change the code base in the process?” is a common brief.

The trick I’ve learnt is that I can do it, it just takes a lot more patience and focus –, and you really need to know every single backdoor into Blend as well as the Silverlight/WPF API’s. IT is a challenge but can be a success if there is enough time and the communication is clear and expectations are set properly.

The bottom line is folks – Engage early and often. Even if its just 1 or 2hrs of their time per week or day, make sure you have someone in the room who bleeds UI/UX from the beginning of the project. Don’t engage late as the price will go up you won’t be able to salvage as much as you think by then it’s not a UX consultation its just a pixel polish.

I don’t use Blend, just Visual Studio.

You are breaking my design heart when you say this to me. Everybody right now who reads this open up Blend and pick a fight with it. If you take the time to get to know it and get to know it well, then when used right can help you out enormously with both Silverlight and WPF development. If you’re a person who likes to indent and keep their XAML neat, stop right now, you are trying to skate up hill.

XAML is not meant to be a hands-on language. It’s a common data format created to allow Design and Code tools to work against the same model without giving up their inherent capabilities. If you are editing it by hand just stop as you are not doing it right.

Pick a color any color.

The amount of times I’ve walked into an engagement and seen a rainbow of colors in the UI has left me thinking that it’s not so much a lack of will power around design it’s more the reality that not everyone is up to speed with color theory (there is a science to color selection).

The easiest tip I give people is this. Typically a brand has one or two colors that are used the majority of the time, then they will use white or black for the majority of the content depending on the background composition (white for dark, and black for light). When you design a User Interface for your next Silverlight/WPF project, pick one or two colors and create a ResourceDictionary called [ThemeName]Colors.

ColorePalette Then take that color and break into four shades (2x dark, darker and 2x light, lighter). Now then select what I call your chrome colors, these are the colors you would use for the outer chrome of your UI, in windows its typically around 4x shades of gray (light, lighter, dark, darker) and label them accordingly (i.e. chrmeAccent1, chrmeAccent2) etc. Keep your color naming conventions abstract (use camel or Pascal case – whatever lights your design candle).

Now don’t use any more colors. Lock that in and use these. Don’t deviate at all from this plan unless you have a designer person in the room who is held responsible for retaining the product/projects brand.

Lastly and this is the most important thing I can say to developers world wide:- Don’t use bold colors. Stick to pastel or light colors as you’re typically not ready for the hurdles that bold colors can throw at you. In saying this I did also notice that the MetroTheme that Microsoft has put into play has me a little nervous as it relies heavily on bold color scheming – which is great and cheap way of avoiding depth in a UI but at the same time creates a potential color scheming hazard around highlights vs lowlights and focal areas of your GUI composition.

Typography is also another concern of mine as too much reliance of ye olde text can put UI two steps back instead of forward – people don’t like to read in general, visuals often handle the workload – review the many articles available on “extraneous cognitive load” for proof of this.

MVVM that is all.

I get that some of you want to get gung-ho with PRISM, MEF or your own framework. Bottom line is this, if you’re starting out and haven’t figured out the tricks and hacks just yet of WPF/Silverlight then you are better off sticking to simple MVVM. It handles 90% of your workload and doesn’t require you to learn WPF/Silverlight and an extra layer of complexity at the same time.

Keep it simple, work to the idea that the code you write in the first year of WPF/Silverlight is code you will want to throw away or refactor later on. It’s natural you write bad code or work onto something that a year later you’ll look back on and proudly say “What was i thinking”. You’ve got your Microsoft UX training wheels on, embrace this openly and you’ll do just fine. Walk into a room and pretend you have it all under control and you’ll fold eventually as you can’t credibly hold that facade for too much longer.

If you can also check out AutoFac as well, this again will compliment your codebase nicely. MEF/PRISM are really for folks who have a team of engineers and are looking to build a complex mammoth size system – that’s the reality even if Microsoft try to deliver a different message – I’m an ex Microsoft Product Manager so I can spin with the best of them hehe.

UI and UX are two different things.

I need to say this out loud. If you ask someone to do UI, then they will do just that; focus on designing a user interface for an existing concept. If you need someone to wireframe and help you figure out how the whole user interface can be built, that’s where a UX person comes in. They are two different work streams just like a developer and a DBA are different.

You can find people who do both, but keep that in mind.

Oh, I need someone local.

Yes, having someone onsite is definitely a goal a team should always be on the hunt for. SCRUM teams etc benefit from this and it doesn’t need to be evangelized further. I will say however though, having someone working remotely can be just as effective especially a guy like me in Australia.

I say this, as at the moment I’m working on a project with Microsoft and it’s working out in our favor as while they sleep I work, while they work I sleep and we’re able to have a show & tell (i.e. remote stand-up) with one another where the design and development work can meet in the middle actually pretty well. As I’m able to say “ok here’s what I’ve done for you, its in your inbox when you wake up” and in the afternoons they’re able to go “ok, here’s what I need for you to start my day tomorrow” and so the cycle is a 24hr development run that works quite well.

It’s not for everyone but so far I’ve found it works without any issues other than an expensive mobile/cell bill from my end lol.

Show me some of your work?

There’s a reason why painters and builders never work on their own house – same goes for me. This blog as weak as it looks is still the front door for my company – RIAGENIC. I need to get off my ass this month and put my site up but the problem I have is distilling what I do into a webpage that makes sense as I’m my worst client (picky, arrogant and will agonize over every pixel and paragraph in the site).

I also need to find a way to promote me but at the same time associate myself with a brand, so that for me is a tricky marketing hurdle. I’ll soon see if I can pull it off!

Find people you can trust and don’t have to babysit.

I’ve worked with a lot of developers in my time, nothing annoys me more than baby sitting incompetence. I’m fine with newbies learning the ropes, that I find far more rewarding as you’re working with someone who has passion and a determination to learn. It’s the people who are lazy and expect you to spoon feed them every 5mins on “how”. I didn’t learn Cinema4D by sitting next to a 3D wizard and ask “Ok so how do I write an xpresso script that makes the wheels rotate per frame”, I sat on Google and the objective was this “Find how to make wheels rotate in xpresso” and eventually I found it. Along the way I learnt a lot about Cinema4D and Xpresso as i was hunting for my answers.

If you work with me, I will set the benchmark high per person I meet, I will quickly assess your skill set and then raise the bar to challenge you to meet it as I do want to work with people who get it and are smart at what they do.

That being said, I love nothing more than coming into a cubicle of developers and feeling like I’m the newbie in the room as now I’m in learning from others mode.

At the moment I’m working with Joseph Cooney (one of WPF’s first MVP and of learnwpf.com fame). I’m learning heaps from interacting with this guy, and its a fun project at the moment we are on. I don’t have to babysit him and he doesn’t have to babysit me. We just looked at the specifications, agreed on a solution structure and boom, were’ off grinding pixels and code.

The next job I go to where they need a WPF/Silverlight dev etc, Joseph is one i’d recommend – again, its about networking and building relationships and finding people who you can trust and work alongside.

Reputation is a false economy.

I often hear how folks worry over their reputation. I’ve watched people spend way to much time either building or recovering it from a bad project etc. The simple truth to this from what I’ve learnt is that if you know your work, you approach things with openly and honesty and don’t dump and run as well as admit mistakes, you’ll come out fine.

Just focus on doing good work, reputation has a habit of following and self regulating itself over time.

At times people I’ve heard bad things about on a project often aren’t the ones at fault as the recruiter / business development sales person didn’t set expectations appropriately or the project was a train wreck well before this person arrived and they were the last ones to hold the steering wheel as it went off the road.

Agile/SCRUM is not a religion.

I’ve seen a lot of developers follow this concept by the book to the point where I often wonder if they are conscious of how badly they have gotten. The correct way and the natural way are two different things and in the end communication is the core piece to this.

Stop arguing over protocol and just focus on establishing a clear line of communication and work on getting estimations as close as you can while at the same time admitting to your fellow team mates the moment you can’t do something or are over on your estimate – just put up your hand and say a simple word – “help”. I personally work under the assumption I’m the dumbest guy in the room, it keeps me calibrated and if you work with me and think “geez i thought that guy knew all of this” that’s fine, but i probably do, but i’ll ask anyway just to make sure.

I’ve felt the wrath of a false hero before, and I ended up having to do his work and mine at the same time only to be burnt for it later on. I could of thrown this person under a bus and said “well actually it was his fault” but in reality, I just absorbed the blame and avoided working with this person since.

That is all.

Note: I am a UX/UI Ninja for hire.

Contact me at scott at this domain.

Discovery vs Delivery.

Unpacking the Discovery phase.

UX Personas are not what you may think they are.

You are in the patterns business.

Discovery integrates with delivery.

Sunlight is the best disinfectant.

Related Posts:

Related Posts:

Related Posts:

The Problem.

The Flash of Genius.

The Objectives.

The solution.

The Terminology

The UI Teardown.

The Conclusion.

Related Posts:

Related Posts:

Meet Mr Wolf

My way or the wrong way.

Related Posts:

Value Propositions.

Comparison.

Microsoft

Apple

Less is More.

Comparison

Microsoft.

Apple

Conclusion.

Related Posts:

Related Posts:

The List.

The wireframes aren’t the spec.

8 is the number, not 7 or 6 or 2…

Tough decisions but necessary ones.

Don’t shoot the project manager.

Learn from your mistake.

Embrace MVVM.

Related Posts:

Which are you? a developer or designer?

I need a UX guy urgently.

I don’t use Blend, just Visual Studio.

Pick a color any color.

MVVM that is all.

UI and UX are two different things.

Oh, I need someone local.

Show me some of your work?

Find people you can trust and don’t have to babysit.

Reputation is a false economy.

Agile/SCRUM is not a religion.

Note: I am a UX/UI Ninja for hire.

Related Posts: