Downloaded 43 times
Uploaded byTom Illmensee
Build a Recipe for Better UX Process with Fresh Lean Ingredients
This document outlines a structured recipe for improving the UX process, emphasizing a balance between product, process, culture, and leadership. It details a week-long trial run of iterative UX design activities, including assumptions outlining, prototyping, and critique sessions. The final recommendations suggest reviewing UX processes, mapping them, and facilitating group critiques to enhance collaboration and effectiveness.
More Related Content
Similar to Build a Recipe for Better UX Process with Fresh Lean Ingredients
Build a Recipe for Better UX Process with Fresh Lean Ingredients
- 1. Build a Recipefor Better UX Process withUXFresh Lean Ingredients Lean Day / NYC 2013 Tom Illmensee | @tomillmensee | snagajob
- 7. Product < Process< Culture < Leadership Balanced Team Meeting, Chicago 2012
- 9.
- 11.
- 13. If you can'tdescribe what you are doing as a process, you don't know what you're doing. W. Edwards Deming Father of Quality
- 14. #29 Being process-oriented, notproduct- driven, is the most important and difficult skill for a designer to
- 16. Job Seekers andAdvertisers Employers Product manager Product manager Product manager Product manager Product manager Interaction Interaction Interaction Interaction Interaction designer designer designer designer designer Lead engineer Lead engineer Lead engineer Lead engineer Lead engineer Dev team Dev team Dev team Dev team Dev team Scrum master / Agile coach Scrum master / Agile coach Visual design, Copy, Marketing, QA testers Visual design, Copy, Marketing, QA testers (automated), (automated) Database engineers, Operations
- 17.
- 18. 2. Outputs, outcomesand goals
- 19.
- 21. 4. Share, debate,and critique.
- 23. We reviewed frameworksfrom Lean thinkers.
- 24. We reviewed frameworksfrom Lean thinkers.
- 25. 5. Re-organize andre- sequence.
- 26. Think Make Check Personas Sketches Research planning Charter (who, what, why) Design studio Session facilitation Business model Prototyping Analytics Stories & scenarios Information A/B testing Story mapping architecture Critique Content and copy
- 27. The process wasa prototype. So we tested it.
- 28. Trial run: “SaveJobs”
- 29.
- 30.
- 31.
- 32. Think / Make Thursday Stories& scenarios Revise prototypes Visual design
- 33.
- 34.
- 35.
- 36. Think Make Check Test plan Develop variant design Monitor data Requirements (variant Configure testing tool Review results design) Review results of previous tests
- 50. 3 things to do with your team next week 1. Review UX processes via interviews 2. Map each process on cards 3. Review, critique and revise as a group
- 52. Product Process Culture Leadership Balanced Team Meeting, Chicago 2012
- 54. Gratitud e Jeff Patton Marty Cagan Tim McCoy Hugh Beyer Jeff Gothelf Janice Fraser Anders Ramsay Desiree Sy Eric Ries Stefan Klocek
- 55. Thank you. @tomillmensee Limited handouts today. Ping me if you’d like an additional copy.
- 56.
Editor's Notes
- #2 Hello. I’m Tom. I lead the User Experience team at Snagajob, in Richmond, VA. Snagajob is a medium-sized software and web platform company focused on connecting hourly job seekers and employers in service industries. For the past 8 months my team has been using Lean Startup principles to redefine and refine our UX and Product processes, and today I’ll share with you some highlights from this journey.
- #3 Who here has ever had a crappy piece of frozen pizza from a box? These “pizzas” are stamped out in a factory. There is little craftsmanship here – and the product tastes manufactured and industrial. The ingredients are extruded and squirted – and not very healthy. The cheese may or may not originate from a cow. You can’t taste much love. The quality of frozen pizza is inconsistent at best. The product is a reflection of the process used to make it.
- #4 Who has made one of these semi-homemade pies? The pizza dough comes from a can! The ingredients are combined on a cookie sheet and baked. A good word for this process is “shortcuts.” The results are a little better than the frozen options. If the cook uses some fancier ingredients, then you might taste a little more love in the final product but it’s not going to win any awards. Again, the product is a reflection of the process used to make it.
- #5 This is Little Vincent’s Pizza in Huntington, Long Island. I grew up with this place.The next level requires making the crust from scratch, preparing the sauce and selecting quality toppings. The cook uses a special technique to toss the dough. Pizzas are cooked in a special oven. This pizza tastes better than the other options. The product is a reflection of the process used to make it.
- #6 Neapolitan pizza is on an entirely different level.Richmond, Virginia is home to Stuzzi, among the few elite pizzerias in the US authorized to make D.O.C. – following the Naples formula. D.O.C. translates to controlled designation of origin – which requires that a food product be produced within a specified regionusing defined methods and that it satisfy a defined quality standard. Part artist, part scientist - the chef follows an elaborate procedure to make the perfect dough. The dough is made from the finest imported flour – and they don’t use water. Instead they use tears of joy from Italian grandmothers. The tomatoes are crushed by hand. The cheese is not grated, it’s torn and placed strategically around the pie. Pies are fired in a special oven at 1000 F in 60 seconds. The final product is sublime. The product is a reflection of the process used to make it.
- #7 Many types of pizza. Many recipes. Many processes. The shortcut methods produce indigestion. The D.O.C. method produces rapture.
- #8 At Stuzzi, the product reflects the meticulous process outlined in the recipes. This process is a reflection of the chef’s commitment to a culture of quality and craftsmanship. This culture is a reflection of the restaurant owner’s leadership and vision. Software follows the same path. As designers, the things we help produce reflect our processes. We cannot produce high-quality work with a weak or ad-hoc process. And our processes are guided and supported by the cultures we help create within our companies and agencies. Culture reflects leadership and vision. This talk will focus specifically on the process area.
- #9 Snagajob was founded in 2000. We make digital tools and provide services to help people find hourly work and help businesses manage human resources in places like restaurants, stores, hotels, and warehouses. Our products are good – over 40 million job seekers have accounts with us, and sales to employers are up year over year. But we want to be much better than “good.” One key challenge: we’re not a startup anymore. We have evolved into a stage where stability and operational excellence are crucial. Naturally, this means a culture of discovery, experimentation and learning are sometimes in conflict with a culture of delivery.
- #10 At Snagajob, product discovery and definition is the responsibility of a “balanced core team.” Each team is lead by a product manager – who functions as the product owner. The PM works with an interaction designer and engineer to explore new product ideas, enhancements and features. Core teams are responsible for evaluating value, usability and feasibility of each idea, and then describing validated items in backlogs. They build prototypes and validate these ideas with users ahead of the larger development teams. In theory.
- #11 In practice, we recognized that our Agile culture was very good at getting products to market. But we also recognized that releases sometimes arrived a little “burned” around the edges – and sometimes with toppings customers didn’t really want. What do people do with toppings they don’t like? They pick them off. This happens in every organization. Even recently with Apple’s Maps. Part of the problem was that each of our product teams used different recipes, tools, and ovens. Our results were inconsistent because our processes were inconsistent. We devised a process to help improve our process.
- #12 There were several challenges with our model: 1. Discovery and construction sometimes overlapped. This, of course results in wasted effort because the team might commit resources to build too soon. This is what happens when teams plan, design and construct all at once. Hazardous!
- #13 2. With as many as 5 independent product teams, discovery activities varied widely between teams. PMs with stronger project management skills were also stronger with delivery than with discovery. Right arms were stronger than left arms. Left arms were stronger than right arms. Agile principles facilitate efficient construction practices, but do little to support UX practices. This imbalance is easy to spot when teams spend more time prototyping solutions than defining problems. The key to delivering value is understanding what customers’ actual problems are. This photo documents one of Nina Levy’s amazing sculptures. That’s not his real arm.
- #14 Let me take a moment to talk about the P-word: Process. Edwards Deming said: “If you can't describe what you are doing as a process, you don't know what you're doing.” Deming’s quality control and continuous improvement methods were used to optimize manufacturing during WWII, then helped transform manufacturing in Japan in the 1950s and US auto manufacturing in the 1980s. He was lean before there was lean. One of his contributions: Kaizen. Good change through small steps. Solid process guides continuous improvement.
- #15 Why is process sometimes a dirty word in Agile settings? Jeff Patton told me once that process is sometimes the shield we reach for when things get out of control. It’s a way to slow…things…down. But there are some great benefits to being process-oriented. In his book, 101 Things I Learned in Architecture School, Matthew Frederick describes what being process-oriented means. Tell me if the following points ALL sound like they would work for Lean teams…
- #16 Overdone process leads to overdone products. Underdone process leads to mushy products. Here’s what our team did to refine and improve our processes…
- #17 This was our team structure. UX is marked in red.Interaction designers are partnered with PMs and engineers within a vertical team. Visual designers support multiple teams.Each team worked differently, served different users, and focused on separate aspects of the business. Likewise, each designer used a special collection of recipes and techniques to get things done. We were good cooks in the kitchen, but our styles were different. Process varied from team to team – and the products reflected that.
- #18 Our first step was to outline our issues and assumptions about our UX practice. For example, we felt we invested significantly more time creating prototypes than doing foundational research and measuring outcomes. Another key assumption: a leaner process would help us eliminate wasted time and effort building things users didn’t value or couldn’t use easily.
- #19 The second step was to articulate outputs, outcomes and goals. One example of an output: a sequenced list of tools, methods and techniques for interaction and visual designers. An outcome: a consistent framework for developing hypotheses and answering questions about our users. We had 3 goals: (1) APPLY our UX tools consistently across product teams, (2) INTEGRATE our UX process with product management and engineering processes, and (3) EVANGELIZE user-centered thinking and design within the company through a common vocabulary.
- #20 Next we interviewed each designer about their tools and techniques. We deconstructed our recipes to reveal our processes. The goal was to learn how everyone was working, how many people got mixed in the UX kitchen, what departments, and what deliverables (if any) were produced as a result. If you try our approach, we recommend using index cards to document and sequence each task and tool. They are easy to sort and re-arrange. Here’s Chip, our Visual Design manager, taking pictures of his process.
- #21 When we were finished with the interviews we had 7 stacks with over 500 cards! Pictured here is the final mega stack.
- #22 Our next step was to share and discuss our processes and recipes with each other. We organized a workshop away from the office for a day where we could work without interruptions. It was important for us to step away from the action at the office to do this properly. Also turned out to be helpful to have plenty of space because we made quite a mess.
- #23 First, each designer had 20 minutes to present his or her process to the group. Each dealt cards and talked about their systems. We noticed gaps and overlaps because everything was visible. The good news was that nothing on the cards was unknown or surprising. We had all the building blocks laid out – the ingredients were pretty good. It was also apparent why products were inconsistent. UX process was often tied to product management and engineering process. We recognized a holistic approach was needed – not just UX. Here, Archie describes how interaction design is applied on his product team.
- #24 After the designers presented their processes, we discussed frameworks that could help us organize everything. We gravitated to Lean thinkers because of their focus on experimentation and emphasis on customer value.For example, we’re all familiar with building something small, measuring how customers and users respond to it, then making time to learn from the experience. Insights feed back into the build phase, are measured and learned from, until the team has established value, usability, and feasibility.This felt right to us.
- #25 This framework felt a bit “righter”. Janice Fraser re-worked this model slightly to focus on understanding customers and users as a first step. From there, the team designs something they’ll validate. The loop repeats until the team discovers an idea that is valuable, usable and feasible. The team thinks in terms of hypotheses and problem statements instead of solution definitions. We experiment iteratively, quickly and with just enough design to answer research questions. This is the framework our team decided to model our process upon. We liked starting with knowledge about our customers and users.
- #26 We started organizing our cards – our ingredients – into themes based on the THINK MAKE CHECK framework.There was a lot of debate. Sometimes we make stuff to help us think.We separated interaction design from visual design. Seemed to make sense.At this point none of the designers saw the whole breakdown… Which we could barely fit on four tables.
- #27 Here is how the interaction designers sequenced their tools and techniques. We all agreed that we often invested too much time in the “Make” stage developing prototypes. From this point on, we would try to balance our time and attention in all three areas. And we knew we would need to teach our teams to think in these terms, too. Would this work? Which team would have the most friction?
- #28 Just like any new recipe, the process itself was an experiment. We needed to validate and iterate.
- #29 One team chose a relatively small piece of functionality from the backlog: a system to allow job seekers a way to save jobs to their account and apply later. The core team was comprised of a product manager, interaction designer, and lead engineer.
- #30 On Monday we described our primary persona, then placed her at the center of a story in which the feature helps her accomplish a task. In the charter, we defined how we’d measure success, outlined requirements and dependencies, and articulated the business case.
- #31 On Tuesday we sketched solutions collaboratively using the design studio technique. The team created 12 different ways to solve the problem. From there, we took the best ideas from the sketches and wireframed the flow on a whiteboard and quickly built an interactive prototype with Axure.
- #32 On Wednesday we validated the first prototype with users. We do this via remote moderated usability testing and screensharing. This photo shows a typical session led by the interaction designer and observed by the entire team.
- #33 On Thursday we went back to the drawing board – changing the prototype based on what we learned the previous day. At this point we involved the visual designer more directly to help put a bit more polish on the prototype.
- #34 On Friday we validated our refined prototype with moreusers. The UX team also critiqued the design. Pictured here is one of the feedback sheets from the critique session. Our design principles served as lenses that help us evaluate the work.One week. 2 loops through Think Make Check. We knew we were on to something – and the teams noticed right away.
- #35 Another example: A/B tests. These are simple experiments where 2 or 3 designs are put into production at once and we measure to see which one performs best.
- #36 The team wanted to know if jobs should be listed by company name or job title. We applied the Think>Make>Check framework to guide us through the experiment.
- #37 Here’s how we used the process to facilitate the experiment. This also helped us introduce the new UX process to other teams and more engineers.Perhaps the best outcomes yet have come from these tests because the PM, UX and engineers collaborated and communicated consistently through the think > make > check loop. Even when the outcome of an experiment is failure, the thrill of building something fast, measuring it well, and debating the results and planning next steps make the whole effort worthwhile. We learn quickly what users do with the design (quantitative) and have a pretty good theory about why (because we also do usability tests). Frustration develops fast when we skip over think and check. We stopped doing that.
- #38 8 months after we started this journey together, our team has a process that is malleable, a little messy, but made out of the right ingredients and combined in a better sequence. And our recipe and technique is getting better because we work on it every day.
- #39 Here’s how THINK MAKE CHECK plays out now. Your mileage may vary.
- #40 Core teams collect ideas, questions and hypotheses from users, customers, stakeholders, and each other.
- #41 Ideas are rinsed and sorted via filters: ROI, scorecards, product vision, product principles. These raw ideas are processed and prioritized in an opportunity backlog. This is the “discovery” list. The “delivery” backlog comes later. Design debt and tech debt are organized and processed separately.
- #42 The team prioritizes the backlog and chooses which things merit further study. Questions and problems are explored through multiple trips through the THINK MAKE CHECK loop. This is where LeanUX happens. Fast prototyping with as much customer feedback as we can get before anything is coded.
- #43 When the team feels like it has a solution that is valuable, usable and feasible, they describe the feature on cards and grow the product backlog.
- #44 Validated ideas, design debt and tech debt are addressed and released in an Agile way.
- #45 Some completed and functional components are released “dark” until fully assembled.
- #46 Some ideas that need further validation (live data prototypes) are released in BETA, where they continue through the loop at a larger scale. The team understands that these live data prototypes will need to be validated qualitatively and quantitatively.
- #47 But wait! There’s more! We use our process as framework for performance reviews. We measure how and when we apply UX tools and techniques and focus on areas we should improve.
- #48 We made our process visible and tangible in our projects and through consistent UX vocabulary. But process is not something we just talk about. We live it and do it. UX process has helped connect the team and bring renewed focus on customers and users.
- #49 Our process is a work-in-progress. It’s not perfect. We invite discussion and debate. We let it change. We know it’s a recipe we will perfect only by trial and error.
- #50 There are many good UX processes and recipes out there. Ultimately, we learned that our process had to be tailored to our unique culture. We had to roll our own.
- #51 Three easy things you can do with your team this week.
- #52 Of course, customers don’t line up around the block for a solid process. They want a great product. The process helps you get there.
- #53 But a culture of quality and visionary leadership are also essential components. A logical, compelling UX process can affect these areas, too. Our experience is showing that it can help reinforce and even change culture. Over time, our product teams have learned to embrace uncertainty because they have a solid framework to experiment and learn.
- #54 Culture change is never easy because it often means behaviors have to change. At Snagajob we have been successful partly because our sales and support teams go above and beyond to take care of our customers. Our engineering teams have been successful partly because Agile techniques have enabled faster releases. We had “Delivery” down pat, but “Disciplined Discovery” is new territory for the company. The UX team’s goal is to help the company find a way to balance Discovery (fast, efficient experimentation and learning) with Delivery (fast, efficient execution and production). One way to help people embrace change is to shine a bright light on our experiments regardless of the outcome (many fail) and celebrate every new discovery – never brush aside the learning. There are no shortcuts to this. Patience and persistence are key at this stage. We’re focused on taking lots of small steps. More of a “Kaizen” approach seems to be working.
- #55 There are many people who are working to understand the intersections of UX, Agile and Lean thinking. We’re grateful they have shared so much with us and the community. We have been lucky to work with Jeff Patton – his guidance and support have helped us tremendously.
- #56 Thanks. Handouts are available. Looking forward to your questions and comments over lunch!