UX Took Velocity Down The Drain

/

UX iterations have been really slowing down the apps team so we broke out the no sacred cows, somebody should be yelling at least once, discussion framework for candid dialogue, and we went at it.

First we agreed on the situation; “We are having too many iterations of UX, each iteration involves the whole team, and together they are really slowing us down.”.

Then we talked about why, five times actually (Toyota Five Whys), to determine what is causing this and we came up with the following;

  • misunderstood or missed requirements
  • everyone reviews every iteration, very expensive
  • how we review and what is expected from the ux review is undefined
  • context switching between too many parallel projects
  • missing complex state situations
  • introducing and not identifying new patterns when we don’t have to bring them on in the first place
  • common CSS and referencing HTML is a mess
  • responsive issues when reviewing for mobile to tablet to desktop resolutions
  • adding use cases that aren’t identified and aren’t falsifiable

Took a while but we finally agreed on the list and we kept correction out of it. We made sure we all agreed as to what the situation is, then we talked about what caused the situation, and then we talked about how we will correct the causes, which included:

  • S...L...O...W DOWN, publishing a UX iteration is not a race, slow, steady, well thought out and thorough has much higher ROI
  • all UX must be accompanied with implementation notes from wireframe right through to release to developers, no more shared assumptions
  • before UX work begins prevalidate, recap, what will happen next, make sure we all have the same understanding
  • don’t involve everyone in the review, first peer review, and then move up the tier to finally the whole team
  • define and publish how the peer to tier review process works and what is expected of reviewers and how they should submit their feedback
  • we need to work out how we run ux and development so that we don’t context switch, right now they run in parallel with UX working ahead of Dev but the context switching for both sides isn’t productive
  • as soon as we see a situation that involves state transitions we need to throw a red flag in the air and realize this isn’t a normal UX situation, this is complicated, and we have to define how we map these out with state transition diagrams and other tools
  • best way to solve the impact of introducing new patterns is to stop doing it, PERIOD, and to make sure we don’t it, it is on peer review to catch it, and if and when we absolutely have to bring a new pattern online we need a process to vet and add it
  • it is time to break out the refactoring tools and tackle our HTML/CSS common code, big investment needed here
  • we need to define the expectations that we have for UX prototypes and their target resolutions, it is too loose and full of holes in how we do it now
  • and we all agreed that we just stop adding use cases for the sake of our personal opinions, if it wasn’t required and the proposed use case isn’t falsifiable, just censor yourself and get it off the frickin board fast

We took the above and created three separate cards to track the work to get the corrections implemented;

  • Refactor common styles
  • Define UX Processes
  • Define how to run UX and Development so that we don’t context switch

We gave the cards owners, and queued them for next up. This is how you nail tough situations. You don’t shy away from them. You call them for what they are and describe the situation as it is. Don’t add anything, don’t add cause, don’t move to solution. Just describe the problem that needs to be solved. Then, candidly work out what is causing it. Don’t let anyone go sideways, add other things in unless they prove to be the real problem, and don’t worry if people get upset. If they don’t, you are doing it wrong. Then define what corrects those causes and get the work queued to make it happen, pronto. Don’t delay.