The UX of Social Media

User experience (UX) design has its own process. Briefly, it’s about developing flows and wireframes, a spec, assets to be incorporated by Dev, usability testing, and feedback of test results to Dev. Lather, rinse, repeat. In an Agile scrum environment the spec becomes a story, and the process otherwise behaves typically. Everyone runs with their hair on fire until the last week of the sprint or release, when code freeze arrives.

It doesn’t do any good to provide usability input to Dev after they have put away their bits. And it is unlikely to find the features tested on the slate for the next sprint or even the next release – modern software programs are too large for that. So usability feedback that comes too late simply falls into the black hole of coulda, woulda, shoulda…

What the UX designer can do to accommodate the pace and code freezes of Agile takes in a number of things, including:

Test faster!
Approaching code freeze, work with the developers to get their last testable features as early as possible. Test with fewer users (two instead of five) and rely more on heuristics. Don’t spend so much time on the report itself, and stick to the major complaints.

Do the risky features early in the sprint.
Work with Dev on this so that toward the end of the sprint it is the small features being worked. If there is a delay due to feature creep or unforseen problems then only the small features will fall off the schedule. This also allows more leeway for UX testing and feedback of the first features completed.

Agree on acceptance principles.
Establish on the Wiki (you are doing Agile, remember?) a list of acceptance principles by which Dev can avoid repeating the same mistakes. Testing often turns up the same type of usability bugs in feature after feature. Get the scrum leaders and other stakeholders to agree that those principles are nominally part of any story that touches the UI.

Acceptance principles (not the same as acceptance criteria, as criteria require yes/no answers) are essentially best practices packaged to make sense to the particular team or project. For example, one might remind developers to match the OK/CANCEL button text in a confirm dialog to the descriptive text in the panel. Doesn’t make sense to ask a user to click YES or NO when buttons are labeled otherwise.

This forces the user to compare four concepts, Stop, Delete, OK, and Cancel to find the desired action.

Another good principle in this regard is to suggest that developers consult a technical writer for verbiage in dialogue boxes. Tech writers are very close to user experience designers in their thinking, and the writer will likely make other good suggestions as well.

The three previous paras align with the fact that a change costing $100 on a finished product costs about $1 in design. Please see ibmdesign’s post on ROI of usability.

Build in a post-freeze usability test cycle

In a perfect world, where user experience is a priority, the team will allow more time after code freeze for proper usability testing and feedback to take place. Yes with promotion and patience on the UX designer’s part, this can actually happen! When it does, stay cool. Act like such advanced thinking is totally normal.