User Advocate vs. Front-End Engineer

I really enjoy doing UI work: being close to the user's mind, thinking deeply about interaction design, and how small changes can massively improve someone's day. But in order to market oneself as a “Front-End Engineer” in the current landscape requires dogged attention to fashion trends, and I'm on Team Evergreen, baby.

Early in my career in web development, I loved reading Jakob Nielsen and Steve Krug, but at some point I had to accept that maintaining intimate awareness of the specifics of JavaScript Framework Du Jour was not sustainable for me. Call me "full-stack", that's fine.

Front-end is the most ripe for résumé-driven engineering. Default skepticism is always warranted for new technologies, but in front-end, it is truly a necessity to avoid lighting your company's money on fire.

I found a rather cathartic post by Marco Rogers on Hacker News recently called The Frontend Treadmill. I fully agree with Marco's take: 

If you are building a product that you hope has longevity, your frontend framework is the least interesting technical decision for you to make. And all of the time you spend arguing about it is wasted energy.

I would not necessarily describe myself as a React fan, but I am very happy that it feels like we finally landed on a framework that can survive for several years, with wide adoption by startups and enterprises alike. Let's go, Lindy effect. Maybe React can be the framework equivalent of what jQuery did as a library. 

Make Your Thing Work Like the Thing Everyone Knows

Users build up expectations about how applications should work based on the applications they're already familiar with.

If you're including a search box in your application, it should work as much as possible like Google. Even if you have some clever idea about how it should work, if that way makes it act differently from Google, that's probably enough of a reason alone not to do it. We'll make the terms they typed in automatically match an exact phrase because our users would probably like that! Nope! They won't because Google doesn't do that. 

How will we let users know that there's fresh content for them to see under a tab of our application? Hmmm...got it! Let's underline the tab title! Wrong! You put a little dot to the side of the tab title, because that's what every app your users are familiar with does.

An invaluable skill for product owners, product managers, business analysts, etc. is that they are widely familiar with popular software and applications. And more importantly they are able to map requirements for the product they manage onto the conventions of other existing software.

Please, by all means, if you're a startup building a general purpose search engine from scratch, go ahead and wildly violate the conventions of Google search. That's literally why you exist. But if you're building a search box for your forklift parts website, make it work as much like Google search as you possibly can.

If you're building a feature for your accounting application where a user can send another user a message, this is not the time to innovate. Just make it work as much like Slack, Instagram, Twitter DMs, etc. 

I feel like well-meaning product managers sometimes misunderstand what innovation means in software. Innovation in the realm of what I would call commodity features is not good for your users. Features that are present in many applications are not the place to innovate unless that feature is at the heart of the value proposition of your application--if your product is that feature.

Wow...if you're violating users' expectations about a commodity feature in your application, you better have a damn good reason. Everyone else: make your thing work like the thing everyone already knows.

Goals, Not Tasks

From my recent posting history, you might tell I'm on a real kick about how work is split up on software projects. Well, that kick continues because I just read a great post from Charles Miller called Decluttered Software Development. I particularly identified with the section in which he discusses assigning goals to software developers rather than tasks.

One of my longstanding pet peeves in the software industry is the way in which some managers treat developers as if they're highly paid instruction followers, like computers themselves, instead of rather intelligent human beings who can comprehend high level business objectives.

Here's Charles:

If somebody takes ownership of a complete goal, they feel responsible for delivering it as best they can, even the bits they discover on the way that they didn’t know about when they took responsibility for it.

When you split a goal into tasks, you are redefining “achieve this goal” as “complete this set of tasks”. Developers own their individual tasks, nobody owns the gaps between them, and anything that shows up after that initial split inevitably floats all the way back up into the project-wide planning process for expensive renegotiation and rescheduling.

Often these things that fall between the gaps won’t be noticed until long after the feature is “delivered”, because nobody at the developer level is thinking about the problem as a whole any more, just about the component parts it was split into during some meeting.

