<http://schema.org/articleBody>
"David Arnoux is Head of Growth and co-founder of Twoodo, helping\u00A0your team organize itself using simple #hashtags.\r\n\r\n\r\n\r\n\r\nLean methods have been famous amongst young and agile companies for years, but they haven't necessarily penetrated larger businesses yet. Its main principle is that scientific data and tests should be the basis for decisions - not opinions or assumptions.\r\n\r\nThe creation of an engaging and successful website requires a strong commitment to design and user experience. The most important link between your product and its design is to get people to do what you want them to do right from the very first visit. We call this the First User Experience (FUE).\r\n\r\nFor some companies, it\u2019s getting a visitor to create an account. For others, it\u2019s getting them to give you their email address or buy an item of clothing. As a general rule, you want to get the visitor to see the value your website offers and upon leaving, be able to clearly explain it to others.\r\n\r\nEven healthy-looking companies like Twitter still face this issue. Good UX design and onboarding processes minimize friction by being clear and enticing.\r\nSo how do lean methods help you solve this?\r\n\r\n1. The Minimum Viable Process\r\nJosh Seiden, author of Lean UX, says the process of creating a product should be conducted in a lean way. This means that each step of development and design should be looked upon as an opportunity to cut waste in order to reach the goal - creating the minimal viable product.\r\nEach member of the team should constantly look at how they are doing their part of the project, and evaluate if they could be doing it more efficiently, or if there are aspects that are unnecessary.\r\nApplying lean consistently will ensure that long-term costs are kept low, by reducing the likelihood of failure at a later stage. This is because there is high certainty of overall success due to each small step being validated.\r\nSimilarly, if all the individual components of a physical device are made excellently, as a whole the device will perform at its best possible.\r\nIn creating a minimum viable product, no team member just jumps in and starts putting together a large piece of a product or service. Let\u2019s take an online service as an example. The idea is not to spend weeks or months perfecting a landing page and an onboarding process, but rather building a basic, scrappy version and putting it online as soon as possible.\r\nThe whole team must be involved in the brainstorming, testing and creating of:\r\n\r\n\r\n\tThe most basic realization of the product in order to test it (see next section on the \u201Cminimum viable test\u201D). The idea is to test the concept before spending hours on design.\r\n\tAnalyzing the results and reiterating based on them, and the possibilities of the tools and skills of the team.\r\n\tBuilding a slightly more complex version of the minimum one.\r\n\tRinse and repeat until the product has been iterated to perfection = attains its goals in a satisfactory way.\r\n\r\n...but the team must also divulge how they do their work. In discussing how a team member does the job (tools used, time spent, steps taken etc.) the rest of the team can offer suggestions on how the process might be made faster, more efficient or better quality.\r\nThe minimum viable process forces the whole team - designers, engineers, market researchers and business managers \u00A0- to work together intimately from the earliest stages. They can suggest shortcuts from their own unique backgrounds (for example a designer will know that using a wordpress template is faster and just as good as the programmer\u2019s idea of building a landing page from scratch).\r\nThis maximizes the potential of their combined knowledge and resources. The result is the ability to deliver more value to the user in faster iterations.\r\nWhy? Because the product is being built in faster, validated micro-steps based on user feedback and user data.\r\n\r\n2. The Minimum Viable Test\r\n\r\n\u201CIt\u2019s dangerous to do too much at once.\u201D - Thomas Wendt, Lean UX Advocate\r\n\r\nIt can take some creativity, but it is very important to decide on the right test. It may even take multiple tests.\r\nSeiden talked about creating a \u201Csandbox.\u201D You must create a test that, even when it fails, does not harm the overall project.\r\nBut defining safe parameters is something unfortunately grey. The most common parameters for choosing which tests to run are complexity and impact. How complex and resource hungry is the test going to be? How much impact will it have on the success of the website.\r\nOf course, the ideal scenario is to run low complexity, high impact tests.\r\nHere are ways of running a minimum viable test:\r\n\r\n\r\n\tMake a simple prototype (this could be a simple drawing) and get out on the street to show it to people\r\n\tExplain the idea to your friends and see if they are interested\r\n\tBuild a basic website explaining the idea and have a \u201Cput me on the waiting list\u201D button\r\n\tAsk on forums\r\n\tAsk followers on social media\r\n\tDo a low-dollar crowdfunding campaign\r\n\tEmail questionnaire to your target audience\r\n\r\n...and many others, depending on what you are trying to test. A/B testing and multivariate testing are also a useful way of minimally testing some finer details such as color, location of features, copy and so on.\r\nWhat the minimal viable test prevents is building features that will ultimately fail or never interest users. This may be a feature the team is convinced will work, but in the end does not achieve product-market fit.\r\nWe discovered this with a Chrome extension version of our product; people just simply didn\u2019t want to know about it, despite us feeling like \u201Ckings of the world\u201D for thinking it up! A difficult part of the learning curve of lean UX is accepting that your expertise from experience cannot be the final word in decisions.\r\nThis hurts many egos, and also traditional workplace values that seniority equals knowledge. Data cannot be refuted, but often is for personal reasons.\r\n\r\n\r\n\u201CYour assumption may be correct, but without data it\u2019s just luck.\u201D - Wouter, Lean UX Designer\r\n\r\nThe pleasure derived from lean is the strong evidence it provides that your idea is valid. It can be tedious to wait for approval for every decision from the audience, but it\u2019s normally worth the wait.\r\nThe great thing about applying lean UX to enterprise is that you can use it without causing a backlash on your brand. This is accomplished by:\r\n\r\n\r\n\tTesting ideas under a pseudonym\r\n\tTesting incrementally so as not to cause a backlash from users\r\n\r\nIt\u2019s hard to \u201Cthink lean\u201D when we\u2019re so used to listening to the oldest guy in the room giving us his opinion on what should be done. I\u2019d say stop listening to experts and start listening to your user (or future users).\r\nIt\u2019s better for all that you stop wasting time and start applying scientific methods to your validation process.\r\n\r\n3) Let\u2019s take a look at a real MVT that we performed\r\nHere\u2019s some context before we jump in. We are a teamwork app. One of the huge challenges we face is convincing people that email is an inefficient way of collaborating.\r\nDefined problem: Getting people to switch to a collaboration tool and stop email\r\nOne of the problems we faced in building a social collaboration tool was that some members of a team just didn\u2019t want to start using a new tool. They\u2019d rather stick to email. So we decided to integrate email to our existing platform.\r\nDefined solution: Integrate email\r\nA user suggested we should build a Gmail extension that would live inside your Gmail inbox. Our gut feelings unanimously told us this was an awesome idea and that we should jump right in.\r\nDefined method: Create a Gmail extension\r\nThat\u2019s where lean came in. Instead of starting to wireframe the idea, design it, code it and tweak it over the next couple of weeks, we agreed to test the idea.\r\nThis was an easy decision to make - a team of five rarely has leftover time during work hours! A larger team may make the mistake of going straight to development.\r\nDefined test: Build a landing page (on Unbounce, no coding needed) with an explanation and an \u201CI want it button.&amp;quot; Visitors who clicked on the button would receive an email stating the product was in the development phase but that would be the first to access the private beta. If we could get enough people to show their interest the idea would go ahead.\r\nDefined KPIs:\u00A0We assigned three days to gain at least 400 qualified visitors to the page. Qualified meant that they used Gmail and knew what Gmail extensions were.\r\nThere are many way to find such visitors (some are listed here). If less than 20 percent signed up, the idea would be considered a failure and we\u2019d have to keep iterating before we would start building.\r\nResults: 8.12 percent conversion rate = Fail. Not enough people showed interest.\r\nWe had even taken the precaution of creating two slightly different versions of the landing page in case one would outperform the other. The better version only reached 9.13 percent conversion.\r\nConclusion: Don\u2019t start building yet. Iterate and try again. We went on through two more iterations of the test before we finally found a solution that worked.\r\nApplying such a process is best achieved when you surround yourself with people of multiple competencies rather than one single speciality. Without knowledge of the possibilities of the various tools we use in the total creation of products, the leanest approach cannot be achieved.\r\nSo if there\u2019s rule #1 for choosing co-founders and early employees, it's going with multi-skilled rather than singularly proficient.\r\nThere is no one-size-fits all approach, and new ideas come about all the time on how exactly you design the parameters of your testing. These tools from Visual Website Optimizer can help to control some of the chaos:\r\n\r\n\r\n\tA/B split test duration\r\n\tA/B split test significance calculator\r\n\r\n4. How we combined lean SaaS and lean UX\r\nWhen we created our company we had a notion of what we wanted to achieve and some assumptions on how to achieve it. We wanted to create a new way of collaborating that reduced friction as much as possible.\r\n\r\n\r\n\u201CYou need to think: what is the least amount of things we can do to test the idea?\u201D - Lis, Lean UX Designer\r\n\r\nOur CEO had a coding background and found that simple commands achieved a lot. Why not bring this feature out and create a seamless system of organization?\r\nPeople were being introduced to simple commands such as the #hashtag on Twitter and the +plus on Google. Online conversations were also using *stars to highlight emotional or important words. This was the first validation: people were using symbols to organize information.\r\nSo how would such an idea be brought to reality? We decided on what crucial actions people would need to use our product successfully:\r\n\r\n\r\n\tBe able to effectively label information\r\n\tBe able to create a network of colleagues\r\n\tBe able to discuss the information in a conversation-like style\r\n\r\nThe central part of the system was going to be the labeling, which is what we tackled first. We used a whole bunch of symbols (&amp;amp;gt;, #, *, +, @) to convey collaboration. But people found it too confusing to learn so much, even though for us it was \u201Cjust five symbols!\u201D\r\nA two-week long A/B test comparing all the symbols against using only @, # and + to accomplish good collaboration showed us that less was more. That was based on our first private beta users\u2019 feedback.\r\nOur minimal viable test was to build a basic prototype, invite a small number of people on, and to do an extensive questionnaire (and sometimes interviews) to learn from them. We were surprised at how many people we willing to answer the questionnaire. Almost 70 percent of people answered - so don\u2019t chicken out of doing surveys!\r\n\r\nWhen the core basic elements were secured, we looked to competitors for options on how to design an interface that would suit what we wanted our audience to accomplish. They needed to be able to put in tagged information, have conversations about it and then extract the tagged information into a checklist. It needed to feel social.\r\nWith that in mind, the logical colors to choose were light and airy. There had to be a minimalist view to reduce confusion and distraction. A feed-like design would be familiar to users from both conversations on forums and various social media platforms.\r\nWe relied on family and friends to give us kneejerk reactions. We\u2019d show it to people at conferences and ask what they thought. We\u2019d frequently ask our super-users from the private beta stage about the choices we had made, and how we could make it more intuitive.\r\nThe faster you iterate based on solid data, the better your company will perform.\r\nThere\u2019s no easy way of applying the lean to your workflow or lean to your testing. Developing a lean method with your team will take many trials and errors before getting it right. It\u2019s a mindset that has to be developed. If it can be achieved, the benefits to be reaped are enormous."^^<http://www.w3.org/2001/XMLSchema#string>
<http://thenextweb.com/dd/2014/03/05/stop-wasting-time-lean-ux-methods-help-test-build/?awesm=tnw.to_s2g8R&_escaped_fragment_=yAwM9>