Building a simpler mousetrap

mousetrapThere is a saying that I’m going to incorrectly remember that goes something like: When you are putting together an outfit, take half of the things you planned on wearing off, then take another 2 things off. We watch a lot of project runway in my house.

With a site like sears.com you have such diverse product offerings, persona varieties, and fulfillment channels to account for there is no such thing as a simple solution. An elegant simple solution suddenly becomes a 5 step process once all the stakeholders have their input accounted for. Keeping things simple and focused is probably my first rule of successful UX. Number two involves bribing your coders with free drinks and being able to keep a secret but that will wait for another post.

When beginning a new design hopefully you have some data or user research to fuel the requirements of the project, the “What are we trying to solve?” While things are fresh and just starting to take shape we may not have a lot of data related to the new designs and it’s often helpful to establish a simple mission statement of guideline. Maybe the goal is to push more users to our brick and mortar locations to pick up their orders, so that becomes the litmus by which all decisions are judged. Each new feature or asset being added to the design needs to pass this sniff test. Does it help our goal succeed? No? then leave it out! Even if its not not directly opposed to the goal its mere existence could detract from the primary goal and therefore hurt the conversion. This is a pretty scorched earth example, things are rarely as single minded in our business but less is more when it comes to persuasion.

Things can get a bit trickier if you are updating an existing feature or product. When Microsoft announced the new update to their Xbox video game line they were met with disastrous reactions. In their efforts to add new features to their machine they appeared to have lost focus on what was currently working. In the efforts to turn their video game console into more of an entertainment console they removed functions that their gaming base wanted. The reactions were so negative that they actually walked back some of the new features and have patched in old features after release. Many analysts attribute this poor reception to feature removal for the widening gap between Microsoft and Sony’s new gaming platform sales.

So now we are posed with the problem… How do we balance editing and removing old functions users want? Hopefully your editorial decisions are driven by data that shows what is and isn’t being utilized. While it can’t always tell the whole story its probably the safest way to hedge your bets. So what do we do when we don’t have the data? Maybe its not something easily attached to a metric or more likely, we didn’t set up the metrics properly in the rush to launch. This is where we need to fall back on our project’s guiding principals. Hopefully we know our product and our users well enough to understand their needs and have incorporated that into the goal. In the Microsoft example they clearly understood that their new direction could be veering away from their base but that was by design. They wanted to change the old in order to expand their demo. These are calculated risks and it makes having a solid understanding of your project goals that much more important as you iterate feature sets. “Keep it simple, make it new, just don’t change anything I like”  seems easy enough right?

Tags:

One Response to “Building a simpler mousetrap”

  1. Karol Czyrka →
    March 13, 2014 at 9:05 am #

    One approach I have always advocated is the incremental change. In a world where we can deploy changes so fast in code, I never understood why we can’t get this to work. We all seem to suffer from ADD and move from one project to the next with no continuity, no continual improvement. A project gets shipped, we know it is lacking 20% of what we wanted, but that 20% seems to fall on the floor and be swept away instead of getting into the next release.