From a PM/AM perspective, we are expected to keep the client happy (fulfill their objectives and vision), be the voice for our internal team and help produce a relevant and useful product while staying on time and in budget. Neglecting one and overdoing the others can cause issues with the overall success of the project, ultimately placing strain on the client relationship and internal morale. Catering to the client only can result in delivering a product solely focused on business objectives. This tends to overlook the user’s satisfaction, delays development and produces a less than successful product. It is our job to figure out what those objectives are and how they translate to the end-user. On the flip side, if we as the agency look out for our sole interests, rogue creativity may result in irrelevancy and dismiss the client’s primary business objectives. There is a balance, but how do we get there?
There was a similar discussion in the book, SCRUM: The Art of Doing Twice the Work in Half the Time, which sparked my interest on the topic. In software/web development, teams can be overwhelmed with a never-ending list of requirements that become irrelevant and outdated as the project develops, and they tend to serve more as roadblocks. Features become wasteful and not needed. These requirements are gathered at the beginning of the project and are thought to be essential to success. Things change, however, and we must be willing to be flexible.
To get to the overall purpose and desired outcome, we need to prioritize with our clients and internally: what is important, what is a must have, what is a nice to have, and what can get left out all together?
Look at the requirements through the lens of the Kano model, a method that has helped me wrangle in my own grandiose ideas.
Must-be Quality – Expected qualities of a deliverable. (The table stands up – woo hoo!)
One-dimensional Quality – User is satisfied when achieved, dissatisfied if not. (Table says it raises up and down. It does not – boo!)
Attractive Quality – Not expected or desired but a bonus. (Table was also made with recycled tires – cool) If it wasn’t, still cool table.
Indifferent Quality – Neither good nor bad, doesn’t really make much of a difference.
Reverse Quality – Too many features/options, not all customers are alike. (Table can also fold into a sofa, a ping-pong table, a sled and be used as a trampoline. I just want to put my computer on it!)
I’ll never forget a project that was delayed for one small feature that eventually was removed anyway. At the time for the client, they thought it was the make-or-break feature for the site. They had lost sight of their goals which cost them in the long run. (Of course, I tried to stop them, they just wouldn’t listen…LOL)
My Favorite Example of an Indifferent Quality
“Think about it: when was the last time you used Visual Basic Editor in Microsoft Word? …But it’s there, and someone spent time implementing it, but I guarantee you, it doesn’t increase the value of Word by much”
- Jeff Sutherland, Co-Creator of Scrum. Author of: SCRUM: The Art of Doing Twice the Work in Half the Time
Here are two projects with the same intention (success and increased usage), yet two very different results:
FAIL: Windows 8 Metro UI
Here is a unique example of having the user experience in mind, so they thought. The Metro worked very well across mobile, tablets and the Xbox interface. The move to PC caused confusion as they forgot to examine what the experience would be like for the user and focused more on the continuity of look/feel between devices. Hidden gestures, a clunky start screen and other usability issues put the desktop user last, not remembering that desktop browsing is still very relevant. It solved the problem for creating the same interface to multiple devices, which is more of a design conflict, not solving a real problem for the user.
YAY: McDonald’s App (Netherlands)
This UX team had great attention to detail on what the users wanted (locations with directions, relevant coupons, favorites, build a meal with nutritional values) while still meeting the business needs. The app had delivered on its KPI’s, impact on sales. 2.1% of all McDonald’s customers brought in a mobile coupon, and there was a 47% increase in spending through upsells using the coupons. On top of that, it was the #1 download in the app store and Google play, downloaded by more than 1 million Dutch consumers, according to UX Magazine.
This thinking can be used throughout the project cycle; there is not one definitive moment that it is more useful than another. Project is off track? Look at where you are in the development cycle. What can be removed? Does it still have the same effectiveness without it? Will it still remain relevant and useful to the user? As we all know, projects are evolving pieces of work and have elements of upkeep to them. Does the product still engage the user? Have the business metrics flat-lined? Are there new technologies/techniques that we have access to now that will make this better? Moral of the story: take a step back from the chaos and reflect on what it is that you are trying to accomplish and how you are trying to get there.
