Category Archives: Design

Is Easy-to-Use Hurting Us?

There’s an inherent tension between designing something so that someone doesn’t have to think, and cultivating the drive to learn something new. Are we dumbing things down and perpetuating the ‘entitlement culture’? Is Google Making Us Stupid? from 2008 describes the downside to increasingly easy and instant access to vast hordes of information.  We used to spend days in a library to find something that now takes us seconds. We don’t have to spend energy memorizing things because we know that google will be there to answer our questions time and again. There are plusses and minuses to the situation. Better access to more information for more people, shorter attention spans and information overload.

I remember trying to figure out how to use the TRS80 that my parents bought back in the days when I was playing Oregon Trail on an Apple at school. I didn’t have the foggiest idea how to make it do something productive. We were so naive that we didn’t know that we had only purchased hardware and that we needed to buy software to do wordprocessing. So we used it to play the one game that came in the box and eventually forgot that it existed. (My parents still bemoan how we didn’t use what they spent hard-earned money on.) Now, if someone gave me something that I wanted to learn how to use, I have unlimited resources at my fingertips. If I can’t find the information on my own, I can reach out via facebook and twitter and get the answer from another person. If motivated, I can figure nearly anything out because I have the information available.

But are we creating a world that conditions people to be less motivated because information is so accessible? Do we get frustrated more easily since we have less practice staring at interfaces that aren’t self-explanatory? I say no for a few reasons. Primarily, there are so many complex problems waiting for us on a daily basis, we really don’t need to be concerned with doing harm by removing a few roadblocks from someone’s life. We still have world hunger, poverty, wars and omelet flipping to figure out. If we are making it easier to deal with the little stuff, or streamlining a task so that a person has more time to spend with their kids, I say bravo!

Additionally, we are opening doors for individuals to learn things of interest. Children are no longer limited by the quality of their local library and their access to transportation. If you want to learn to play guitar and can’t afford lessons, there are vast online resources. Struggling with math or literacy? Skype with a family member who can tutor you. Endless possibilities. A computer and an internet connection maybe the most important thing to provide for your child’s future success. (I don’t want to open up that can of worms here at the moment, though.)

We should acknowledge this tension between what we require someone to learn and understand versus what we simplify and automate. It’s not always bad to make someone think or learn in order to use an interface. Let’s just make sure that it happens for the right reasons. I don’t think technology is making us stupid. In fact, it’s freeing up our minds to focus on the big, heavy ideas and connecting us with others so that we can work together.

 

Crush the Real Issues to Make Customers Happy

Your project goal is to update a business solution that is slow and laughably outdated. Frankly, this dinosaur is making life hell for Company X’s employees and causing good people to make costly mistakes. You want to deliver a solution that gets rid of that pain and they will enjoy for years to come. (Hopefully not too many years.) It doesn’t take long to realize that there is a fundamental flaw in a business process that no amount of intuitive interface design will fix.

The great thing about this situation is that you’ve discovered the problem. In the user interviews, discussions about pain points and daily tasks have painted a vivid picture of the issue. Old school requirements gathering processes probably would have disregarded the information about the issue or simply recorded requirements needed to follow the currently flawed process. That’s one of the beautiful things I love about User Experience work. You get to dig deeper. The team can now start discussions to address the root issue.

Of course solving a business process problem is rarely in scope for most software rewrites. But the customer expects the project to make their lives easier. They have put faith, time and money into the project because they believe it will improve their situation. If you deliver a kick-ass application, that only solves part of the problem. The customer will be disappointed and perceive that you didn’t deliver or that the project didn’t accomplish all that their dollars were supposed to. You can meet your obligation, do your best work, and then not understand why the customer a year later contacts a different vendor to fix what you built.

It may mean increasing scope, or writing another SOW to cover the additional project of a new service design. Or, heaven forbid, you may have to take on that extra work and absorb the hit on this fixed bid project. But you have to do something in order to make your customer happy. Either that or you end up being the infamous third-party that technically delivered the requirements, took the money for the gig, but didn’t solve the problem they were hired to fix.

Make fixing that business process your problem. Because it is. You may not be the one to do the work of fixing it, but any UX professional worth their title should be able to guide a business to a new process that will work. And then, when you deliver that kick ass application, they truly will love you.  You will have provided critical value and brought a little more sunshine into the users’ lives. While you’re at it, capture some before and after metrics so that you can measure the awesomeness you have brought to their business.

Crush the Real Issues to Make Customers Happy

Your project goal is to update a business solution that is slow and laughably outdated. Frankly, this dinosaur is making life hell for Company X’s employees and causing good people to make costly mistakes. You want to deliver a solution that gets rid of that pain and they will enjoy for years to come. (Hopefully not too many years.) It doesn’t take long to realize that there is a fundamental flaw in a business process that no amount of intuitive interface design will fix.

The great thing about this situation is that you’ve discovered the problem. In the user interviews, discussions about pain points and daily tasks have painted a vivid picture of the issue. Old school requirements gathering processes probably would have disregarded the information about the issue or simply recorded requirements needed to follow the currently flawed process. That’s one of the beautiful things I love about User Experience work. You get to dig deeper. The team can now start discussions to address the root issue.

Of course solving a business process problem is rarely in scope for most software rewrites. But the customer expects the project to make their lives easier. They have put faith, time and money into the project because they believe it will improve their situation. If you deliver a kick-ass application, that only solves part of the problem. The customer will be disappointed and perceive that you didn’t deliver or that the project didn’t accomplish all that their dollars were supposed to. You can meet your obligation, do your best work, and then not understand why the customer a year later contacts a different vendor to fix what you built.

It may mean increasing scope, or writing another SOW to cover the additional project of a new service design. Or, heaven forbid, you may have to take on that extra work and absorb the hit on this fixed bid project. But you have to do something in order to make your customer happy. Either that or you end up being the infamous third-party that technically delivered the requirements, took the money for the gig, but didn’t solve the problem they were hired to fix.

Make fixing that business process your problem. Because it is. You may not be the one to do the work of fixing it, but any UX professional worth their title should be able to guide a business to a new process that will work. And then, when you deliver that kick ass application, they truly will love you. You will have provided critical value and brought a little more sunshine into the users’ lives. While you’re at it, capture some before and after metrics so that you can measure the awesomeness you have brought to their business.