We’ve all used operant conditioning. Just admit it. You know, when you take someone into a plain white room and hook them up to electrodes and then start–wait, what??!?!

No, not that.

As it applies to UX, operant conditioning is when an application attempts to change the frequency of specific user behaviors. Things like confirmation modals, success and zero states, some kinds of error messages, form validation, etc. It comes in several varieties but I want to quickly hit on three common ones:

Positive Reinforcement

Rewards, payouts, praise, humor and value are all forms of positive reinforcement that encourage users to continue to do whatever-they-just-did to get more. It’s the addition (positive) of something wanted.

Negative Reinforcement

Contrary to the colloquial understanding, negative reinforcement is not punishment. Silencing the alarm, hiding the error state, removing the danger, and opening the path are all forms of negative reinforcement that encourage users to continue to do whatever-they-just-did. It’s the removal (negative) of something unwanted. 

Punishment = Bad

Not going to say a lot here because computers should not be used for punishment. Like the first law of robotics, applications should not harm humans. Don’t do this or… or… you’ll be punished? But to be clear, punishment is the addition something bad or the removal of something good as a consequence for specific behaviors. Remember that punishment can only be marginally effective at stopping behavior, it can’t encourage behavior. As you know from your horrible experience with your second grade teacher, you never forget punishment. Not only is it a damaging method for changing behavior, once the punishment is removed, that behavior often returns! 

So What is Proper Reinforcement?

So the studies have been done. You can read more here, here and here and much of it applies to humans as well as lab rats. Everybody likes good things and hates bad things and there’s some morality here too: if you’re hoping to induce improper behavior in others, or worse, behavior that is good for you and bad for them? Stop reading now. 

But in software applications there are “good” behaviors and “bad” behaviors. Or more accurately, user actions that will get them the value they need and actions that will ultimately frustrate them. Incentivizing proper behavior is a smart thing and will actually contribute positively to the tenuous relationship humans often have with software.  And there is a real science to optimizing the change in behavior with proper reinforcement. While you might think that rewarding every “good” behavior is the best, it’s not. Users will actually have a higher response rate to reinforcement (e.g. start doing it sooner) and will have a slower extinction rate (e.g. will keep doing it) if the reinforcement is variable, both in time and frequency. In short, this means that we shouldn’t reward our users every time, but closer to about 50% of the time.

Key Takeaways

1. Help users find their value by reinforcing supporting actions (e.g. the animation of a lock icon turning unlocked)
2. Never punish
3. Mix up the reinforcement (e.g. don’t toast “Good job!” every time)

Don’t lie, don’t mislead. You never want to be on the opposite side of truth.

“The signature of mediocrity is not an unwillingness to change; the signature of mediocrity is chronic inconsistency.”

 — Jim Collins, Great by Choice

I was reminded this morning of the tragic burning of Edison’s labs and his aloof response, “Go get your mother and all her friends. They’ll never see a fire like this again … We’ve just got rid of a lot of rubbish.” I’d heard the story before but what I didn’t know was that Thomas carried a coin carrying the latin phrase “amor fati” or love of fate. Clearly he had learned to embrace the machinations of the world that were outside of his control. Completely independent, I was struck yesterday by the haunting duet Come What May from the movie Moulin Rouge. From the lyrical word choice alone, it is clear that these two lovers face their fate daunted but determined.

There are so many things that we cannot control, and perhaps the greater portion of those we sometimes believe that we can. I am reminded today that not only should I NOT waste effort, but recede and embrace the reality that is happening before me. Although driven for greater realms, embrace the present, there is so much to do here.

Now don’t be grossed out, but this is part of what I found in my iPhone 6 lightening port last night. My charging cord wasn’t fitting securely and I was worried that I might have a loose connection in the phone. After confirming a suspicion with a flashlight that lint-crap was causing the connection problem, I fished this out with some tweezers. It’s not a lot, but enough to keep it from charging.

Keep your ports clean.

There is an equation for watts to decibels, given a sensitivity of x decibels, (1w/1m)!  Wattage must double for each increase of 3db.  See here and here for more info.  So that sensitivity (SPL) score is a pretty crucial starting point for a speaker.  Not that adding more amplifier watts is not impossible, just moderately costly.  But then again, in the case of an amplified PA speaker with 700 watts peak (and 350 RMS) then you’ve a lot of power.  By my calculations, taking a 98db SPL woofer up north of 122db, and a 110db SPL tweeter up past 134db – past the threshold of pain!  Also, I’ve read that perceptively, humans believe +10db makes one sound twice as loud as another.

BUT distance from the speaker matters!  On a ratio of 1/d^2, the sound gets softer the further away you are!  If pumping 350 watts through that woofer gets us 122db, standing 52 feet away from it, it will sound just like it we only pumped in 1 watt at 1 meter = 98db.  That’s still plenty loud.

