Productivity

The head of my engineering department had a meeting yesterday to talk about getting from requirements to shipped product. He talked about our need to become more productive and more efficient--not because we were dogging it, but because the market place is getting more competitive. He made a couple of points that had the same clarifying effect you get when you've been knocking about in a dark room and you finally turn on the light. That "aha!, that's what I've been barking my shins on" kind of moment.

He defined just one metric for assessing the productivity of an engineering department: $/E
$ = revenue
E = number of engineering employees

The point is that any time you are exerting any kind of effort, you must ask "Is this adding value that someone will pay for?"

He also talked about efficiency, and he pointed out that there are only two ways to improve efficiency:

• Add more value for the same amount of work.
• Do less work for the same amount of value.

The second bullet leads to such questions as "Do we need  a 90-page PRD to build this?" and "How much detail does the programmer need in the wireframe to know what the UI needs to do?"

He did not give the following sobering example, but it is food for thought along these same lines as we go into the new year.

Let's say that your product has a profit margin of 10% and let's say an employee costs $100,000 a year.

A company would have to sell $1,000,000 of product to add $100,000 to the bottom line.

Or it could lay off that employee.

I worked for a guy who had been a colonel in the green berets. He used to describe poor performers as "So and so isn't worth their rations."

$/E

Top four misunderstood expressions

There's a great column in UXmatters on the Freemium Model. What I liked most was that the author resurrected B.F. Skinner and reinforcement ratios. I was talking with my wife this weekend about what I consider to be the three most misunderstood expressions, and this column reminded me that B.F. Skinner is a source of a common misunderstanding--so my list has grown to the following four most misunderstood expressions:

1. "God rest ye merry, gentlemen, let nothing you dismay." It means, "Hey guys, I hope God keeps you happy, and don't let anything scare you." Putting the direct object "you" in front of the verb "dismay" throws folks--that and the fact they don't hone in on the first comma before "gentlemen."
2. "Wherefore art thou Romeo?" Means "Why did you (hunky guy I really like) have to turn out to be Romeo--my enemy?" Wherefore means "why" and note the lack of comma before Romeo.
3. "Suffer the little children." Means "Put up with the kids."
4. And last, my buddy, B.F. Most people interpret negative reinforcement to mean what B.F. Skinner calls "punishment," i.e., the doing of something unpleasant to make someone stop doing something (like the electrical shocks Bill Murray administers in the lab in Ghost Busters). Actually, negative reinforcement is the removal of something unpleasant to encourage someone to keep doing something. If a teacher cancels weekend homework because a class has had perfect attendance, that is negative reinforcement. The key is the word "reinforcement."

Designing for the total mobile experience

I've been working on my first "smart phone" project--investigating how our managed security services portal could accommodate smart phone users. If nothing else, it forced me to take the plunge about a month ago and get an iPhone. Up to now I have used phones to call people and take calls from people. At least I was using a cell phone and not one of those things that hang on the wall and you have to crank.

I was lucky to have done an internal presentation about 2 months ago for IBM on the same topic I will be doing at the STC Summit in Sacramento (Designing user assistance for trial demo software), and the speaker right after me was the manager of the IBM Mobile Research Center. Needless to say, I stayed on to hear what he had to say. (Say what you want about large corporations, how many companies have a Mobile Research Center?)

The most important insight I got from his research was that users distribute a task between their smart phone and their workstation. Smart phones are easier to access than workstations and good for monitoring; workstations are better for doing work than smart phones. I know, kind of duh!, but it's led to a different approach to the UX design than I would have taken.

I am writing use-scenarios that envision the total experience:

• What triggers the user to access our portal from a smart phone?
• How much of the task needs to be/should be done on the smart phone?
• How do we gracefully transition the completion of the task to when the user gets back on our portal from his workstation?

It has really helped me stay away from just redesigning pages to look good in constrained real estate. 

And the way cool part is that my wireframing tool, Basalmiq Mockups, has iPhone templates.

 
Oh brave new world :-)