UX STRAT conference, day 2

I just wrapped up the day by having dinner with Simon of Bristol (okay, Simon Norris of Nomensa) and Bob Royce and Dan Klyn of The Understanding Group. A relaxed conversation with three brilliant gentlemen—an excellent end to the day.

So, the conference. First, I was glad to have met Josh Seiden in person so that I could apologize for my choice words about Lean UX in the preceding blog post. Josh is legit.

As for the topics, again, too many for me to itemize, so I’ll first do a top-of-mind review and then think about themes.

Top-of-mind reflections

First, Aarron Walter of MailChimp blew me away with the approach he shared about using Evernote with e-mail as basically an API to take a very real step at solving the data silos problem. Sure, this may not have been pure strategy, but as a tactic, wow. Thank you Aarron.

Doodles about Aarron of MailChimp's talk on using Evernote to connect silos of data
Sharing these notes in case they help someone else remember the talk better. Click on the photo to view it larger.

Heads-up to my team, we’re going to give this a whirl.

Second, Ronnie Battista had the whole room laughing repeatedly. Awesome presentation style, and great ideas on “The Ten Commandments of UX Strategy.” (Where is our Hippocratic Oath?)

Okay, there you go for top-of-mind.

What was missing?

So, back in the late 1990s I thought of information architecture as something akin to strategy, and we didn’t have the label “user experience.” (At least if we did, I was still too ignorant.) Then IA lost its way amidst all the insane growth of the web, related technologies, and professions. (Yep, I’m over-simplifying history.) I stopped thinking of myself as an information architect and eventually replaced my self-identity with user experience.

Then a few years ago a new generation of information architects began to speak, and among them is Dan Klyn. Dan and his cohort have knelt around the dying embers of information architecture and breathed life back into it, adding tinder, twigs, wood.

IA is starting to throw off heat and light again, and thank goodness for that.

And you know what? This new framing of information architecture looks even more like strategy to me. Now, it isn’t strategy any more than design is strategy—but they overlap in meaningful ways.

Let me put it this way, if I had a performance continuum describing information architecture with one end called strategy and the other tactics, I’d probably describe IA by putting a mark halfway to strategy. (Is that “strategy yet tactics?”) If I used the same continuum to describe UX, I would regretfully right now put the mark on the half towards tactics.

Performance continuum, isn't IA more strategic, UX more tactical?
This is just my gut talking, and isn’t based on any deeper study or rationale. When I’m doing more strategy-level work, I find myself frequently reaching for IA methods and frameworks, not more generalized UX facets of the work. Curious about others’ thoughts.

So, whether IA and UX are cooperative siblings or one contains the other (or they overlap, but not fully), UX strategy seems to me like it ought to sit down and listen hard to what today’s information architects are doing.

Or, hey, maybe we as a UX strategy tribe think that “good” is tactical, yet strategic, not the other way around. Seriously.

(End of that editorial.)

Themes from Day 2

We need data. We need to get it and use it. It is part of the language of business.

Stories and data together can be compelling.

We need to continually adapt UX strategy to corporate strategy in order to stay relevant to the business.

We need to be ambassadors, reaching out to our partners within our businesses. Seek to understand them, even serve them, and build those connections.

Learning is part of culture. We need to continually learn. Be bold in being okay with change (think of Dick Fosbury and how he changed how the high jump is done).

The DIKW pyramid, getting to Wisdom is hard!

UX strategy includes shaping our teams capabilities in ways that will best serve the business.

Customer Experience is often populated with marketing professionals. Are they a group to compete with or a group to align with? Should we just admit we’re all doing the same thing, only that we’ve been doing it longer? Or is there really a difference?

UX strategy does include organizational change (overlapping with changes to an organization’s culture). Think the Vistaprint center for excellence, the innovation program at Citrix, and the leadership changes at Sage over a few years.

Done

And, I’m spent. It’s been said, but can be said again: UX STRAT team, fantastic job. Thank you for all your time and effort. It was worth it.

UX described by Socrates

Lately I’ve been reading from Philosophies of Art & Beauty: Selected Readings in Aesthetics from Plato to Heidegger, edited by Albert Hofstadter and Richard Kuhns, and read a passage that sure sounded a lot like a premise of user experience work.

This is from Plato’s The Republic. Socrates is dialoguing with Glaucon about art.

