Nielsen Norman Group defines<\/a> User Experience (UX) Design as \u201cencompassing all aspects of the end-user\u2019s interaction with the company, its services, and its products.\u201d<\/p>\n Usability.gov defines<\/a> it as \u201cfocusing on having a deep understanding of users, what they need, what they value, their abilities, and also their limitations.\u201d<\/p>\n User Experience Design<\/a> places a value on business goals and objectives of the group managing the project in addition to user requirements. Designers\u2019 overall goal should be focused on increasing user satisfaction through engaging interactions with their product, functionally and aesthetically.<\/p>\n Peter Morville at Semantic Studios defines<\/a> the various pillars of user experience design as:<\/p>\n User Experience Design is actually comprised of various specialties executed together including:<\/p>\n Understanding the people who will use a product is a key first step in trying to create empathy and influence what the initial problem statement will be. A technique known as Ethnographic Research allows designers to get a clear picture of the user\u2019s problems and processes.<\/p>\n Claude L\u00e9vi-Strauss in his 1963 book Structural Anthropology<\/a> said that, \u201cEthnography consists of the observation and analysis of human groups considered as individual entities (the groups are often selected, for practical and theoretical reasons unrelated to the nature of the research involved, from those societies that differ most from our own). Ethnography thus aims at recording as accurately as possible the perspective modes of life of various groups.\u201d<\/p>\n The groups L\u00e9vi-Strauss mentions are known today as personas. Personas allow for the generic concatenation of user data from both a qualitative and quantitative perspective. To many project managers this observational method may appear inefficient but it\u2019s a very important exercise that informs designers about the context in which customers would use a new product and the meaning the product should hold in their lives or jobs.<\/p>\n A user interview, where a designer sits down with a user to discuss their problems and processes, is known as an Ethnographic study.<\/p>\n Study findings provide an understanding of user behaviors, needs, and motivations using observation techniques, task analysis, and other feedback methodologies. Depending on the situation and required information various research techniques are available including surveys, A\/B testing, focus groups, and more.<\/p>\n Nielsen-Norman Group defines<\/a> Ethnographic studies as \u201cthe best way to learn about your customers\u2019 goals and needs. Visiting people in their own environment can help you learn very different kinds of information from that collected in usability labs or other methods. They are commonly known as \u201cfield studies\u201d and \u201ccontextual inquiries\u201d.<\/p>\n There are 4 research keystones that inform long-term product strategy:<\/p>\n Nielsen Norman Group points out<\/a> that despite the unique insights gained from field studies, few organizations take advantage of this technique \u2014 usually due to some combination of the following:<\/p>\n One specific challenge faced within organizations is that user research is not entirely a quantitative process. You don\u2019t get lots of neat numbers, graphs and figures at the end. User research is very much a predominantly qualitative process. It produces lots of unstructured data that can be hard to summarize. It\u2019s also difficult to prevent bias from creeping into the research process. Bias can cause our own understanding of something to introduce a lack of objectivity. To help prevent bias delve into the user much like a character actor does. Your goal should be to understand them and their contribution to your research. It\u2019s never a good idea to assume that all interviewees view problems they face similarly.<\/p>\n User research begins by developing a relationship with the interviewee. Developing a level of rapport helps show you possess empathy and understanding with that person. When they feel comfortable with you they tend to be more honest when participating in the process.<\/p>\n Take the time to introduce yourself prior to starting. Explain what\u2019s going to happen and invite questions from the start. Make sure you are engaged in the conversation throughout and thank them for taking the time when finished.<\/p>\n If the interviewee states they took an action or made a judgment call but do not explain their motivation, this is an opportunity to ask \u201cwhy\u201d to explore if you can find a root cause to truly address their problems within their existing processes.<\/p>\n Each time you ask \u201cwhy\u201d you get someone to re-evaluate their position and dig a little deeper into their own reasoning. It can seem odd to keep asking \u201cwhy\u201d at first but it brings great insights.<\/p>\n If the interviewee mentions something often or seems to trigger a strong emotional response to a topic that is also an indicator of something you\u2019ll want to spend time exploring to discover new opportunities or problems that aren\u2019t currently being addressed.<\/p>\n Bonus points if you are forward thinking and book a room with a whiteboard. Don\u2019t be afraid to ask the interviewee to sketch out a particular process. It\u2019ll be more accurate and, honestly, it saves you from drawing it later on. It doesn\u2019t need to be perfect and, if they won\u2019t, you can just draw it following their instruction. This tends to help the interviewee wrap their head around a bigger picture instead of just focusing on one aspect of a process or software that doesn\u2019t hold great value across personas.<\/p>\n Human-Centered Design aligns what your users and your team members want, with what is technically feasible and financially viable. It can be applied to both physical and digital products.<\/p>\n It is one of the best pathways to products that are embraced by users whilst also meeting an organization\u2019s business goals.<\/p>\n It\u2019s an approach that helps make sure new products are tailor-made to meet people\u2019s needs and wants. It is achieved when the following pillars of the methodology intersect:<\/p>\n Desirability<\/strong>: What do people desire?<\/p>\n Feasibility<\/strong>: What is technically and organizationally feasible?<\/p>\n Viability<\/strong>: What can be financially viable?<\/p>\n This methodology is flipping the heart of product design from system-focused to human-focused. That means building a product thats interaction fits the way a particular persona works instead of requiring the user to learn new processes through documentation in order to conform to the system.<\/p>\n HCD can generate insights about both your target users and internal stakeholders through the following activities:<\/p>\n Human-Centered Design is really all about building empathy for every person involved in the product design process. This way the final product is tailored as close as it can be to meeting user and stakeholder needs. It maye take a few iterations of the design process to finally understand a problem or create an user-accepted solution.<\/p>\n Interaction Design Foundation describes<\/a> Design Thinking as \u201ca design methodology that provides a solution-based approach to solving problems. It\u2019s extremely useful in tackling complex problems that are ill-defined or unknown, by understanding the human needs involved, by re-framing the problem in human-centric ways, by creating many ideas in brainstorming sessions, and by adopting a hands-on approach in prototyping and testing.\u201d<\/p>\n <\/p>\n It draws upon logic, imagination, intuition, and systematic reasoning to explore possibilities of what could be and to create desired outcomes that benefit the target user.<\/p>\n Design thinking can greatly reduce uncertainty to facilitate lasting and innovative products by regularly engaging with users using rapid prototypes<\/a> to learn, test, and refine designs. It\u2019s important to understand these insights are gained through real-world experiments and not just analytical data or marketing research. Research data can tell you \u201cwhat\u201d but only real-world experimentation will tell you \u201cwhy\u201d.<\/p>\n \u201cDesign thinking is a human-centered approach to innovation that draws from the designer\u2019s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.\u201d \u2014 Tim Brown, president and CEO, IDEO<\/p>\n A process that uses rapid iteration to get to a product that will add the maximum value to the user. It is a cyclical concept where you move through each stage to the next and when you reach the end, you return to the beginning (over and over again) until you have the result that you need.<\/p>\n Rapid prototyping is to let your users \/ clients know the objective of the prototype.<\/p>\n It is also very important to explain to them that ultimately, the prototype is not the actual solution. This avoids confusions and encourages feedback from the clients. The other thing to keep in mind is, it is not necessary to prototype every single feature of the application.<\/p>\n Analyze the application carefully in breadth and depth and make a list of the features that you feel users will use the most and then prioritize the features that needs to be prototyped.<\/p>\n TDCs allow us to quickly get a shared sense of how we feel about an existing design, what might need to be done about it?\u2014?and also grow stronger as a team while we\u2019re at it.<\/p>\n Agile Alliance defines<\/a> Agile as \u201cthe ability to create and respond to change in order to succeed in an uncertain and turbulent environment.\u201d A Manifesto with 12 principles was written in February of 2001 by 17 software practitioners.<\/p>\n Scrum Alliance defines<\/a> Scrum as \u201can Agile framework for completing complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work.\u201d<\/p>\n The Scrum Guide lists<\/a> 3 pillars that uphold every implementation of empirical process control.<\/p>\n The entire process must be visible to those responsible for the outcome. Transparency requires a shared understanding and goals. For example \u201cA common language referring to the process must be shared by all participants\u201d and; \u201cThose performing the work and those accepting the work product must share a common definition of \u201cDone\u201d\u201d<\/p>\n Participants should frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work. This is typically performed at the end of a sprint in a retrospective group session.<\/p>\n If an inspector determines that one or more aspects of a process deviate outside acceptable limits and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.<\/p>\n According to Leankit<\/a> Kanban is Japanese for \u201cvisual signal\u201d or \u201ccard.\u201d Toyota line-workers used a kanban (i.e., an actual card) to signal steps in their manufacturing process. The system\u2019s highly visual nature allowed teams to communicate more easily on what work needed to be done and when. It also standardized cues and refined processes, which helped to reduce waste and maximize value.<\/p>\n Scrum Alliance describes<\/a> four core principles that Kanban follows:<\/p>\n Create a visual model of work and work flow, so as to observe the flow of work moving through the Kanban system. Making the work visible, along with blockers, bottlenecks, and queues, instantly leads to increased communication and collaboration.<\/p>\n Limit how much unfinished work is in process and reduce the time it takes an item to travel through the Kanban system. Problems caused by task switching and the need to constantly reprioritize items can be reduced by limiting WIP.<\/p>\n By using work in process (WIP) limits and developing team-driven policies, the Kanban system can be optimized to improve the smooth flow of work, collect metrics to analyze flow, and even get leading indicators of future problems by analyzing the flow of work.<\/p>\n Once the Kanban system is in place, it becomes the cornerstone for a culture of continuous improvement. Teams measure their effectiveness by tracking flow, quality, throughput, lead times, and more. Experiments and analysis can change the system to improve the team\u2019s effectiveness.<\/p>\n According to Interaction Design Foundation<\/a> a User story is used to \u201cfacilitate the functionality of a system but can be used in any environment to ensure that design and development are focused on user needs.\u201d It focuses on the who, what and why, never how. User stories are structured as the following:<\/p>\n As a [<\/em>persona<\/em><\/strong>], I want to [<\/em>goal<\/em><\/strong>], so I can [<\/em>motivation<\/em><\/strong>].<\/em><\/p>\n Understanding the motivation helps because:<\/p>\n In an attempt to understand the total effort required to complete a story, points are assigned. Points are the unit of measurement for expressing the overall effort required to complete the acceptance criteria for a user story or any other piece of work.<\/p>\n They are assigned using the fibonacci sequence (1,2,3,5,8,13\u2026). 1 story should equal 1 point for 1 day of work. A 3 would merely mean 3x the effort, not necessarily 3 days.<\/p>\n Because story points represent the effort to develop a story, a team\u2019s estimate must include everything that can affect the effort. That could include:<\/p>\n A story point estimate must include everything involved in getting a product backlog item all the way to done. If a team\u2019s definition of done includes creating automated tests to validate the story (and that would be a good idea), the effort to create those tests should be included in the story point estimate.<\/p>\n Stories estimated at very large sizes are called Epics. Epics are made up of smaller journeys. Journeys are made up of many stories. So it goes:<\/p>\n Epic -> Journey -> Story<\/p>\n These organizing principles are used when building a Product Story Map.<\/p>\n Scrum.org describes<\/a> a Sprint as a time-box of one month or less during which a \u201cDone\u201d, useable, and potentially releasable product Increment is created. Sprints best have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.<\/p>\n Sprints events include Planning, Daily Scrums, Review, and Retrospectives. Any stories not completed within the assigned sprint are pushed to the following sprint to be completed first or sent to the backlog to for inclusion in a future sprint.<\/p>\n During an Active Sprint:<\/p>\n Sprints help to determine predictability of team velocity through inspection and constant fluctuation of progress toward a sprint goal while also reducing risk of misapplying effort towards an invaluable goal.<\/p>\n Sprint planning helps product teams determine which stories should be targeted for completion in the upcoming sprint by adding them to a sprint backlog list. The session is moderated by a scrum master who ensures the session is conducted within a time-box of ~ 45 min.<\/p>\n As stories are added to the sprint backlog from the product backlog the product team should be cognizant of the total number of points added to a sprint much in the way a baseball manager monitors the number of pitches thrown by a pitcher. Using the team\u2019s prior sprint velocity as a barometer, make sure not to set unrealistic goals by over stuffing the sprint backlog. Yet with each successive sprint the scrum master should increase the sprint target story point completion by 5% to continually push team speed and productivity.<\/p>\n Once the session is complete there is now a clear window into what stories will be targeted during the sprint. This also provides a window for stakeholders by setting expectations for what should be completed during the sprint.<\/p>\n Once the sprint starts the stories in the sprint backlog are locked for that sprint. Any planning after this is applied to the next sprint.<\/p>\n Backlog Grooming is a session where the product team in collaboration with stakeholders prioritize, add, or remove user stories in the product backlog. Prioritizing the backlog includes arranging the stories with the highest priority at the top and lowest priority at the very bottom. Grooming sessions are occur prior to the start of the next sprint.<\/p>\n Beware that this is generally an informal session and should not be viewed as a status meeting.<\/p>\n Backlog Grooming includes the following elements:<\/p>\n The result of backlog grooming is a oft revised product backlog that alludes to the probable stories for the next sprint. The Product Backlog may also be adjusted overall to meet new opportunities.<\/p>\n Scrum Guides describes<\/a> the sprint retrospective is \u201can opportunity for the [Product] Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.\u201d<\/p>\n At the completion of each and every sprint the product team should gather for an informal session for a formal opportunity to focus on inspection and adaptation of the sprint process. All members of the team, including the scrum master, participates.<\/p>\n Topics considered:<\/p>\n At the conclusion of the session the team should have identified improvements to review and implement in the upcoming sprints.<\/p>\n A scrum huddle is a daily 15 minute session lead by a scrum master where a product team can synchronize. Huddles are used to understand progress toward a sprint goal and to inspect how progress is trending toward completing the work remaining in the sprint backlog. The huddle is held at the same time and place each day to reduce complexity. The scrum master is responsible for ensuring that only product team members participate in the huddle and not stakeholders.<\/p>\n The team\u2019s updates touch on three points:<\/p>\n A huddle increases the probability that the product team will meet their sprint goal. On a daily basis the team should understand how it intends to work together as a self-organizing group to accomplish the sprint goal. The primary target should be trying to complete all the stories in the sprint backlog by the end of the sprint.<\/p>\n Scrum huddles are specifically designed to have smaller meetings more often. This approach can improve communications, eliminate other meetings, identify impediments, highlight and promote quick decision-making, and improve shared knowledge amongst the team. A secondary goal for huddles is to inspect and adapt to the work currently in progress.<\/p>\n At the end of each sprint the team adds up the effort estimates associated with each user stories that was completed. This rate is known as velocity.<\/p>\n In understanding team velocity the team is able to compute (or revise) an estimate project milestones. This is based on the estimates associated with remaining user stories and assuming that velocity over the remaining iterations will remain the same. Scrum Alliance describes<\/a> three specific valuable aspects for understanding team velocity:<\/p>\n As sprints are completed the planning and forecasts will begin to become more accurate as it will become more clear how many points the team can complete within a given sprint.<\/p>\n A product story map is an holistic approach to building a shared understanding for teams around a user\u2019s experience with a product. The map is a simple way to visually tell a product story. Stories are arranged top to bottom to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that deliver value to users and business with each release. Jeff Patton describes<\/a> story maps providing a visual representation of understanding:<\/p>\n The product map is an evolving product backlog where stories can be pulled into a sprint backlog. The map, as seen above, has horizontal slices denoting the group of stories intended to be added to a particular sprint. These often correlate with product release schedules. The first row of stories on the map is considered the stories required to create an minimum viable product (MVP). The stories in the this row are the bare necessity to create a functioning product.<\/p>\n Leading Agile describes<\/a> acceptance criteria as \u201cthe conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.\u201d in other words criteria are the lowest level tasks required to be completed for a given story.<\/p>\n Acceptance Criteria should be quantitative in nature. It can be added to stories at any point in the process but any story added during a sprint planning session should have acceptance criteria assigned before the sprint starts.<\/p>\n Its also important to define the what, and not the how. This tact ensures that requirements are met but allows for flexibility in implementation for the team member working on a story. Tasks should never dictate steps to take.<\/p>\n Acceptance criteria can vary on topic but not intent. Design acceptance criteria is usability-oriented such as \u201cusers should encounter no major usability issue while completing task A\u201d. Whereas development acceptance criteria is task-oriented such as \u201cWrite script X for connect to API Y\u201d.<\/p>\n The user-centric product design lifecycle is a high level process combining user-centered design principles with agile and scrum methodologies. Following this process will ensure that the product meets both user and stakeholder requirements. The 5 pillars of this process are:<\/p>\n By following these pillars, and their subsequent events, a product team is enabled to create a more informed and usable application with the expectation of low user rejection and high user satisfaction.<\/p>\n Stakeholder Discussions<\/p>\n Especially in an enterprise setting, the stakeholder often commissions a project to create a product to solve a perceived problem.<\/p>\n The stakeholder will have a \u201cvision\u201d to execute a solution for a perceived problem. This vision will often drive priority of the roadmap release schedule. The problem statement \/ product story is defined here to help focus the scope of the product and what challenges it will look to solve.<\/p>\n Branding can play as big a role as user experience and functionality. The product must fit into an overall brand strategy (marketing analysis). This can include what integrations are targeted to using the same typography and color palette.<\/p>\n Defining success at the onset w\/ stakeholders buy-in is crucial so that everyone both inside and outside of the product team can measure if they have been successful. It\u2019s important that the goal posts be set at the onset and not change.<\/p>\n Determining which aspects of a product should be prioritized over others. This should guide the project manager in designing the release schedule and what features to work on when.<\/p>\n This is traditionally what is used to drive product development. These requirements help establish acceptance criteria later on in the process. These are the \u201cmust-have\u201d aspects of the product. How often are users competing tasks? How many users use a particular system? How many tasks are they processing? Obtaining analytical data about users helps understand what<\/strong> they are doing.<\/p>\n Understanding the data users are utilizing during their tasks helps for user-defined acceptance criteria. If specific types of data are used it\u2019s important to understand this so you make sure to include that in your product.<\/p>\n Contextual user interviews help understand why<\/strong> users take specific actions. This is the most qualitative event and provides a trough of information about user behavior. It also helps define user processes, tasks, and personas.<\/p>\n Theses are great if you need quick responses to quantitative information.<\/p>\n This can be done during the interviews but doing some sort of testing on the user\u2019s existing products<\/a> can help you improve your product by avoiding the pitfalls the current software falls into.<\/p>\n These are often situational understandings of a particular user action. Nowadays these are written as user stories, encapsulating the persona, action, and motivation of the task.<\/p>\n A persona is an document that contains the analysis of qualitative and quantitative information about a identified meta-person. Personas are made up of groups of real people who identify with a particular role. Each persona has their own goals, tasks, and motivations.<\/p>\n Storyboards help understand user stories in a visual way. They are created at specific situations or use cases.<\/p>\n An experience map They can help organize user stories in a logical way that enables product teams to quickly and efficiently build products.<\/p>\n When trying to map a product flow to a user\u2019s processes, workflow diagrams are essential in understanding when to present information to the user.<\/p>\n Much in the vein of Pinterest, mood boards are \u201cyes, and\u2026\u201d exercise where designers will collect colors, typography, existing products, etc to form a basis for the overall look, feel, and function of the product.<\/p>\n A site map visually shows the steps a user could take to navigate a product, this is analogous with information architecture.<\/p>\n Jotting down general ideas in a notebook or on a whiteboard is the free-form exercise designers can perform to get a general idea of concepts that could be used in the design of a product.<\/p>\n The next level up in fidelity from sketching, wireframing takes into account the device constraints and dimensions on a whiteboard or a program like balsamiq creating very low fidelity mock ups for what a real design could mimic.<\/p>\n Using the wireframes as a basis, prototyping is where the designer creates \u201cgood enough\u201d products.<\/p>\n Using the wireframes or prototypes, designer show users what they\u2019ve come up with in a short amount of time. Users are able to physically interact with the product but no actual code or data is present. This instant feedback look avoids expensive development effort to make sure when the product is built, very little changes would need to be made.<\/p>\n Prototypes at this point have been thoroughly vetted in the previous step so they should be much more fully formed and tested with a users outside the initial pilot group.<\/p>\n This is when a minimum viable product (MVP) gets deployed to a set of pilot users. The product should be thoroughly QA\u2019d from both a design and development standpoint.<\/p>\n Testing with the pilot user group, and more if possible, should be stringent using testing plans to make sure all use cases are thoroughly tested and functionality has no errors.<\/p>\n The big day has come to deploy your release! User behavior should be closely watched using analytics and contact with users should be higher than usual to make sure the product is fully functional.<\/p>\n Throughout this user-centric process there are multiple points in which the people who will use this product on a daily basis have multiple instances of interaction w\/ the product team. Following the learn, build, test methodology stakeholders and users are heavily involved in the beginning during the strategy and discovery phases when building empathy and understanding is the focus. During the design and production phases we are following more of a QA model in eliciting direct feedback from users.<\/p>\n","protected":false},"excerpt":{"rendered":" Concepts and Methodologies To Live\u00a0By At the time I\u2019m writing this post, I\u2019ve been a full-time product designer for ~ 3 years, though my overall professional career is closer to ~ 8 years. Every couple of months I would sit down and braindump lessons learned and methodologies I\u2019d absorbed from work, Meetups, articles, podcasts, etc. As a believer in paying… Read More ￫<\/a><\/p>\n","protected":false},"author":148,"featured_media":10261,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[493],"tags":[],"class_list":["post-10199","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-product-design"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n![\"0-1un9o5hlpvh7qibi-1\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-1uN9O5hLpvH7qIBi-1.png\")
<\/a><\/p>\nUX Design\u00a0Facets<\/h2>\n
\n
\n
Ethnographic User\u00a0Research<\/h2>\n
<\/a><\/p>\n
![\"0-6efpdx66vdlzfuem\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-6EFpDx66VdlzfUEM-2.png\")
<\/a><\/p>\nEthnographic Study<\/h2>\n
<\/a><\/p>\n
![\"0-uzkbmsrfz2idekcx-1\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-uzKBMsrFz2IDeKcX-1.png\")
<\/a><\/p>\n\n
Challenges<\/h2>\n
\n
<\/a><\/p>\n
![\"0-jbk_xhvtx7bptrsg\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-JBk_xHVTx7BPTrSg.png\")
<\/a><\/p>\nInterviewee Interaction<\/h2>\n
Interview Strategy<\/h2>\n
<\/a><\/p>\n
![\"0-ixbimnvx228badly\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-ixBimNVX228badlY.png\")
<\/a><\/p>\nHuman-Centered Design<\/h1>\n
What is Human-Centered Design<\/h2>\n
<\/a><\/p>\n
![\"0-a5tf9stiec_2-f-c\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-a5tf9Stiec_2-F-C.png\")
<\/a><\/p>\n\n
Design Thinking<\/h2>\n
![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/16toxsrJEdVIt_tnVjDVQUw.png\" "\\"\\"")
<\/a><\/p>\nRapid Prototyping<\/h2>\n
<\/a><\/p>\n
![\"0-gn1fyjapuuxo1ltf\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-GN1fyjaPuuxO1Ltf.png\")
<\/a><\/p>\nTactical Design\u00a0Critique<\/h2>\n
Objectives<\/h2>\n
\n
Process<\/h2>\n
\n
Participant Guide<\/h2>\n
\n
Agile, Scrum, and\u00a0Kanban<\/h1>\n
Agile<\/h2>\n
Manifesto\u2019s 12 Principles<\/h2>\n
\n
Scrum<\/h2>\n
The Scrum Framework<\/h2>\n
<\/a><\/p>\n
![\"0-evannkgiejghxigi\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-EVanNKGIEjGHXIgI.png\")
<\/a><\/p>\n\n
Transparency<\/h2>\n
Inspection<\/h2>\n
Adaptation<\/h2>\n
Kanban<\/h2>\n
<\/a><\/p>\n
![\"0-luqp6bi8xnok7zu9\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-lUqP6BI8XNOK7zU9.png\")
<\/a><\/p>\nVisualize work<\/h2>\n
Limit Work In\u00a0Process<\/h2>\n
Focus on\u00a0Flow<\/h2>\n
Continuously Improve<\/h2>\n
User Story<\/h2>\n
\n
Story Sizing<\/h2>\n
<\/a><\/p>\n
![\"0-yj_1llk_2zaw1wkm\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-yj_1llK_2Zaw1WKM.png\")
<\/a><\/p>\n\n
Agile Sprints<\/h2>\n
<\/a><\/p>\n
![\"0-rz86mvwa_a2w-li8\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-rz86MVwa_A2w-lI8.png\")
<\/a><\/p>\n\n
Sprint Planning<\/h2>\n
Backlog Grooming<\/h2>\n
\n
Sprint Retrospective<\/h2>\n
\n
Scrum Huddle<\/h2>\n
\n
Velocity<\/h2>\n
<\/a><\/p>\n
![\"0-7c-rqqz8_i8zov0u\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-7C-rqQz8_i8ZOv0u.png\")
<\/a><\/p>\n\n
Product Story\u00a0Map<\/h2>\n
\n
<\/a><\/p>\n
![\"0-zu5vccw9cjzdobi2\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-zU5VcCW9cjzdobi2.png\")
<\/a><\/p>\nHorizontal Slices<\/h2>\n
Acceptance Criteria<\/h2>\n
<\/a><\/p>\n
![\"0-lfvh1r_dohj8idud\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-lFvH1R_DOHj8iDUd.jpeg\")
<\/a><\/p>\nFocus<\/h2>\n
User-Centric Product Design Lifecycle<\/h2>\n
<\/a><\/p>\n
![\"0-t8l6dtdc3vesvbll\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2017\/06\/0-T8L6Dtdc3vesvbLL.png\")
<\/a><\/p>\n\n
Strategy<\/h2>\n
Project Vision\/Goals<\/h2>\n
Brand Strategy<\/h2>\n
Measure of\u00a0Success<\/h2>\n
Project Priority<\/h2>\n
Discovery<\/h1>\n
Business Requirements<\/h2>\n
\n\u201cWe must begin digital projects by exploring and pinpointing the needs of the people who will use the service, and the ways the service will fit into their lives. Whether the users are members of the public or government employees, policy makers must include real people in their design process from the beginning. The needs of people \u2014 not constraints of government structures or silos \u2014 should inform technical and design decisions. We need to continually test the products we build with real people to keep us honest about what is important.\u201d \u2014 via U.S. Digital Services\u00a0Playbook<\/p>\nAnalytics Review<\/h2>\n
Content Audit<\/h2>\n
User Interviews<\/h2>\n
Surveys<\/h2>\n
User Testing<\/h2>\n
Analysis<\/h1>\n
Use Cases<\/h2>\n
Persona Creation<\/h2>\n
Story Boards<\/h2>\n
Experience Map<\/h2>\n
Workflow Diagram<\/h2>\n
Design<\/h1>\n
Mood Board<\/h2>\n
Site Map<\/h2>\n
Sketching<\/h2>\n
Wireframing<\/h2>\n
Prototyping<\/h2>\n
User Testing<\/h2>\n
Production<\/h1>\n
Prototyping<\/h2>\n
Beta Launch \/\u00a0MVP<\/h2>\n
User Testing<\/h2>\n
Release \/\u00a0Launch<\/h2>\n
User Involvement<\/h2>\n