Click here to read on Edsurge.com.
The 3-day LeanUX NYC event held April 11-13 at NYU was a mix of hands-on workshops and short presentations, all led by folks from different industries who have successfully applied lean and agile principles to designing better UX experiences. (Particularly impressive was the diverse mix of men and women presenting.)
Many startups religiously follow lean advice from the likes of Eric Ries (Lean Startup), Steve Blank (Customer Development), and others that focus on continuous cycles of building, measuring, and learning through testing assumptions, validating learning, and building MVPs (Minimally Viable Products).
But edtech companies are idiosyncratic.
As Heather Gilchrist, Founder of Socratic Labs shared in her joint presentation, “Accelerating EdTech Innovation with Lean Startup,” withKatie Palenscar, CEO and Founder of Unbound Concepts, they have longer cycles of development and sales, the user is often not the same as the customer, and there are often multiple stakeholders to consider. Heather also shared that it’s important to recognize that many schools and programs worry that if they adopt a relatively new tool, the start-up could either fail or pivot, leaving them to scramble.
Much of traditional education technology has been clunky, difficult to use, and often unable to address the problems of most concern to educators. With increased pressures and workloads, teachers and administrators need solutions that are immediately easy to use and that solve real problems. In this context, it makes sense for edtech solutions to begin applying lean thinking to improving the user experience (UX).
Who is the User? Who is the ‘Client’?
Fundamental to the process of developing an effective UX is building an understanding of the client’s needs–a process made even more complicated in edtech because the client is not always the same as the user. For example, solutions for students are often bought by parents or schools, not the students. A teacher may love the ease of use of a tool, but if that tool doesn’t generate the data that an administrator needs, it won’t be adopted. Edtech companies must understand the roles and needs of each stakeholder.
Test Assumptions: Research, Interviews, and Personas
One aspect of understanding client needs is to test assumptions– even if members of the team are prototypical users (former teachers, administrators, etc.).
Too often education as a whole fights the mistaken belief that just because people have experienced a classroom, they believe they understand education and can provide solutions. I loved the comparison shared by Heather Gilchrist: Most people have visited a medical doctor’s office, yet they don’t feel they have medical expertise.
Even when edtech startups have education experts on the team, though, they still run the danger of assuming that all educator experiences are similar. For example, I was surprised at the striking differences in needs and budgets of many districts with fewer than 1,000 students in contrast with large districts such as the one where I worked most recently that had a whopping 107,000 students. Independent and charter schools operate differently, as do urban versus rural schools.
Delving into client needs can take multiple forms: traditional research,
observations, and interviews. As has been mentioned many times here at Edsurge, go where the users and clients are: schools, conferences, after-school programs, malls– really, anywhere!
Ideally, the best learning occurs through observation, though interviews can be effective as long as they’re not leading. Face-to-face is best, but virtual can work as long as the technical connection is tested thoroughly in advance. Running Lean offers some nice templates for both problem and solution interviews.
Personas, or representations of different users, can be one method of developing and sharing insight into customer profiles. Another way to think about this is developing user stories. Adrian Howard cautioned that to be effective though, personas should be continually updated as more information is learned or as a product pivots.
Sketch Often
Sketching was a hot topic at the conference. Ray Dela Pena’s excellentsketching across the design process workshop can be found here.
The essence of the role of sketching is to get ideas down on paper (or digital paper) at all stages of development without worrying about perfection. These sketches create a vehicle for visual communication that is more effective and efficient and a means for gathering feedback. Speaking of visual communication, check out this periodic table of ways to visualize information—great formats to share data!
Build an MVP
There really is no better (or cheaper!) way to test a solution before building the real product than building an MVP. Ariadna Font Llitjos’ workshop,Designing an MVP That Works For Your Users, walks through the whole process of understanding client needs, developing empathy maps, user stories, and finally, the MVP — it’s a worthwhile exercise to go through the slides if you’ve no experience with the process.
One frequently asked question during the workshop: How many times should you conduct an experiment with an MVP? The answer was always, “it depends on the situation.” If something isn’t working, then you shouldn’t continue to interview or observe people using the product or process. How many people need to trip over a tear in the carpet before you realize that the rug needs to be repaired? You don’t need 30 – 40 people to validate that something’s not working. Though it may seem counter-intuitive, the more successful the experiment appears to be, the more times one should run it to keep fine tuning.
All presenters stressed the importance of continually validating each piece of learning, and looping through the process of build-measure-learn.
Don’t stop at the MVP: Good Enough is Not Good Enough
Several LeanUX presenters, such as Melissa Perri and Grace Ngcommented that people frequently use the concept of an MVP incorrectly. Creating an MVP should be an experiment, a proof of concept. Too often people forget to go back and build a full product. In education technology, this can be particularly painful. Early adopters will tolerate “glitch” software but the busy teacher, rushed administrator, or easily distracted student will not. An edtech startup can gain initial traction and attain proof of concept, but if they can’t quickly move to a product that provides a smooth user experience, they’ll lose momentum.
Good enough is not good enough for adoption of edtech solutions. The stakes are too high for educators.
This is a lot to track!
A whole series of workshops was devoted to managing these processes.Kanban, a method for developing software products and processes with a focus on agile development, was the most popular and participants left with a wealth of online resources to support a Kanban model. Another method, Lean Canvas, also helps organize these continual learning and development cycles, and here’s a free digital validation board from LeanStartupMachine, a sponsor for this event.
Education Matters 