Of the painter we say that he will paint reins, and he will paint a bit?

Yes.

And the worker in leather and brass will make them?

Certainly.

But does the painter know the right form of the bit and reins? Nay, hardly even the workers in brass and leather who make them; only the horseman who knows how to use them—he knows their right form.

Most true.

And may we not say the same of all things?

What?

That there are three arts which are concerned with all things: one which uses, another which makes, and a third which imitates them?

Yes.

And the excellence or beauty or truth of every structure, animate or inanimate, and of every action of man, is relative to the use for which nature or the artist has intended them.

True.

Then the user of them must have the greatest experience of them, and he must indicate to the maker the good or bad qualities which develop themselves in use; for example, the flute-player will tell the flute-maker which of his flutes is satisfactory to the performer; he will tell him how he ought to make them, and the other will attend to his instructions?

Of course.

The one knows and therefore speaks with authority about the goodness and badness of flutes, while the other, confiding in him, will do what he is told by him?

True.

The instrument is the same, but about the excellence or badness of it the maker will only attain to a correct belief; and this he will gain from him who knows, by talking to him and being compelled to hear what he has to say, whereas the user will have knowledge?

True.

Sounds like UX, doesn’t it? Maybe something from Don Norman about system image and mental models?

How to write better personal work goals

As managers, we require our employees to set goals, and then we measure them against those goals during annual performance reviews. While this is common and sounds reasonable, the goals often end up disconnected from real performance.

This is a waste. (Managers: it’s okay to nod your head in grim agreement.)

Why does goal-setting fail, and what can we do about it? Well, I connected a few dots recently, and have a plan. It requires us to rethink the shape of the goals themselves.

How workplace goals typically fail

This is a real 6-month goal from an employee from about two years ago.

Maintain weekly focus on defining billing business rules.

Not bad, right? Seems do-able. There’s a time-frame. The action is simple: to maintain focus on the topic. It basically means get work done on it every week.

But here’s the thing: That goal failed, but by no fault of the employee.

Instead, that project to work on business rules was scuttled by management (okay, I confess: I did it). So, according to the preset goals for that period, I would mark the employee as having failed that goal. Well, I couldn’t in fairness do that! So while I didn’t penalize the employee, the goal itself became worthless.

I trust that other managers out there agree that this is not an uncommon situation.

I’ve found that my employees’ goals fail most often in these two ways.

  1. The goal is based on a project, but the project changes or is even canceled.
  2. The goal requires another person’s action, but that other person doesn’t take the action.

Is it always a simple dependency problem? Not purely. There are other factors, such as the goal being too large to get done or too generic to measure. In that case I shrug and make my best estimation as to whether it was met.

Another problem is that goals sometimes aren’t that important. We dumb them down to something that we’re sure will happen anyway, but it ends up having little to do with the most important work.

Why would we do this? It’s a play-it-safe reaction to being beaten up by all the previously failed goals. Name it: dysfunction.

But should I gauge an employee’s performance based on unimportant goals? Of course not. That’s small-minded, desperate thinking, yet our typical goal-setting systems prod us into those sorts of goals.

So, let’s see this from the angle of sports goal-setting.

Since 1990 I have been a competitive pistol shooter. Goals are pretty important—and effective.

In that sport, I use two types of goals: achievement and process goals.

My achievement goals are based on scores, and are obvious. For example, at the next match, my goal is to shoot at least a 2430. When I shoot a 2440, I know that I’ve achieved that goal. Easy to track.

But what can I do to make that achievement happen?

That’s where process goals come into play. For this, I point to Lanny Bassham’s Mental Management program outlined in his book “With Winning in Mind.” The book is worth reading, especially if you compete in most any sport.

Couched in the methodology from Bassham, let me explain a process goal that I use when target shooting.

In preparation for firing a shot, I plan and visualize the shot, then I do it. Here are some details.

  1. Gun is on the bench, and I’ve already settled my stance and grip.
  2. I look down at the gun, glance at the rear of the gun and see that the bolt is forward.
  3. I focus my eyes on my gunbox, which is with me at the shooting bench. I’m probably seeing a cut-out X-ring, and a step-by-step shot plan I’ve taped to the inside of the box.
  4. I close my eyes, tilt my head up just slightly, and breathe in and then out, fairly deeply.
  5. As I’m breathing I visualize the gun raising, my eyes finding the sight picture, I see a good sight alignment as the gun is rising, as I start to exhale I settle the gun so the sight picture is aligned to the target at which point my breathing pauses. I confirm that my middle and ring-fingers are putting pressure straight back into the grip while my thumb is lined up parallel to the barrel towards the target. At the pause in breath, I continue maintaining solid sight alignment to the slow count of 1-2-3 as I’m applying smooth, straight-back pressure to the trigger. I don’t get to 3 because the gun has fired and I know it is a good shot.
  6. Then I open my eyes at the end of an exhalation and act out what I just visualized. (If I get to three, I put the gun down and start that shot over.)