There's a whole class of bugs that comes down to the developer followed very specific instructions without understanding the goal. And a well-meaning manager will take that to mean I wasn't specific enough in my instructions. No! Computers need instructions. Humans need understanding.

I hope I'm not beating this dead horse until the end of my career, but I must again point out that user stories are essential to organizing the work on a software project. If the developers are not focusing on the users' goals, then they cannot make good software. Developers don't need better instructions. Developers don't need more detailed tasks. Developers need understanding of the users' goals.

User Story or QA Story

"What do our QA people do at the beginning of a sprint before the developers have coded any user stories for them to test?"

- Every aspiring Agile team with QA people

Honestly, I'm not sure I've ever worked on an Agile team that did not struggle with this conundrum of keeping QA people busy early in a sprint.

I'm a fan of the maxim: "If you can lean, you can clean"—there's always something valuable to do on a software project at any given time. Here are a few ideas off the top of my head, but I'm sure a curious mind could come up with many others:

• Automate the testing of user stories that were tested manually in previous sprints
• Conduct exploratory testing not directly related to a particular user story
• Training

In case none of these ideas are adequate, there's also the common advice from Agile literature that smaller user stories are better. This idea of smaller user stories is appealing to people who are struggling to keep their QAs busy, because the thinking is that smaller stories take less time for the developers to code, and therefore the QAs don't have to wait as long to begin their testing. Makes sense, right?

So well-meaning teams take an axe to their user stories in an effort to make them smaller by any means necessary. Give QA something—anything!—to test.

Work proceeds like:

1. Write a specification of something.
2. Write code that meets that specification.
3. As quickly as possible let a QA person check if the specification has been accurately met.
4. Forget whether the behavior specified solves any problem for a real user.

By following this path, it's amazingly common to see the goal of "keeping QA busy" become the central organizing principle of a software project. And before we know it, maximum utilization becomes the goal of our sprint, rather than delivering value to users at the end of our sprint.

After a while, it starts to look like QA is our user, not the actual user anymore. We're delivering stories for QA now, not the actual people who need our software.

Snap out of it! There is no user but the user. Value is only realized when the user has it.

It's like acquiring staggering piles of Monopoly money. That pile looks really pretty, but let's not kid ourselves about the "value" of what we've achieved.

We don't work for managers and we don't work for QAs. We work for our users.

User Story or Manager Story

A pet peeve of mine is when people say "user story" as a generic term for any discrete chunk of work the team needs to accomplish.

And I don't mean this in a procedural sense, like you forgot to write the requirements in the classic "story" format like:

As a [type of user], I want [some functionality], so that [some benefit].

There's something very revealing about how teams write their requirements. Some teams have a product backlog filled with "user stories" written like this:

When you click on the "Edit Account" button, show a modal dialog with the title "Account Editor".

The modal contains:

- A dark green button in the lower right corner with the label "Save Account"

- Next to the "Save Account" button there should be a light green button "Close"

- A field with the label "Account Number" is pre-filled with the account number

… 

At the surface level, you can see that obviously this work item is not written in the typical user story format. So you could say, hey, we should write the requirements more like this:

As an administrator, I want to edit an account, so that the account is up to date when information changes.

That's better…maybe…but the real issue is not the format in which the requirement was written. The way a requirement was written can often indicate who we're hoping to please when the requirement is met.

When we approach software development as a series of user stories, we're seeking to please a user with each chunk of work that we deliver.

All too often software development proceeds more like a series of manager stories, in which we are pleasing someone in the team's management chain with each chunk of work delivered.

Some software organizations are set up like a feature factory, in which a management function beyond the development team decides ahead of time which things to build and the specifications of their design, and then parcels these chunks out to the development team on a sprint cadence. 

Feature Factory diagram via John Cutler

The optimum state of a software organization is one in which every person involved in the creation of the software understands the user's brain. Instead of thinking "what would my manager want me to build", think "what would our users want me to build".

