Real Perspectives – UCD in Agile Development

The UCD Process in User experience management provides a very detailed and specific methodology to be followed to  get the best experience out. The steps in layman terms are as below

  1. User Research
  2. Data Analysis
  3. Brainstorming & Strategy
  4. Wireframe – Lo-Fidelity Prototype
  5. User Test – Validation 1
  6. Mockups – Hi-Fidelity Prototype
  7. User Test – Validation 2
  8. Visual Design and HTML

BUT,  this is not always the reality in the industry. Most likely your client/Product Owner/Project Manager would have asked for a top class visual design  “Inspired by” similar applications or websites. How do you deal with this? Well here are some workarounds/tips to overcome the typical UX hurdles and doing your job right

AGILE methodology – The UX Killer

The 2 week sprints of Agile process hit the UCD process hard as the latter is a long drawn systematic approach to design. Starting along with dev team for a sprint leaves absolutely no margin for error or iteration. Against all known convention you have to “Get it right in one go”

There are many strategies to match the speed of development with UCD cycles. One of that is UX team will work 2 sprints ahead of dev sprints giving them the much needed space to  work proper UCD process and also take up change requests in middle of the sprints

Another way to make it work in AGILE is UX team will work in release mode and dev working in sprint mode. I.e UX team will complete all deliverable for next 4 sprints which typically constitutes a release for the product. Post that a one UX designer will be made available with sprint team to work on any changes.

Lean UX is another interesting way to work, Basically you are combining User research, Brainstorming, Strategy and prototyping into one big co-development session with PO,Dev team and other stakeholders like Sales,marketing teams,CRM etc.

 

Product Owner – Mr. Know-It-All

Well! At one point or another the UX person would have contemplated killing the PO. PO’s usually are key persons in product strategy and positioning but unfortunately for UX team they also think themselves to be expert in UX matters.

So, how do you set the boundaries…Well you can’t! Not with one meeting or discussions anyways. It takes lot of time and patience to work with PO. Thinking them as kids with uncanny knowledge of domain helps. You need their insights on users but not their opinions on UX design. One of the ways to set the boundaries straight overwhelm the PO with sheer knowledge on usability studies and best practices, which means you will have to go prepared and determined like a lawyer defending a losing case.Other option is make whatever the PO says the UI should be and then put in the extra effort to do the UI that way you see fit. Present both the options to user in a A/B test or in absence of users present it to stakeholders of the product and let the best version win.

Developer – The UX eater

Don’t we all just love it when after months of slogging it out the dev team takes over the product and at end of release the product looks like Rusted Bucket of bolts instead of the Ferrari you designed and handed over to dev team!!

Post the UX deliverable to dev team the next sprint works start and UX team moves on but unfortunately the UX person is not over till the product is released. Why! because even after the walkthroughs, style guides and HTML’s the dev team priority is functionality first UI last. Can you really blame them? a little maybe or a whole lot more but whichever is the case ultimately you are responsible for user experience they are not. Establish the ground rules, the first and foremost rule no release without UX review and sign-off . Second just like the testing team all build will have to pass the UX smoke test before more time is committed for UX review. The smoke test criteria could be as simple as not more than 3 UI errors in a screen.

Well, that’s the 3 major hurdles you would face in a real world in delivering a great experience, the rest of the things like getting budget for UX process, taking to users, doing research, usability testing etc. have to driven through with tough stance and very importantly finding a UX champion(someone in C-management) in your organization. If your company is thinking UX then they are almost there it just takes your conviction on UX processes to see it through.

A parting note as a rule of thumb avoid any company like a plague who say “That’s all great but can we quickly put together something” 🙂