So, my process goal is to do that for every shot. It’s an easy-to-do goal that I control, and it is up to me to do it each time. When I do, the results are unmistakable.

That’s the key. When I have the discipline to do that process goal for every shot, my overall performance goes way up. It’s a behavior that I can control that produces a result. This past summer I shot my best 50 yard slow-fire score ever, a 97 out of 100, doing that.

What if I can use that kind of process goal at work?

I was re-reading Bassham’s book as I was mulling over these ideas, and came across a section where he writes:

A habit that separates the top five percent of competitors who win from the other 95 percent who just play is the practice of carefully setting goals. Most people never set them. No surprise there. However, every major corporation sets goals. Every government sets goals. Every builder who builds has a blueprint. Every banker has a written contract on how the borrower is going to pay back the loan. But among individuals, normally only the super successful ever bother to set personal goals and plan their work. (“With Winning in Mind,” Lanny Bassham, pp. 65-66.)

So I wondered to myself, “You’re doing alright professionally, do you set goals?” And it dawned on me that I do, all the time.

I just never think of them as goals. This was the Ah-ha! moment.

So, for illustration, here’s what I already do.

My 2013 Strategic Objectives

Near the end of the year, I review my own annual strategic objectives and identify those that I have for the coming year. I do this in order to maintain a clear head about work.

  • UX: Mature the UX team’s expertise
  • UX: Improve the sustainability of UX @ CE
  • Company: Ship (That one word to me means delivering valuable updates to our services for the benefit of our members. But in notes to myself, I just write “ship.”)
  • Company: Learn to manage the business better
  • Company: Prepare CE for future growth

I know these are not attainable on my own, but I expect of myself to influence our corporate progress towards those objectives more than one might imagine. They are generic enough to leave the tactics open, but clear enough to me that I can look at any period of time and tell if I’ve seen the rate of improvement that I’m okay with.

I’ve done this same thing for 2011 and 2012, and I’ve seen the benefits for the company, although from the outside it must be difficult to see the connections.

These annual objectives provide me some needed focus and an ability to feel like I’ve actually made a difference. Without that, I’d be pretty grouchy.

My Process Goals

When I read that section in Bassham, I suddenly realized that I already have process goals, but I’ve never thought of them as goals. I just know to do them in order to be effective at the level I expect of myself.

Photo of my notebook showing a prioritized daily list.
Using a daily 6-item list is one of my process goals. A simple, thin, pocket-sized notebook is extremely handy for this. I’ve found it better than using apps on my iPhone.

My most frequently used process goal is this:

  • Every day write in my small notebook the top 6 things that I will get done that day.
  • Prioritize them, 1–6.
  • Think of how and when I need to prepare for each item.
  • Keep that notebook on me and refer to it as a guide for my day.
  • Check the items off as I do them.

I use another process goal when I’m sitting in a meeting and I know the presenter will ask for feedback at the end. This too is easy: I use my notebook to jot down reminders of the feedback I want to provide. It’s basic, but effective. Here are two benefits.

  • I can say “I have three concerns.” When conversation ensues over point 1, others already know to bring it back around for point 2 and 3.
  • I don’t waste others’ time as I stumble over my words and try to remember what I was going to say. My memory is frail, and this technique overcomes that.

Are process goals SMART?

If you’ve ever talked with an HR person about goals, no doubt you’ve heard of the SMART acronym. SMART goals are:

  • specific
  • measurable
  • achievable
  • relevant
  • timely

My process goal of using the daily list may, in fact, be the most SMART goal I’ve ever had at work. It is specific, measurable (just flip through my notebook to see the success rate), achievable (it is easy…I just need to have the daily discipline to do it), it is definitely relevant, and by its very nature it is timely.

Whoa. Now that acronym actually makes sense.

