The 5-D Design Method

When You take the Time to Bridge the Gap Between Business Goals and User Needs, then Your Product is not only a Winner, It's a Real Money Maker!!!

Sometimes the key objective is to "sell like hotcakes" but in the world of New Product Design and Development, one must first observe the Customer Experience Needs for greater Usability, Product Usefulness, Compelling Product, adding Value to their (customers) daily Lives, and Exceeding their expectations in terms of offering them something so great that they didn't really realize that they needed one until one day they picked one up and it was such a joy to use that it changes the way the think about doing something that they always took for granted before _ and now that they realize how much the old way sucked, well friends You cannot stop that train, because they NOW are moving on with the new way / provided by joyous product (iPad, Rocket Mortgage, Disney's Park Pass) and never looking back.

Let's take a look at the Design Sprint process, The Definition Phase, the Strawman and the Prototype - Let's take a look at the main activities, sub activities, methods and roles involved - Let's take a look at the dev team, make it more agile and more collaborative with business and design. Let's don't forget to bring our friends the Business Analysts and L&D / Instructional Designers (visual teachers into the process and independent development program authors).

Envision. Understand Objectives, perform Interviews, Analyze Issues, I like to do some working sessions / design workshops, build a strawman (try asking the DS design sprint team to build a model of the Golden Gate bridge with nothing but straws, popsicle sticks, dental floss & hot glue) and then see if that conceptual prototype is primed and ready to go onto usability walk-trus with real Users On Friday of Week One, and if not at least get the DS team to Agree Upon & and declare an end state vision that everyone can get behind.

Define Business Goals and Align / Bridge the Gap with User Requirements: Define User Groups, Develop Personas, ID Target Audiences, Define Content and User Tasks in the in the course of outlining typical daily user scenarios about the people interacting with the Product.

Draft One agenda for each meeting stating what will be covered + VM demos (as needed). 3 Main Requirement Areas: Business, User and System.

Identify Site / Product Content. Do some domain modeling, card sorting (don't forget the rainbow post-it notes and sharpie markers), A-B testing exercise to make sure you've got multiple angles and alternate perspectives covered.

Define / Refine Taxonomy, Navigation Model, Review with Client, make modifications. Product Management to provide all Prior Reqs, Usage Metrics, & Project Documents. Client to walk through existing sites with Sprint Design team.

Spreadsheet List Out Business Requirements and other functional and non-functional requirements. JAD Sessions, Working Session, Add'l JAD Sessions, UX, BA, Tech, Clients: Business Users. May involve further exploration of work processes; however, this is costly in terms of increased LOE and time.

Define User Journeys. This involves standing in front of the with board without any stick notes and waving Your arms like a champion. Speak softly and carry a big stick-y from a 3M flip-chart over to the wall and start over. Repeat this action several times until you have multiple phone screens, web pages or layers of the architecture stack defined.

Define user groups (target audiences), Create Wireframes, Refine the Concept. Daily. Deep drill down into "user by role on week 2-4 basis. If End Users unavailable, must have representative business team leads available weekly as user reps at a minimum. Persona Sub Process. Develop Tasks list, evolve that into or User Stories. If use cases are required, run through real lifer scenarios first and whiteboard User Journeys, you may find you no longer need traditional Use Cases (but you still need explore / build a valid business case, and) assign BA. the more detailed documentation of requirements traceability matrix and Use ? Business case depending (to enable dev budget / allocate resources, perhaps funding additional R&D if the first attempt revealed more fail / weak points than success) depending upon what the business funding committee requires and upon how great the volume of content this application offers.

Be done with that 'blue-print style conceptual prototype' and now that you've already learned a lot on paper by making lots of changes to your first trojan horse of a strawman (and hopefully refining it for the better if you not involved in a egregious exercise of "design by committee" then you

Usability Test. More than Once. With Different People, and in more than one location.

NOW READY to Build a Highly Polished - FULLY FUNCTIONING prototype whose purpose is NOT to go live intro production with a half-finished prototype but INSTEAD we use this camel jockey's 2nd strawman as a "mocked-up"application and Take the polished Prototype (pretending we actually have app already) on a Roadshow to Atlanta, Detroit, NOLA, Houston, Baltimore, Dallas, Austin, San Antonio, Phoenix, Indian Wells, San Diego, and Modesto in search of User Feedback.

Debunking the 5-Day Design to Market Strawman Candy MYTH

• Conduct Test
• Analyze Findings
• Turn Qualitative Metrics in +Quantitative Statistics and Web Analytics
• Present Findings
•  REWORK the Product  Start working on Generation TWO of the Product
• Create Optimized Images, Create Initial Build, UAT, Rework, UAT, Rework the Product
• for Template Driven designs (for reproducibility) and for Admin Console (for governance)
• Try A limited Release Test - Great for Honest Feedback
• Rework the Product
• User research in a Lab with Science
• Rework the Product.
• Provide Walk-me help or Contextual help for the Product.
• Package the Product.
• Developing Reporting Metrics as Flags / Triggers to measure success.
• Market the Product.
• Sell the Product.

Start working on Generation Three of the Product.