Communication and education as a team sport

It occurred to me today that a conversation I had with my boss of the time nearly 10 years ago encapsulates the problems I have today trying to promote the UX profession.

I was asked to work in a way that suited the Project Manager’s defined methodologies and my answer “I don’t work that way” was construed as “I won’t work that way”. The boss hit the roof and reminded me who was boss.

Of course I realised straight away that he had misconstrued my statement, meaning and level of deference to the management hierarchy - I should have promptly explained the WAY I work best, then proposed a path that would suit us both.

We both needed to find a path, to understand each other's problems, capabilities and worked as a team to solve the issue; in effect we needed to educate each other.

Levels of priority as a concept - seriously!

So, what does "High Priority" really mean?

A requirement has come through that a job must be able to be marked as "High Priority". Simple enough? Well, as in all things UX, the answer is yes... and no.

The reason I started asking what it really meant was that I'd seen users game the current system's definitions and implementation of a "High Priority" setting. Their "High Priority" had a business rule that meant that a warning flag was sent to a senior manager if a task was not completed within X days of it being started. The task included a number of information gathering and data entry tasks that very often could take more than X days since there were sometimes a lot of dependencies (including other tasks that had the same time limit!).

Their solution was to do the entire job manually outside of the system that was built to manage the collection of the data. The data set was collected in a word processor document and only then did they start the data entry task inside the system by copy and pasting the results from their information gathering, and finally save the results in the previously time-limited application.

All on the same day.

OK, so the job got done, you say. But the reporting and time management data that could have been gathered at the same time was totally useless. There was no way of knowing how long each different task took, so efficiency reports were useless. And the data was captured outside the system, so managers have no idea at any specific date or time the state of each task with their individual workers, or within the team as a whole.

In the end, the "High Priority" setting was no solution, and added risks to the system that should not be acceptable.

So, how do you fix this to help all users?

You must go back to the original idea that prompted the concept of a "High Priority" setting as the solution.

Again I ask, what does "High Priority" really mean?

High priory really in this case means "I want this done quickly". But high priority as implemented in the example above meant “get this done within the time-limit or you’ll be reported to senior management”.

The aim is 'fast work throughput', but the solution is ‘cover your arse’.

The point is there should never be a need for that non-perform flag to be sent to the senior manager. The workflow and operating procedures should have the potential for manageable escalation built in.

The problem can be broken down into a number of points:

1. The business rule is linear and too rigid.
2. The rule is often unachievable as the same rule can apply to individual sub-sets of the measured task.
3. A consequence of the rigid rule creates inaccurate metrics...
4. …so analysis is based on inaccurate data.
5. There is no gradual escalation of the issue; just a big stick, 
6. Users that run out of time do not normally just work faster, they cut corners or find a way of conforming to a rule that is outside the original intent of that rule (as in the case above).
7. The flag is being used by the manager, not the team.

So from a usability point of view, how do we solve all of those issues?

Let's look at that list and reverse it.

The last point, point 7, is in my list is actually the starting point for a better way to design the system. The team should always be the driver, not the manager. The users must be given visibility of that flag and provided with up to date information on how to beat the flag rule without going outside that rule’s intent.

In point 6 we see that although the rule's intent was to push high priority tasks through the system first, the result of gaming the rule meant that the high priority flag had an unintended - and potentially dangerous - outcome. Tasks escaped the 'system' and was not visible while outside that system.

Point 5 shows that there is an heavy imbalance between the managers of the system and the people actually doing the work. Rigid rules and big sticks only tell your workers that you don't trust them to complete a task successfully; a task they have been hired to do after going through an interview process to allow a manager to pick the best person for the job. If you, as manager hired them, why don't you trust your own judgement in them? End even if you didn't do the direct hire yourself, isn't part of a manager's job to make sure their team has been trained to do their job?  

Now, points 3 and 4 are linked: inaccurate metrics creates inaccurate data. Inaccurate data means that decisions are ill-informed.

Point 2 really means look at the whole system. Creating arbitrary rules made without looking at the holistic consequences of that rule is just plain bad management. And leaving that rule in place over several years brings us to the initial point.

For in point 1 rules need to be degradable. In programming every decision has options - the 'if' statement is there for a reason - it allows a programmer to look at what happens next if an event occurs. It defines options. It must include, within reason, get-out or postponement clauses that allow staff to do their work in a flexible - but still legal - manner. By all means you still need a red flag event, but that is the LAST step, not the ONLY step.

In the case above only one rule was made. Make this task high priority. The intent was to speed up work for high priority cases. The result was to put a major flaw in the system. That is NOT why we make a task high priority.

 

Where does design start?

I'm sorry to have to break it to all you software developers out here, but people do not get up in the morning and say "I need a computer-based solution to solve my business problem".

Chop the first bit and you are left with the bit that matters. 

"I need to solve my business problem."

Yes, we may use a computer-based solution to help in the process, but that is not the whole solution. There are other steps in every solution's set of tasks that rely on steps executed offline.

People don't go online to buy a book. They go online to find something to read. People don't use iTunes to download music. They use iTunes to find something they want to listen to. Buying the book and downloading the music is how they reach their goals. The technology is an enabler, and enablers work best when that enablement is as frictionless as possible. 

