Finding Dory - The Nature of Usability

"I remember!" - Dory


Being in a crowded cinema is sometimes a good and a bad thing. I've been spoiled by the recent trend to have cinema houses with hard limits on when children can be in the audiences, cell phone use and even talking to your neighbor.

If you don't have one of these places where you can have a pint and watch a movie, I definitely recommend it. It does wonders for those moments where you are just in the movie and don't want the interruptions.

SPOILERS POSSIBLY AHEAD, oh and TESTING STUFF


First off, Dory's parents are freaking geniuses. Dory reminds me, often, in this case, of setting a user off in a world on their own, and figuring out very quickly you need to set some parameters for that user, or they could get lost or hurt or worse. Her parents immediately take steps to remedy many of the things about their environment that could pose problems for Dory. And they sorta work, but at the same time, they are seeing the small failures and trying to actively fix them instead of shrug at their circumstances and go, "that's how it's going to be". They don't ever approach a problem like that. Granted, it's parents interacting with their kid so I would hope they would be active in their approach to fixing issues.  Which really makes me think, they made Dory's environment more user friendly, some of it by trial-and-error, some of it with mnemonic devices, some just by sheer repetition.

{Writers note: How cool is it that Dory has parents, plural. Not a dead one or missing one, but both. I think that's pretty neat! It also surprised me, because I went in with the notion that certainly something bad happened to them, even before you see them in the small flashbacks.}

The ideas in Finding Dory, making Dory's world a safer one, as best they could, should definitely be mimicked and even used as a measure for usability design and even testing.

No matter what the app is, usability should always approach things relative to the consumer. Will this make sense? Will this allow ease of use? Can I improve someone's situation? The questions you don't think of, often are the ones that come up in progress, much like when cell phones became widely used, the sudden rise of traffic accidents where cell phones were involved increased dramatically, then jumped tenfold as texting became more popular. Maybe that could have been predicted, but I would imagine that since the initial use of cell phones, in the commercial sector, were by individuals that weren't driving themselves or were working from remote locations were land lines weren't available, they probably weren't using the phone and driving. Especially since most of those first phones didn't work very well while they were in motion. Because of this, there have been increases in consumer awareness and even technologies to help prevent distractions with text or calls while driving.

In the case of software testing, and usability, testers should approach everything like Dory's parents. See a problem with a feature and how it works for the user, whether that's workflow, or the placement of a button, say something. Make a plan. Make it better. Make a fix until a better plan comes along.
Be the advocate your customer needs every time. Not just some times. Not just when it's in your face. Or your customer is upset. Invest in people that can see the larger picture, or even have some kind of trend analysis to know when an update would be the most useful. We can't predict the future, but if I've learned anything from the massive amount of Sci-fi I've read growing up and loving, you can sure as hell influence it in a lot of ways. Testers can definitely be that influence. We should be advocates of sound design and changes right along with the UX designers. Wireframes should have a spin through the testing group before they go to development. It should be a practice more companies take, but often rarely do.

Usability Vs Accessibility 

Be especially aware of issues dealing with accessibility. Some things are specifically made for users that have specialized needs, but often, software especially, doesn't think about anyone but the average user first and foremost.

TEST CHALLENGE: Can you navigate your software with the sound off? Or the monitor off, and only by using sound? Can you gray-scale your software and tell the difference between features, buttons, colors? 

Developing something for the average user isn't a bad thing. There are a lot of average users, and by that I mean a lot of people that can read directions and use a computer without any physical or mental limitations. The domain your software inhabits might not need to consider users with specialized needs, or consider it too costly to address needs. But how would this be any harder than addressing Localization problems? I'm sure there is a cost comparison in there somewhere. Something that would justify creating a version of software that is translated to Spanish, while not worrying so much about making voice activation usable and interactive with the software under development. I know it's a complex problem and there is no one, easy solution, but it's something to strive for.

The Knowledge 

If you are actively testing any UI, I recommend a couple of really good books by Steve Krug.


















These two books are quick reads and very good at getting the point across about what to look for in good design patterns and usability. "Don't Make Me Think" is more about web usability, and "Rocket Surgery Made Easy" is more about finding issues with a website and how to run usability tests with prompts and recorders. If you haven't read them already, I think you'll be pleasantly surprised about how easy it is to find issues to fix which do not run into a massive amount of technical debt.

If you have other recommendations or experiences with UI and usability that would great for others to know about, please comment on this blog and share them!

Comments

Post a Comment

Most Read Posts

Ready, Tester One? *GO!*

"I handed my passport to the immigration officer, and he looked at it and looked at me and said, 'What are you?'" - Grace Hopper (60 Minutes Interview) The Grace Hopper quote above always makes me think about my job as a tester. Companies that develop software know they need testers, but they generally have hard time figuring out what testers are and what skills they need in the role. There have many discussions about how testers can be more technical and at some point, coding comes up in the conversation. My response on twitter contained a few things on a list I have, which I created for a client, so they could have a checklist of skills. This checklist was a guideline to determine the skill level of the tester applicant. This is by no means a complete list and I would be open to additions to the list. Feel free to add those to the comments or tweet them to me. For clarity, I took the list of skills I had and broke them into levels. I like games and I lik...
Read more

Learning From Failure: The Tricky iOS Environment

"You build on failure. You use it as a stepping stone. Close the door on the past. You don't try to forget the mistakes, but you don't dwell on it. You don't let it have any of your energy, or any of your time, or any of your space."  - Johnny Cash There are times when our work, as a team, as testers on a team can give us insight into how we can improve things for the overall success of the product. Often those things are issues or defects which can present themselves at the most inconvenient times, in the most inconsistent ways. When we can learn from them and improve things for everyone on the team, the team benefits. When the team owns the defects and the testing strategy, not only the testers, then customers benefit as well. I was working remotely verifying a release and only had simulators and emulators to work with as I was testing mobile builds. Often folks mistrust builds which only use emulated software and not real devices for fairly good reasons...
Read more

Postman In The Pipeline: Newman Delivers

Image
  It's not me, it's the songs.  I'm just the postman,  I deliver the songs....  - Bob Dylan Recently, I've had the chance to work on a project with some other awesome folks which has involved creating a BFF - A back end for front end service. This allows the app to access several API and aggregate calls into something the app can use, or lets the app send information to the BFF for several APIs to receive. Part of the code coverage for the BFF was creating some simple tests with Postman around the business logic and interactions. Learning About Postman I did lots of reading. Lots of reading how others has done things (Danny Danton - big props for being a super help!). Eventually, I came down to a small set of tests which could give us some accuracy about our BFF pipeline and the APIs we were accessing with it. Postman has a couple of options for this, global variables, environmental variables, and plain variables. One of the first problems I came acros...
Read more