And while it isn’t on the SMART checklist, these process goals are activities that I don’t have to rely on anyone else for. If I don’t do them, it’s nobody’s fault but mine.

What if goals can be expressed instead as habits?

So, like thousands of others, I’ve been through BJ Fogg’s 3 Tiny Habits program, and I actually use that lesson on how to form habits. The daily list is one thing I’ve used the 3 Tiny Habits program to help me do better. So, before I considered these to be process goals, I just considered them to be habits. These process goals are also habits.

If you haven’t yet, go through Fogg’s program. Process goals may make a whole lot more sense and you will have the knowledge to actually train yourself to do them. I’m going to predict that most good process goals, which are probably better as daily processes, could be implemented as though they are habits you are trying to form.

So, given this insight, how have I applied this?

I’ve talked with my staff about this approach, and we’ve updated some of their goals to follow this pattern.

Here’s what amazed me: In the very first week I saw improvements in performance and morale. For example, one of my staff wrote this process goal, “Every day, write down one thing I’m proud of.” I believe this simple goal improved this employee’s morale and it has spilled over to others, myself included.

But has the quality of work gone up? Difficult problems are solved by people who can easily think laterally as well as vertically, and a person’s emotional state has an effect on this. More stress means less lateral thinking. So, yes, I’m sure the quality of work has gone up.

Further, this kind of attitude can be trained over time and will help others want to work with this employee. Who wants to work with someone who doesn’t appreciate the chance to do quality work? I know I don’t.

How can you implement this change in setting goals?

Write process goals for yourself. If you are a manager, have your staff do this.

Process goals are:

  • Easy to do
  • Quick to do
  • Done frequently (e.g., daily)
  • About how you work or think of your work, not about the outcome
  • Done by you alone, so that you alone are responsible for doing them

I’ve listed a few examples in this post. Have others? Feel free to share them in the comments on this post.

I’ll close with another quote from Bassham: “The BEST years of the BEST players are rarely foreseen in advance. Why? I believe it is because the elite are not thinking about outcome. They are thinking about process.” (62)

A model for UX design reviews

Design reviews are so important for our work as user experience designers, but they too often fail us. Here is a model for design reviews that overcomes the problems of ego, emotion, and communication that so often get in the way of helpful feedback.

Alaina Kraus, Caitlin Potts, and I presented this process for the Jan 27, 2011 IxDA Lansing meeting.

Roles in the design review process

  1. Designer
  2. Facilitator (may also be a reviewer)
  3. Reviewers (you’ll need at least 2, but 6 may be too many)

Step 1: Designer explains the project and design concerns

At this step the designer shows the design (on paper, on screen, a prototype, etc.) and explains to the reviewers the context of this design. The designer should also point out specific areas that she wants feedback on.

Step 2: Reviewers discuss the design

This is the part that’s going to go against your habits.

The designer steps back and withdraws from the discussion. She should use body language to exclude herself to make it harder for the reviewers to address her. She should instead focus on her listening and note-taking.

Meanwhile, the reviewers are discussing the design amongst themselves. Instead of referring to the designer, they should refer to the design. Instead of talking to the designer, they should talk to each other.

Of course, the reviewers should point out good aspects of the design as well as discuss areas that they’d like to see improved.

By intentionally excluding the designer from this conversation, the dialogue can cover more ground and the feedback can be more honest. Otherwise, the dialogue has a good chance of focusing on a single point or so as the designer begins to explain or defend her decisions. That will derail good feedback, and everyone loses out on good information. People’s feelings are also at risk.

Step 3: The designer rejoins the conversation.

Finally, once the facilitator has determined the design has been discussed enough, he will invite the designer back into the discussion.

The designer can now summarize the notes she has taken in order to give the reviewers the opportunity to catch any misinterpretations. She can also ask follow up questions to clarify feedback she may not have fully understood.

The designer will probably want to defend the work or explain it, but really doesn’t have to. The goal is feedback for her, and at this point, she has it.

Why this method works

This method works because it makes it okay for the designer to simply listen in without feeling a need to defend her work. Likewise, it frees up the reviewers to not have to worry about hurting the designer’s feelings or fear the reaction of feedback taken poorly. While the method may feel a little awkward at first, after a few times it becomes easier.

What kinds of feedback make sense?