It makes sense to me now why stage monitors are always like 100-150 watts.  Even with all the noise on stage, you’re pretty close which means they’re pretty loud.

Here’s what that speaker system sounds like as the watts are increased:

Contrast that with another system with a higher SPL:

For reference, here is a reference table for decibels:

I just read a great article on Effective Technical Leadership that outlines with a fair amount detail, the role of a great development technical lead. Since then, for the last few minutes I’ve been trying to figure out how a technical lead would fit into the scrum variant that we run, as we currently don’t have tech leads.

# How does this fit with scrum masters, off-team architects and team managers?
# Would you need a tech lead for each functional development team (UI, services tier, back-end), or one tech lead for each scrum team?
# Does an off-team architect become a technical lead if you assign him to a team?
# Do scrum masters have the time and technical chops to be a tech lead?

I realize that team titles past PO, scrum master and team member are no less than subversive to scrum, as the whole team needs to own the process and the results, but it is clear that there is room within the team for these responsibilities. Additionally, several of these positions are, in a healthy way, at odds with each other. Simply merging two scrum master and tech lead would result in only one individual responsible for both the results and the approach, which is a lot of weight to not be spread around the team. Perhaps technical leadership lies outside of scrum, but within agile’s self-organization principle, to be cultivated by the organization’s managers.

I’m going to stew on this for a few weeks. I was inspired by the content of the article, but I don’t know how to formalize it in my organization.

I appreciate a recent article from the Washington Post that discusses the changes to BSA policy and the Mormon faith. As a scout leader of eight years who is moving out of the area of my current service, this change has cause me to reflect on my involvement with Scouting and the policies of large organizations.

One key line in the new resolution that the scouting body approved is worth citing: “…any sexual conduct, whether homosexual or heterosexual, by youth of scouting age is contrary to the virtues of scouting.” That is it, in a nutshell. For the Church of Jesus Christ of Latter-day Saints, this was never about whether the BSA or local scout leaders should try to discern or categorize ill-defined and emerging sexual awareness of pre-pubescent boys and early pubescent young men

“…Some may not see the sacred gatekeeping role scouting plays. They may see only fundraising and not a foundation. Others may brand scouting activities as merely outdoor recreation, but it can and must be shown that BSA is not a camping club; it is a character university centered on duty to God. I quote again from Robert Baden-Powell: ‘The whole of [scouting] is based on religion, that is, on the realization and service of God.’

I am satisfied that a renewed focus on the BSA’s foundational principle – Duty to God – is sufficient for the continued support of the LDS Church and my continued participation, should new opportunities arise.

http://transition.fcc.gov/Daily_Releases/Daily_Business/2013/db0401/DA-13-581A1.pdf

I do not support a loosening of restrictions on offensive content, including but not limited to language and nudity, based on concepts of deliberate placement, isolation or repetition. Offensive language is just that, regardless of its density throughout a program. Individual nudity is not accepted in public, sexual or otherwise, nor should it be allowed on public broadcast. Public broadcast is a common asset and should be appropriate for the general public and if it is allowed to become unsuitable for significant portions of society, particularly families and those who understand the negative outcomes of repeated exposure to vulgar content, it will become devalued as a medium for education, entertainment, marketing and news as viewership decreases. If any change is to be considered, let it be to tighten restrictions to include offensive material that has crept into acceptance over the past years!

The argument that the enforcement of established standards has become excessively expensive is surprisingly shallow and does not address the root cause: despite clear restrictions, media organizations continue to broadcast material that is offensive to the public. At least two other solutions should be considered as well: additional federal funding as granted from expressed public interest and higher fines to further discourage offenses and to subsidize enforcement.

All ranges of appropriate and inappropriate programming are already available via Internet, cable and satellite media providers. Those wishing to experience more offensive programming should continue to turn to these, leaving public broadcast wholly appropriate for all ages and sensitivities.

Lastly, I suggest that any changes to the FCC’s policies be submitted to a more formal public review. Furthermore, please evaluate establishing differing standards based on state or regional standards as well as different bands of public broadcast with varying levels of objectionable material.

We do so well at diving deeply into product features and functionality. We can map so many of the possible outcomes and approaches along a single line of thinking, and then we stop because we’ve either hit bedrock or because it’s time to dive down the next feature. Sometimes it’s a sister feature and sometimes totally unrelated. When we’re tired of diving down features we step back and look at all our features. We wonder which feature sets should be done first, and how many could be done at the same time.

We sometimes ignore a more sensible approach: a single focus that weaves its way through each of the feature sets we’re interested in.

Holistic focus on limited feature sets instead of shallow focus on entire features.