RSS

There are no small changes

Pic of Review screen

“We want to limit the length of a review in our application to 140 characters, because we may want to use SMS at some stage. That’s a tiny change, right?”

Wrong.

There are no tiny changes when you’re committed to delivery quality software. Let’s look at the above case. A naïve programmer may well get this coded in three minutes, after all it’s just an if-statement.

When handling requests like this, experience has taught me to ask a few questions…

Delivering a good experience

In the unlikely event that we have answers to hand for all of the above concerns, we’re still not finished. Performing a round trip to the server is a messy way to handle errors. We can do better than that. Well if we’re going to do client side validation then I’d have a few more questions.

We’re still not done. Look at this from a users point of view, they’re already frustrated by having to limit a review to 140 characters for a bizarre reason they won’t understand, and now we’re asking them to guess how long their message is? There must be a better way. Let’s at least give them a character counter. That raises a few more questions…

When all the issues are solved, and we’ve implemented the character counter, styled all the errors, implemented the server side validations, and checked it in all our supported browsers then it’s just a case of deploying it. This presents a new set of problems, as we need to pick a time when no business critical actions are being performed and have a team ready to roll back if necessary, even when it’s highly unlikely.

All of this is happily ignoring the fact that users will wonder why someone wrote an eighty word review just before them and now they’re only allowed write a 140 character one. Who wants to handle feedback on that one?

And don’t get me started on how we’re gonna deal with all the funky characters that are doing the rounds these days, thanks to CopyPasteCharacter. Good luck sending them in a text message. We’ll need sanitise the input string for rogue characters, this means new error messages, new server side code. The list goes on.

Once you get through all this you will have your feature in place, and this is just for a character count. Now try something that’s more complex than an if-statement. There are no tiny features when you’re doing things properly. This is why as a UX designer you need a good understanding of what it takes to implement a feature before you nod your head and write another bullet point.

This is why plugins and swhitelabel solutions can be troublesome. They make the addition of features look deceptively easy. Adding a plugin to a codebase is easy. Integrating a new feature within an existing application is not. When you’re striving for quality there are no small changes.