The reviewers should provide feedback that matches the fidelity of the design. This is to say, if it’s a rough sketch or task flow diagram, talking about pixel-perfect alignment of the layout is inappropriate. This should be obvious to most of us.

Also, instead of simply presenting your opinion about a design, discuss it in terms of usability heuristics (Nielsen’s list of 10, Tognazzini’s 1st principles document), accessibility concerns, visual design principles (e.g., proximity, alignment, repetition, contrast), and your observations from usability tests.

Where did this method come from?

In the mid-90s I worked at the Michigan State University Writing Center, and we used a similar process that we called the “fishbowl” to teach people to do peer-review writing workshops. In many ways, writing and designing are similar. When I started doing more design work, I recalled this process and adapted it to design reviews. It seems to work great. I credit learning this method from Dr. Sharon Thomas and Dr. Laura Julier of Michigan State University.

Update Feb 26, 2011: Wordcast live on Design Critique

Tim Keirnan over at the Design Critique podcast posted an interview we did on this process. Check it out! And thanks, Tim, for inviting me.

Update July 14, 2011: Michigan UPA workshop

This evening Alaina, Caitlin and I ran this workshop for a Michigan UPA event in Lansing. We had fun and it sounded like the attendees enjoyed themselves while learning this model. Thanks again Second Gear Coworking for letting us use your excellent venue!

How to write release notes

I confess, I’m a release notes reader, and I’ve read some overwrought release notes lately. When you use them like an installation guide, a features list, or a list of software conflicts, you’ve got it wrong.

The purpose of release notes is simple:
Release notes explain what changed with this version of your software. Period.

I hope this article will help you write release notes with clarity and brevity.

Title format for release notes

The title for your document should include specific information:

  • Name of product
  • Version number

For example, if your product is RubberDucky and this release is version 3.3.5, the title for your release notes document should be RubberDucky 3.3.5 Release Notes.

Make the title big and bold at the top of the page. Refer to it in links exactly as the title reads.

Consider following the title with these bits of information.

  • One sentence overview of the product
  • Date of the release
  • System requirements
    • Note changes, like “Discontinued support for Windows XP.”
  • Link to installation instructions
  • Link to a user manual
  • Link to a release notes archive

Other sections in release notes

Break the release notes document up into sections, each with its own heading. Here are some sections to consider.

  • Additions
  • Removals
  • Changes
  • Fixes

Keep the actual descriptions brief. Release notes are often little more than a bullet list of updates, and that’s fine. If there are a series of small technical changes, try to describe them as a theme. For instance, “Improvements to the communication between the software and our servers.”

However, if there is an update that is important for users to understand, do not sacrifice clarity for brevity. Write enough of a description to explain the feature, but no more than necessary.

How do you know if an explanation is too short or hard to understand? Ask someone who is familiar with the software but doesn’t really know about the release to read the explanation and explain it to you in his or her own words.

What about personality?

Release notes should be easily scannable, and inserting witticisms should be avoided. However, if the company is proud of some feature, it doesn’t hurt to brag about it, so long as it is brief.

Here’s a nice example from TextWrangler 3.0 Release Notes.

Brag about it. Snippet from TextWrangler Release Notes.
BareBones Software inserting a little attitude into their release notes.

What about posting existing, known defects?

This question quickly becomes a philosophical one. In my opinion, a company should be transparent about known defects with their software and earnestly try to fix those problems. You can see this type of behavior with some open source projects in that they have a public defect tracking system. The bugs are out there for the world to see. With enough of a user-base, defects with your software will probably become known eventually anyway.

However, I do understand that in some cases advertising known-defects is a security and stability liability and just shouldn’t be done. My preference is that that sort of decision is made on a defect-by-defect basis, and not as a corporate blanket statement.

Regardless, known defects or incompatibilities do not belong in your release notes document. You could, however, link to a list of them in your release notes.

Organizing archival release notes

What do you do with all those release notes from prior versions of your software? Archive them on your website so you and your customers can get to them.

One page, all release notes

If your release notes are brief, you might want to include each version on a single page. The most recent release notes should be at the top of the page. Fetch Softworks currently takes this single page for all notes approach.

One page of release notes per version

For the sake of clarity, I would prefer to have release notes for a specific version on that single page, with a release notes archive page that links to every version. BareBones Software takes this index of release notes approach.

