The Dual-Track Agile UX Process at Dell EMC
•Transferir como PPTX, PDF•
18 gostaram•1,831 visualizações
You'll learn: - How to design ahead of development without chaos - How to conduct user research within Agile - How to deliver consistent UX on tight timelines
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a The Dual-Track Agile UX Process at Dell EMC
Semelhante a The Dual-Track Agile UX Process at Dell EMC (20)
Mais de uxpin
Mais de uxpin (20)
Último
Último (20)
The Dual-Track Agile UX Process at Dell EMC
- 1. Dual Track Agile for Enterprise Creative Teams The long night of disruption and impossible deadlines.
- 2. © Copyright 2017 Dell Inc.2 Ian Armstrong Senior UX Designer Dell EMC Dell Digital Studio
- 3. © Copyright 2017 Dell Inc.3 Let’s get aligned UI is an ArtifactDesign is a System So what is Agile?UX is a Process
- 4. © Copyright 2017 Dell Inc.4
- 5. © Copyright 2017 Dell Inc.5
- 6. © Copyright 2017 Dell Inc.6 So let’s talk about Agile 2 weeks 24 hours Product Backlog Prioritized by business value Sprint Backlog Estimated, Ready Sprint Iterative Loop Build, Test, Modify
- 7. The Promise The Reality Image Credit: Google Ventures
- 8. The Promise Teams receive a prioritized backlog of user stories that break the production process into manageable chunks. The chunks are estimated and producing them exposes team velocity. Accurate completion dates an be inferred. The burndown chart closes in on zero as the team works through a known backlog. Design teams have long and frustrating Sprint planning meetings because backlog items are poorly defined. They have slow velocity as well as poor design because details are still being worked out during the Sprint. The amount of waste and rework is very high because backlog items have not been validated. The Reality
- 9. Gestalt: a structure, arrangement, or pattern of physical, biological, or psychological phenomena so integrated as to constitute a functional unit with properties not derivable by summation of its parts.
- 10. Stakeholder: A stakeholder is anyone who can derail the train.
- 11. #designerproblems The struggle is real
- 12. © Copyright 2017 Dell Inc.12 Pure UX is Waterfall Know the User Thrives on Preparation Execute the Design Know the Business
- 13. © Copyright 2017 Dell Inc.13 Oh look, it’s a cone of uncertainty
- 14. © Copyright 2017 Dell Inc.14 So yes there are two tracks to agile in a creative unit
- 15. © Copyright 2017 Dell Inc.15 The Delivery Track There are two Agile tracks Aligning Delivery With Human Centered Design The Ideation Track
- 16. Dual Track Agile The Purist’s Approach
- 17. © Copyright 2017 Dell Inc.17 The Lenses of Human Centered Design Design and Development work together with stakeholders to ensure that solutions meet three criteria: 1. Desirable Users find the design both useful and more effective than their current options. 2. Viable The company is able to sustain the demands of the design in terms of resource output and ongoing financial commitments. 3. Feasible The solution is designed in a way that is technically possible given the resource and time constraints involved. DESIRABILITY VIABILITYFEASIBILITY BUSINESS OBJECTIVES VALUE PROPOSITIONS
- 18. The Discovery Track The Discovery track is all about quickly generating validated product backlog items. Research sprints focus on discovering a set of user needs and articulating them as problem statements. Design sprints focus on creating a working prototype from research sprint insights. The Delivery track is all about generating releasable prototypes. Interaction designers, visual designers, copywriters, and UX Engineers refine prototypes into production-ready assets. User testing focuses on optimizing designs rather than validating backlog disruptive ideas. The Delivery Track
- 19. The Research Sprint (4 days) Interpret and test initial stakeholder requirements using a “quick win” prototype Discover what we don’t yet know about the user’s needs and process Validate a high concept and unpack it for focused creative work Move the project from actionable insight to a working prototype through rapid ideation Practice team ideation and deep discussion of ideas during the sketch & decide days Build and test a clickable prototype as a proof-of concept for delivery The Design Sprint (5 days)
- 20. The Research Sprint Articulate the problem and ensure the desirability and utility of the opportunity statement.
- 21. © Copyright 2017 Dell Inc.21 The Research Sprint • A sprint model pioneered by Google Ventures • Business needs are expressed by the product owner as a high level product proposal but there are many unknowns. • The research sprint answers a lot of important questions about the proposed idea: – Is there a market for this product? – Will the product help people solve their problems? – What should we build? – Do people understand this product? – Will people find the product useful? – Is the product we are building usable?
- 22. © Copyright 2017 Dell Inc.22 Research Sprint: The Components 1. A set of questions and assumptions 2. Intentional and selective recruiting 3. A realistic prototype you can test. † 4. Five one-on-one interviews combining broad discovery questions with task-based evaluation of a prototype or current product 5. Real-time summarization of findings † This is based purely on the stakeholder problem statements / proposals and does not have to be the result of a design sprint.
- 23. © Copyright 2017 Dell Inc.23 Research Sprint: The Four Day Plan • Day One: Start recruiting participants Designers should begin working on a quick-win prototype based purely on stakeholder requirements. • Day Two: Schedule participants and draft the interview guide • Day Three: Finalize the schedule and complete the interview guide The quick-win prototype should be nearly complete. This is a good time for the researchers and designers to review one another’s work. • Day Four: Test participants and summarize findings
- 24. The Design Sprint Unpack the problem statement and approach the solution from multiple angles
- 25. © Copyright 2017 Dell Inc.25 The Design Sprint: • A sprint model pioneered by Google Ventures • The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. • Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week. • Instead of waiting to launch a minimal product to understand if an idea is any good, you’ll get clear data from a realistic prototype.
- 26. © Copyright 2017 Dell Inc.26 Design Sprint: The Components • Unpack What do we know? • Sketch How would you solve it? • Decide Okay so what are the best ideas? • Prototype Turn it into a clickable interface • Test Dear users… did we nail it?
- 27. © Copyright 2017 Dell Inc.27 As usual, Enterprise breaks everything good in the world
- 28. © Copyright 2017 Dell Inc.28 In enterprise installing a new process isn’t so much about turning the ship, it’s about turning the iceberg.
- 29. © Copyright 2017 Dell Inc.29 1. Stakeholders are busy people 2. Decision makers want a top-line summary, not details 3. Designers find it frustrating to have to do their ideation with stakeholders in the room 4. Businesses are execution focused. 5. Agile purists will tell you the design sprint is waterfall masquerading as agile 6. They’re intensely exhausting. 7. They don’t understand the deliverable 8. They like to tell you what is impossible 9. Modern enterprises are super virtualized. 10. Lack of consistent user information
- 30. © Copyright 2017 Dell Inc.30 How to make dual-track enterprise agile work • Evangelize goal-directed design • Know the lenses of Human Centered Design • Learn how to write, work with, and love KPIs • Establish a consistent project intake with a UX Brief • Constantly communicate the value, especially after a conflict DESIRABILITY VIABILITYFEASIBILITY BUSINESS OBJECTIVES VALUE PROPOSITIONS
- 31. The UX Brief
- 32. © Copyright 2017 Dell Inc.32 The UX Brief 1. Describe the business opportunity 2. What business objectives capitalize on the opportunity? 3. How can we measure the objectives as conversions? 4. What are our primary user types and what do we know about their behaviors? 5. Where and how is the user interacting with our product? 6. What budget, time, or platform constraints exist? 7. Is there any specific creative direction that needs to be followed outside of the standard branding guidelines?
- 33. Oh, did I mention nobody has time for this s**t?
- 34. © Copyright 2017 Dell Inc.34 Unpacking the Data when there is too much of some and not enough of the rest.
- 35. © Copyright 2017 Dell Inc.35 Sketch Day When most of you can’t be in the same room.
- 36. © Copyright 2017 Dell Inc.36 Discuss Day The stakeholders all get to be cops again, but now they’re your friends. DESIRABILITY VIABILITYFEASIBILITY BUSINESS OBJECTIVES VALUE PROPOSITIONS
- 37. © Copyright 2017 Dell Inc.37 Prototyping Day When most of you can’t be in the same room.
- 38. © Copyright 2017 Dell Inc.38 Test Day All you really need to do here is think ahead and have a budget
- 39. So here’s what is going to happen your first time
- 40. Q&A Session
Notas do Editor
- Hello my name is Ian Armstrong and I’m a Senior UX designer at Dell EMC where I lead a high-performing UX team’s interaction design and define a large part of our agile creative process for multiple teams at the Dell Digital Studio. Since completing the largest tech merger in history my team, under Nicolas Rodet, has been working to transform our corner of the Enterprise into a design thinking agency; capable of breaking the sort of entrenched paradigms that often ensnare large enterprises and delivering progressively more value to the end user. When you’ve been doing things the old way for a couple of decades that can be a really scary process. Throw in the already tricky problem of aligning a sales-driven company with an engineering-heavy culture, a global audience, and a bunch of creatives who don’t consume agile or project management processes the same way as anyone else -- and there are days when crying in a corner and mumbling about velocity vs cadence seems preferable to taking your next set of calls. Alas, we persist, but the struggle is real
- So today the thing I want to talk to you about is how to make your creative process, your delivery process, and your engineering process all work together without devolving it into a paint by numbers exercise that makes everybody on your team wish they worked at Facebook or Google. We want to create value, not requirements. That probably should have been part of the agile manifesto. As you know from the title of my webinar we’re going to talk about a dual track agile process – and I’m definitely going to focus on the ideation side of things - but the topic is more complex than “design for the backlog, deliver for the devs.” I think it’s useful to start with a quick review of design, user experience design, and the ideas at the core of a functional agile process.
- Design is the rendering of intent In 1997, when I first took an interest in marketing and advertising, I asked the head of the Academy of Art’s advertising department why I should study in his program instead of learning computer graphics or photography or music production or some other discipline that didn’t involve the occasional suit & tie mentality. He said something that stuck with me. In most forms of art, the viewer’s interpretation is what matters. I mean let’s be real here: Jackson Pollock and Pablo Picasso probably wouldn’t give two craps what you think their art means. It wasn’t meant for you but they’re pleased you like it. Care to commission one? In design, however, the intended message is what matters. By studying advertising, I was pledging myself to a creative field where more than 80% of the viewers of my work would need to interpret it’s meaning with a high degree of fidelity to exactly what we came up with on the creative brief. On message, on target, measurable, predictable, and repeatable – but somehow not completely boring.
- I later learned that the most powerful form of advertising doesn’t complete the circle of logic for the viewer. Instead it gives them all the information required to come to the correct conclusion, which makes the advertising message THEIR IDEA. Having come up with the conclusion themselves the idea then has real power. Many of you will recognize this as the basis of a compelling user experience as well and that isn’t a coincidence. We don’t tell our visitors who they are but, rather, we enable them to be more like themselves and we try our best to make that a powerful feeling. The graphics, the code, and the copy are all artifacts. Deliverables. They are the end result of many MANY many hours of hard work, blood, sweat, tears, pizza, and the occasional tequila. The process that gets us from actionable insight to a value proposition though? That’s UX and UX needs to fit within the agile framework preferred by most of the companies we work for today.
- At the heart of agile is the iterative loop. Build, test, refine. The team mascot for agile, however, is scrum and scrum has a lot of rules. You need a well groomed product backlog, which requires you to have a decent idea of what you are building even if you don’t have all of the details yet. I mean it’s called the one of uncertainty not the cone of “I have no idea what and I can’t even” – and if we’re being honest that’s where a lot of green field design starts from. Also we’ll get to that. You need a properly estimated sprint backlog and at the end of two weeks you need to produce a theoretically shippable increment. Those rules don’t always work well for creative teams because in a lot of cases they were written in a way that supports engineers. Let’s unpack that with the help of Google. Google Ventures illustrates the problem with a pair of graphics on the promise vs the reality of agile in a design unit.
- One of the most common complaints from designers, when they are asked to write and estimate user stories, is that if they could write a user story they would have already designed the interface. For example a user story may say something like: “As an IT Manager I need to be able to log in and view my past network designs” To a developer this makes sense. To a designer it raises questions: Do we need to log in every time we visit the website? How can I minimize the number of interactions required to get to relevant data if I’m forcing a login where it isn’t axiomatic to a feature’s functionality? Should we even subject regular visitors to a login? When do we ask for it? Can I accelerate it? How do we handle the registration loop? What do we do if a user forgets their password?
- A working UI isn’t just the sum of its parts, it’s a gestalt. In other words, we aren’t just building Frankenstein’s monster here, we are building an ecosystem. The whole thing needs to hang together as part of a holistic end to end experience. If all we do is bolt a bunch of features onto the page in isolation, we don’t even need to test that result – we already know it’s going to be terrible. So what looked like a small story is suddenly a full blown whiteboarding session with the UX Deigner, engineer, product owner, and visual designer. It may take a few days just to get all those people together then a couple of weeks to test and build it. So to recap: “As an IT Manager I need to be able to log in and view my past network designs” Innocent story not so innocent after all.
- And then you remember that a stakeholder is anyone who can derail the train… and there are many many stakeholders. So again - waste and rework are the bane of the design cycle.
- Not an alternate fact
- So there’s something we need to talk about, or at least acknowledge. UX in its purest form is inherently waterfall [CLICK] It thrives on preparation We want to know everything we can about the user We want to know all the details of the business model [CLICK] Only then do we have any hope of designing something that is ideal for both [CLICK] There are several books on this. Unfortunately for UX, modern design is agile and we need to make UX delivery an agile process. Unless you literally just crawled out from under the rock where you’ve been living since 1992 this isn’t new information. I’m betting at least half of you have read Jeff Gothelf’s “Lean UX” and although that isn’t the main topic of today’s webinar it is definitely related because dual-track agile can suffer from a lot of the same problems if you aren't careful. It’s a great place to start though, if you haven’t left the old rock house since Nirvana still smelled like teen spirit. Today though - - we’re here to address the next problem in line after lean UX.
- In agile we live comfortably. Okay fine. We say we live comfortably within the cone of uncertainty. The thing about the cone of uncertainty is that while all of the details aren’t yet known the general direction is pretty clear. [CLICK] Captain obvious is sponsoring this slide and asked me to remind everyone of the takeaway: you can’t design a system if you don’t know why you’re designing, what the business goals are, who the users are, or how you intend to measure them. [CLICK] So the question before us today is this: How do we establish a (generally) valid design direction with enough clarity to fill a backlog? We don’t need to know exactly how the story ends but we need to know where North is or our iteration will be more like a Jackson Pollack painting than a marketing message [CLICK] And good luck measuring that for anything but a frame. Also yes, my bachelors degree is from an art school. Thank you for noticing.
- We know about the delivery track. Generally speaking, it looks like Scrum. We could talk about the delivery track and whether to work in sprints or a continuous flow system like Kanban but the thing is we already know a whole lot about those choices. The delivery track is the meat & potatoes of agile and it’s where we spend most of our time. It’s not where the best ideas come from though.
- Yoda is right. There is another track that design teams use in their quest for the almighty minimum viable product. It’s created several household names. It goes by a lot of names as well. I like to call it the discovery track and we really owe thanks to Google Ventures for defining it. At Google the ideation track comes in two flavors: the research sprint and the design sprint.
- A lot of you have read Sprint and I bet at least a quarter of you have tried to run a design sprint. For the other unspecified percent of you, let’s quickly review a purist’s approach to dual track agile.
- But how do we get from a bunch of value propositions to an MVP?
- There are two types of discovery sprints. We use the research sprint when we are short on user data We use a design sprint when we are ready to unpack the problem Spoiler warning: The design sprint as much more work
- When you aren’t sure what you need to build and the goal is to surface user needs around a business objective, you do a research sprint
- When you have a solid set of business objectives, behavioral personas, and user needs available that’s when you run a design sprint Design sprints are the bread & butter that power Google Ventures, one of the largest tech incubators ever created They’re pretty flipping cool We’ll handle the enterprise caveats later
- If you’ve ever used Slack, Firefox, or Prudential insurance you’ve seen the result of a design sprint. It’s not crazy. The U.S. Department of Defense literally used a design sprint to assess the value of life saving technology. You’d best believe they had some big hats up in that room. Every team names these days differently. I like these labels, you may like others. It’s the theme of the day that matters. Unpack The ideal team will include representatives from all relevant functions and at all levels within the organization such as sponsors, senior managers, marketers, designers, developers, customer service, sales, user support, etc. Sketch Sketch day is an individual effort. Everyone (even high level managers and engineers) is tasked with coming up with a detailed solution to the problem. Decide Review everyone’s sketches and work out how various ideas may conflict with your objectives, abilities, resources, etc. The last part of Decide Day is to create some storyboards for your most workable ideas. Prototype This is where the work gets serious. You have a single day to create a prototype that your users can test on the final day. Researchers should be working on the test plan Test Find out if you actually solved the problem. Yes, we will go over these again.
- At Dell Digital the main problem I ran into with design sprints is that they were really designed for startups or small teams. At a startup working on its first product it’s not nearly as difficult to get a bunch of decision makers in the room for five days and gun out a new MVP. They bleed your product and they’re focused. Anyone who has ever tried to explain to an SVP at a multi-billion-dollar corporation that you’ll need five days of his or her undivided attention for the 37th project on their list of critical initiatives the current fiscal quarter knows that the pure form of this thing is not happening. Not even close. The struggle is real. There’s a saying that UX designers and agile coaches use but it loses basically everyone else. I realize that makes for a terrible joke but it’s still useful in context.
- The Titanic isn’t going to turn in time. You’re on the foredeck screaming BERG! The engines are grinding backwards, the screws are churning up backwash, and basically everybody is about to be dead. As the saying goes, ships don’t turn fast enough to save themselves from icebergs and neither do enterprises. What we need is a way to redefine the iceberg in a way that the ship is capable of understanding.
- Here are a few of the objectives I’ve faced to running design sprints: - Stakeholders are busy people - Decision makers want a top-line summary, not details, and certainly don’t want dirty hands about 95% of the time - Designers find it frustrating to have to do their ideation with stakeholders in the room, who tend to be grounded in their perception of reality. You don’t get blue sky by reading from a book of best practices. - Businesses are execution focused and tend to have a “get it done yesterday” process model. That attitude, by the way, keeps your scrum master in a job defending you from the tender mercies of a stakeholder whim. It’s not changing. - Agile purists will tell you the design sprint is waterfall masquerading as agile (it’s not – it’s about aiming the cone of uncertainty – design sprints give us the blessing of direction, not the mandate of a final decision). - They’re intensely exhausting. Oh, they’re totally worth it and they save a ton of time but it puts the lactic acid back in the term “sprint” for sure - They don’t understand what the deliverable at the end of the week is supposed to be. - They like to tell you what is impossible way before getting to the discuss & decide segment - Modern enterprises are super virtualized. My last sprint included two people in the U.K., one on the East Coast, two of us at the San Francisco office on Market Street, a graphic designer in Idaho, and I can’t even tell you where the other stakeholders were calling in from. - And most importantly there is often a profound lack of consistent user profile information across product teams or, heaven help you, entire subsidiary companies. Design sprints are hard. They are new and can be uncomfortable. They’re also the coolest thing since pockets (and I totally stole that line from my director Tom Willey) if you need to do something like say… deliver the entire Dell EMC world virtual experience application in under 8 weeks and are expected by your new CEO to break online attendance records. Yeah, that’s a real thing. Without a design sprint it might well be what we call a resume-generating event. I’m guessing you’d like some tips on how we did it?
- There are five components I want to talk about. Some are soft skills and others require hard measurements. In my experience at Dell Digital all of them are important. I’ll go through them one at a time but here’s the list. Goal Directed Design is an interaction design methodology created by Cooper that identifies the goals and behaviors of users, and the goals of a business, and directly translates these into design. Cooper also invented personas, which are kind of a big deal, even if Cooperian personas are a little fluffy compared to what came later. [CLICK] Human-centered design is a creative approach to problem solving and the backbone of IDEO’s design philosophy. It's a process that starts with the people you're designing for and ends with new solutions that are tailor made to suit their needs. We went over the lenses of HCD earlier in this presentation. [CLICK] KPIs are what make a design measurable. They should be based on real data, not guesswork. If you have analytics then use them. It’s also good to consider that in most cases raw number signal adoption but percentages signal a change in usability. For example it’s more useful to know that a user who adds 7 friends on a social network is likely to be retained than it is to know you added 15,000 new members in your first month. KPI measurements should be crafted to match the business goals and incremented in a way that allows for optimization vs vanity metrics. The UX brief is borrowed directly from my agency experience early in my career, and during my bachelors program at the Academy of Art. A UX brief lays out all of the information a creative team needs in order to begin an ideation, or a design sprint, in the most succinct way possible. I’ll show you mine in just a moment. And finally remember that conflicts between designers, stakeholders, and engineers are teaching points in the context of a design sprint. Just to give a quick example – a stakeholder might misunderstand the intent of a feature, or a designer might feel limited by the stakeholder’s vision. As the two groups resolve their conflict it’s good to recognize that the conflict was likely going to happen anyhow. The difference is that in a delivery sprint it may have taken a week and a half to resolve instead of 20 minutes. Finally – and this may be the most important point of all – let your people know what they are in for. While we try to limit the meeting hours required your primary team members are still in for at least 8 hours of meeting over 5 days. Make sure they are prepared for that reality and do your best to communicate how important their contribution to the success of an MVP is.
- Describe the business opportunity Give a high-level overview of the business opportunity. This could also be a problem statement. Reference any supporting research. What business objectives capitalize on the opportunity? There should be several objectives related to the business opportunity. These should be actionable, measurable goals. How can we measure the objectives as conversions? A conversion is the final action we want a user to take at the end of a funnel. It can be a product purchase, initiating a live chat, clicking an email link, downloading a document, sharing a product data sheet, etc. What are our primary user types and what do we know about their behaviors? Briefly describe the main behavioral personas here. Attach any detailed profile information to the document as separate pages. Where and how is the user interacting with our product? Identify the primary touchpoints and environments in which we expect the user to interact with the product. While mobile devices make “everywhere and on anything” a tempting answer, it helps to define our primary use cases. What budget, time, or platform constraints exist? Include any legacy systems that must be supported, hard deadlines, or platform restrictions related to device types, software versions, etc. Is there any specific creative direction that needs to be followed outside of the standard branding guidelines? Add any information that may be useful to creatives. This can include branding information, tone of voice details, or feature requests from users that should be given consideration.
- Back here on planet Enterprise I can’t just ask a director to spend the next 40 hours of their life in a conference room. If your company isn’t literally swimming in cash, you probably can’t even get half of your people in the same city. At Dell we have had to make a few concessions to the gods of industry.
- The unpack will take about 2.5 hours. Note: not 8 hours. It’s the first day so people will get off topic. You’re going to want to talk about the user and stakeholders will keep on naming feature requests or business goals. Be patient with them, they are smart people who learn fast if you let them. I like to start on a Wednesday because it lets prototyping wrap the whole weekend, plus a Monday. Your UI designers will thank you. You aren’t going to know enough the first few times but using a UX brief will definitely help.
- Sketch day is going to be a pretty individual effort. Book a 1-hour meeting around mid-morning to check in with everyone and hear some of their ideas. Refer back to your user personas and business goals in the UX brief. Try to add some love to the forgotten ones. Also stay available on Slack and, as a facilitator, be ready to have additional impromptu sessions on request. Remind everyone that there are no bad ideas – this is your chance to get crazy and blue sky. It’s actually really fun to see how far out of the box your most conservative team members get once they have permission.
- Which, let’s be honest, feels weird. Good weird, but weird. Discuss day is the grind. We straight up booked 4 hours in a telepresence conference room for my last design sprint and we used two more in a standard Webex call before we split. Put an image of the lenses of HCD on the screen and remind people of how they are going to use them. Every idea should be run by the appropriate stakeholders for viability, then the engineers for feasibility. The UX person in the room, which is probably you given the nature of this Webinar audience, will focus on desirability. You’ll come out of discuss day knowing what you want to build though and later on you’ll realize how much more awesome your stakeholder relationships become. One of the tangible benefits of a design sprint is a near total alignment between stakeholders, engineers, and the design team.
- Prototyping day is when everyone but the design team gets a day off. As I pointed out earlier I actually like to set this up so it hits on a Monday and that way the design team has a weekend to let all of the ideas sink in Plus they can boost a few hours on Saturday or Sunday if they feel like it’s going to be too much work in a single shot. Remember that the prototype doesn’t have to be high fidelity – just clickable. How clickable depends on whether you intend to do guided or unguided objective testing. We use both InVision and UXPin, depending on our ability to lean on pre-authored object libraries vs a totally new interface.
- Testing day should be the one that is easier in enterprise because you have dedicated resources. Really, you don’t have a valid excuse to blow testing. Budget is like… our one mega-advantage. Line this one up before you unpack. Know who you are going to test with so you aren’t stuck wondering what the heck to do about it on Tuesday morning. A bit of preparation makes this easy. Having real user feedback will help guide the iterative process of the early delivery sprints. Presenting the final result won’t take long – you’ll probably only need 30-45 minutes because nobody in the room is going to be surprised by the work. It ends up spawning a huge agile planning meeting later since you can really flesh out the backlog now but that was really the whole point.
- Spoiler: it won’t be pretty - The high level overview will happen fast. - You will probably have too many supporting goals. - You will probably have a terrifying lack of user data. - Stakeholders won’t understand why the user is so important until you try to storyboard a few of the user journey points. - At that point you’ll probably pause the unpack and commission user research, which may completely blow up your first attempt at a sprint. Reschedule and keep going. Now that you know this it probably won’t happen. You’ll have to tell me what the next iteration of “oops” looks like on the Product Tribes slack. Let’s get to your questions and comments.