Good design does that.

So, where am I going with this. I try to look at every problem first as a design problem. Even though I work in software development, I don't see software as the solution. It never is. It is an enabler to the solution. 

I've worked on so many software projects where the business requirements are often based on what they think they need based on just moving their offline process online and not even leveraging the power of the online tool to improve the process itself. And that is as far as they can see. It is like saying "I want the same as I have now but I want it to suck less!" They rarely actually look at the original problem the system they are replacing was supposed to solve. 

In some cases they may already have software once solved a problem years ago when it was first launched, but over time the problems that needed to be solved became more complex and the software no longer covered all of the bases. The answer for many businesses is to either add more features to the existing mess, or just use the bits of that mess that still work at a pinch with a bit of work-arounds thrown in, and create another system to fix the bits that don't work anymore.

In both cases the thinking is to use software processes and the problem is solved. The software will enable a solution, yes, but good initial design before the developer even starts coding can make the whole thing frictionless.

Good design does that.

The new sport of Apple bashing

Harking back to the mid 1990s I well remember the doom and gloom that PC users heaped onto the poor Apple Mac user.

Remember these gems of wisdom of the time?

"It'll be dead before the year is out."

"Microsoft won because they have a better product."

"Apple only make toys; they are not serious !"

Yes, "dead by the end of the millennium" company Apple have built a company on the back of good design and only releasing the best products that just work.  The "i" products we know and love - iPod, iMac, iPhone and iPad.

And now we have Apple, the second largest company in the USA by capitalization, having to defend itself against every man and his dog ripping off their designs and, and a new idiotic chorus of clueless pundits saying that Apple is "this big powerful bully suing the little guy"..

Well, first, I wouldn't say Samsung is a "little guy". I even own some of their appliances and home entertainment products. But I would say that the Galaxy family of tablets and smart phones is definitely riding on the backs of Apple's design and innovation.

But the really sad part is that Samsung's designers actually have the industrial design chops to have gone their own way. They have done it before, so why be a follower now?

I'd say it is because of the gutless and vision-deprived company wannabes who manage "brands" these days, rather than put in the effort to build a company that has soul, knows where it is going and tries to excel in everything it does. It just degrades the efforts of staff who really want to prove to their bosses and peers that they have the talent and commitment to produce great design and great products, but aren't given the chance to prove it.

The same can be said for companies that would rather poach gun-for-hire talent with no 'skin' in the game than actually train staff in the "way" (to paraphrase HP,) that they "do" design.

Designers don't design to shift boxes, they design to enrich lives. Apple designers get to do that, but not many others are part of something as vibrant and dynamic as Apple.

Pity.

Flood Relief and Online Collaboration

I must say I've had a wonderful, if stressful week, and of course it involved building web sites, but this time I was pleasantly involved in a rather unique musical adventure.

A mate called me from Brisbane - yes his building was flooded out - and asked if I could help a friend of his put together a web site in only 1 week in aid of the flood relief efforts up there.

We've been affected all around Australia by the floods first in south east Queensland and now in north west Victoria. After 10 years of drought  in Australia it is both welcome but also awe-inspiring to witness the power of nature, and how she can really bowl a yorker at you.

So this group in Brisbane was getting together a group of 20 bands and musicians to donate a "b-side" song each to help raise awareness for the official Premier's Flood Relief Appeal. The idea was to enter an official receipt number into the home page of the site and they donator could then get access to a whole album of downloadable songs from the unlocked downloads page. I was asked if I could help out, and as always I said yes before thinking about the amount of work involved, or how to actually achieve what they wanted.

Now initially it made sense to me just to run the campaign from Facebook and Twitter, and this was great for promotions and spreading the word, however we still needed a site to host the downloads, the band information and links to their MySpace sites, so I went looking for a content management system (CMS) aimed at unlimited downloads and one that had a stable of musicians.

I found several sites pitched at the music industry but the one that fitted the best - with a little manual tweaking - was the FourFour platform.

So, for most of my spare time over the last week I've project-managed the whole job on Basecamp and along with the group in Brisbane I helped build the site using its templates and some custom coding.

Now I'm quite used to Basecamp - I've had an account for about four years now - and it always amazes me how people who I invite into using it just "get it" pretty well straight off. It is a wonderful collaborative tool that allows all messages to be in one place, and since the team members all worked at different places, and the organisation of who was doing what was very casual - a milestone would be set and somebody would just volunteer within an hour or two and it would be done.

I also worked with a graphic designer from Brisbane (who was shanghaied just like me I suspect ;-) who did the logo in a very tight deadline and with an amazing amount of options in the couple of days we had to get the look of the site right. The only hiccup was a last minute change to the maroon of the Queensland rugby team from the original colour that was a little closer to the AFL football team's colours. As always in Queensland, rugby won!

The site is now live, and we did miss the friday deadline, but we did hit our next one which was before Australia Day. So if you want to have a look at a weeks' worth of collaborative work that started with a phone call on a Monday and was live a week later, check out Bsides4Brisbane.com!
Bsides4Brisbane.com!