Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Product Anonymous - Rogue UX - Feb 2017

From our February 2017 session, Duncan Macneil talks about high fidelity & Rogue UX.

  • Login to see the comments

  • Be the first to like this

Product Anonymous - Rogue UX - Feb 2017

  1. 1. Adventures with Rogue UX Duncan Macneil
  2. 2. What is rogue-ux? A method for getting closer customer alignment using ABSOLUTE FIDELITY WORKING MODELS That is all.
  3. 3. Why absolute fidelity? Because the UI and the Functions together form the entire app! UI + API = APP
  4. 4. Hi-fi / Absolute. Are we nit-picking? No. There are real differences between rogue and traditional
  5. 5. Requirements are vague, systems are specific. Don’t let anyone think we can defer making decisions. Every correction made during development is costly. Where traditional says “We have a few concepts… (now relax!)” Rogue-UX says “There is only one working model… (now fight!)”
  6. 6. For every “A” & “B”, there are an infinite number of “C”s. A/B tests should be for final evidence. Where traditional MIGHT say “We’ll A/B test, and let the customer decide” Rogue-UX says “A/B tests are for proof, not decisions”
  7. 7. What you see in the working model will be in the real system, unless you specify otherwise. Today. Where traditional says “It’s just a mockup” Rogue-UX says “This is real”
  8. 8. Is it important? (Hint: YES) 1. Companies with poor feature analysis will have three times as many project failures as successes. 2. 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of the group's projects were "runaways" which had any 2 of: taking over 180% of target time to deliver; consuming in excess of 160% of estimated budget; or delivering under 70% of the target required functionality. 3. Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects. 4. Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization. The Impact of Business Requirements on the Success of Technology Projects, IAG 2008
  9. 9. HTML5/Bootstrap JavaScript/jQuery H1, H2, H3, H4, H5, H6 P, B, SPAN COL-[XS-SM-MED-LG]-[3,4,6,12] ROW MODAL SECTION HEADER FOOTER thing.slideUp() …. slideDown() … .hide() thing.addClass() … removeClass() thing.attr() …. thing.html() .each() .ajax() body.on(‘click’,...)
  10. 10. 3 new things I learned 1 Lo Fi is still required Don’t skip the sketchy, loose ideation phase. Balsamiq is a great option here. 2 The tools are the rules Since there is only the browser (not any ‘player’), all forms of interaction are fair game. That makes for great customer testing. 3 Narrow in on perfection There is a natural ‘core screen’ on every app, but don’t go deep on one aspect. Rather, model the whole process broadly, then refine. Don’t even try to document until at least round 3, 4 or the final showcase. Things change.
  11. 11. Discussion time Let’s talk specifics! How is it done? What tools help? Look at some demos.
  12. 12. Thanks http://