Certainly many organizations get along fine as feature factories, but the real magic of the modern Agile philosophy is that we all take a user-centric approach to our work.

We call a chunk of work "done" when we all understand how it pleases a user's need, not just that our boss(es) told us to do it.

A user story is not just a format for writing a software requirement, it's the atom of a user-centric software organization.

Apple’s Flat Design: When Clarity Goes Out of Style

I’m not the first Apple fan to take notice of the sliding quality of the company’s user interface design in the post-Jobs years.

I remember feeling almost personally betrayed after installing iOS 7 on my phone and seeing the many stark regressions in usability that came with the sweeping visual re-design. Apple had chosen fashion over clarity, jumping on the “Flat Design” bandwagon. This was the same company that built its empire on usability! I couldn’t believe it.

Well, now Nicholas Windsor Howard has written a series of articles that go far beyond my vague unease with Apple’s UI design of the last several years, and provides a detailed examination of many specific areas of decline, including screenshots comparing recent editions of Mac OS X.

If you’re an Apple loyalist who’s lost faith in the company’s once impeccable UI sensibility, Nicholas will articulate your rage. It’s a must-read:

[Decisions] that decrease contrast and visibility—thinner text and glyphs, grey where black once dwelled, delicate borders, less shading—are the unpropitious child of an ideology that puts hunger for novelty, minimalism (of a cold kind), and simplicity (of a superficial kind) above calm rationality, common sense, and empathy for the average computer user.

-- The Apple Goes Mushy

Developer-on-Developer Crime

Recently, I read articles by Mike Anderson and Adam Waselnuk lauding the unusually helpful error messages produced by the Elm compiler.

As you program in Elm, you follow a delicious breadcrumb trail of extremely readable compiler error messages until the program compiles and everything works.

I’m always delighted to hear about developers being kind to other developers by paying close attention to the usability of their tools.

Remember when Rails came along? Remember the tons of repetitive crap that came with doing web development before DHH came along with his incredibly thoughtful open source project that was “optimized for programmer happiness”? (I sometimes think of DHH as the Patron Saint of Dev Tool Usability.)

It’s funny how we computer geniuses go about producing so many tools for other computer geniuses that are incomprehensible to said geniuses.

I think in the current zeitgeist of software development is an appreciation and understanding of the importance of usability, design, and all the details that make software (or websites) pleasant and easy to use. But, tragically, that appreciation for usability tends to go out the window when we are producing software for other software developers.

Think of the last time someone on your team was assigned to automate some task for the rest of the team. Every run of that script came with caveats about which error messages it produced were important and which ones you could ignore. Oh, it’s blowing up because you did X first. You’re supposed to run the script, and then do X.

I think we get lazy on the usability of things we make for other developers because we know they’ll figure it out eventually. We’re so used to diving into the most arcane topics and surfacing days or weeks later with an understanding.

It’s just nice to see those rare instances where a developer went the extra mile to produce something for other developers that was not just powerful, but with special attention paid to the friendliness of the thing. Because, you know, we’re people, too.

Stop Validating Phone Numbers

Ah, the siren song of the phone number field validator…

Can you imagine if you asked someone to write down their phone number for you, and then told them: Sorry, you forgot to surround the area code with parentheses. TRY AGAIN.

Oh, whoops, your phone number has to start with a 1. TRY AGAIN.

The great thing about human beings is that they can deal with ambiguity, while computers are classically ambiguity-intolerant. Unless your software needs to programmatically call the phone number, then why does it need to be in some exact format?

Certain kinds of validations just aren’t worth it, as they do more harm than good. As developers, our job is to help the user, not get in their way.

I can hear developers everywhere screaming: What if they fat-finger the number, typing a ‘w’ when they meant to type a ‘2’!? We must protect them from themselves! Is that any more likely than the user typing a ‘3’ when they meant to type a ‘2’? How is your regex going to catch that?

The point is just to be aware that sometimes resisting the urge to validate is the right thing to do for the user. Think twice before you reach for that regex!