Some companies keep a current release notes page up-to-date so they don’t have to continue updating links. Again, BareBones follows this approach: http://barebones.com/support/bbedit/current_notes.html

Do you have good (or bad) examples of release notes?

Not having seen any “best practice” document for release notes, I wrote this article. Do you agree? Disagree?

If you have examples of great, or really awful, release notes, please comment with the web addresses so we can all see them. Thanks.

How to aim with iron or open sights

A guy in his 50s a few benches to my right was thumbing .40 cal cartridges into a pistol magazine.

He had arrived when I was about to box up my gear and head home. But, I had seven rounds of .22 leftover, so instead of letting them roll around in my gun box, I loaded them into a magazine. I already had 10 shots in my paper target at 25 yards, so instead of causing problems with scoring that target, I decided to find something else to shoot at.

I rotated slightly to my right, raised my right arm, and lined up my iron sights on a 12-inch diameter steel disc about 125 yards away. It was painted yellow. As I steadied my breath, I raised my Ruger Mk II pistol a little to account for the bullet’s drop at this longer distance, and let off the first shot.

I was pleased to hear the distant ding of the hit against the steel plate. I released the remaining six shots and they each dinged off the plate. I was pleased, but, frankly, surprised. That was a fair dose of luck.

I packed up my guns, and let the the older man know that the line was safe for him to go down range.

I could tell he was curious where the dinging noises had come from. He was scanning the range right in front of us, but there was nothing metallic there.

“So, what were you shooting at just now?” he asked.

“See that yellow disc out there?” I pointed to the steel plate hanging at the 100 yard line.

He was incredulous, except that he had witnessed it. I felt fortunate that I was packing up and wouldn’t be pressured to repeat it, but, hey, why let on.

It turned out that he was a federal agent from downstate on vacation. I was pleased that a federal cop from downstate would have an appreciation for how a kid from the Upper Peninsula can handle a pistol. Strange vanities.

That was about twelve years ago, and while I don’t shoot as much now as I did then, I still appreciate the look of a good sight picture.

Aiming is one of the fundamentals of good shooting, right? But there is actually a lot of complexity to talking about it. There are many different kinds of sights, and some are electronic like red-dot scopes or laser sights. Those have the benefit of being completely obvious on how to use. Put the dot on the spot you want your shot to land. That’s all there is to it.

But for those without a dot, knowing your iron sights is pretty crucial.

I shot a dot-scope for a few years, but gave that up and went back to open sights on my pistols. I like them, and I like that it takes more practice and discipline to use them.

So, here’s what I know about shooting with iron sights.

The fundamentals are that you have a front sight, probably a block or a post, that makes an “I” shape and a notched rear sight that makes a “U” shape. You put the front sight right in the middle of the notch of the rear sight. The tops of the front and rear sights should line up perfectly, and the front sight should have the same amount of space within the rear sights to the left and right.

Proper sight alignment has the front sight in focus and rear sights slightly blurred.
Good sight alignment: Front sight in focus, rear sights slightly blurred. Focus on the front sight, not the target.

When you aim, you focus all your attention on the front sight, observing it’s alignment with the rear sight. The rear sight should be slightly blurred, but the front sight should be crystal clear. Study it. Meditate upon it. Let everything else vanish.

The front sight on my Clark .45 has a slight ding on the top right corner, and when the sun shines at a certain angle, it stands out to me. These are things that you only appreciate if you find yourself studying the geometry of a front sight for long enough. It’s a good thing.

Please note that I have not spoken about the target. If you find yourself looking at the target, you are probably not going to fire a good shot. This is the counter-intuitive part about aiming: in order to hit your target, you must not look at it. It is the front sight and its alignment with the rear sights that should have your attention.

Of course, as you acquire your sight picture, you will probably need to glance at the target in order to line up the sights in the first place, but once you have that, forget it and focus on the front sight.

Focus on the front sight.

Update: May 3, 2010

Here’s a nice image of a variety of types of open sights with a legend. This image does not show the rear sights and target blurred like they would be to your eye, but it’s still a nice resource.

Update: January 10, 2014

The illustration and ideas in this blog post have been included, with permission, on page 59 in a recently published book by Andrew Smotzer, Guns for Personal and Home Protection. Thanks Andy, and congratulations on the new book!

Update: October 21, 2016

This 12-minute video from Chris Sajnog is perhaps the best thing you can watch to understand what it means to focus on the front sight.