In this workshop, I’ll lead you through a series of exercises which help you learn to draw good-looking, quick, useful, user interface sketches, followed by a discussion about how and when we can use sketching in our own projects.

No prior sketching or UX experience required, everyone can draw. Just grab some paper, a pencil and an eraser and follow along. This brief tutorial should take you about 1 hour.

Someone recently asked me “How much time have you usually allotted to paper testing?” I guess I don’t think about it as a process where I allocate some portion of my time to sketching, and another portion dedicated to making prototypes followed by high fidelity comps and production assets. Working that way feels too much like a waterfall process which assumes an orderly progression from concept to product. As a convert to Lean Startup thinking, I know innovative software products don’t come from a predictable and orderly process. As we make things and show them to customers we often learn that we must change the design of the product at a conceptual and structural level, as well as the surface level. How can we create a flexible design process that allows us to keep moving forward fast while allowing course corrections to the design along the way?

Pick the right technique for your situation

In my practice, I’m working with many different design techniques  (solitary and collaborative, low and high fidelity, physical and digital, at a general and detailed level)  throughout the project. I consider the problem I am trying to solve and the kind of feedback I want to gather and choose the method that works best for the situation. In any given week, I might be working on and showing customers: the live product, a generically-styled mock up with fake but realistic data, and a paper prototype as well as using sketches on paper or a whiteboard to think through problems and communicate with my team. Of course, earlier in the project before we have working code we’re using paper and mocks more, but that doesn’t stop once we have a live product. We use them all together as needed.

Three examples

Here are three examples of teams using different methods for iterative design which suit the needs of their team, product and audience.

Carbon Five

Disruptive Innovation using Agile Development and Lean UX
In this blog post Courtney describes a weekly cadence where a balanced team of product owner, designer and developers’ priorities are guided by feedback sessions every week on Friday. In the sessions, the team first shows the working product to potential customers to validate it meets the objectives of the week’s experiment. The pictures in the post show a technique the team used to explore areas where the customer didn’t understand the product. They printed out graphical elements from the product, taped them to a whiteboard and used markers to draw other UI elements. That way the team and the people giving feedback could collaborate on alternative presentations and behaviors quickly and flexibly and save time coding. Cortney  presented more information about working this way at the Lean UX NYC conference in a presentationa called Blending Lean UX and Agile Development.

AppNexus

Heroku

Wow. Lean Startup is really HOT right now. So many new Meetups and conferences and publications and classes and coaches and consultants ready to teach how it’s done. I’m happy to see so many people embrace the concepts, and saddened to see how much of a buzzword “Lean” has become. Similar to Agile, there’s the spirit of the concept (Agile Manifesto) and there’s “going-through-the-motions-agile-with-a-small-a” agile. Writing user stories and doing stand-ups won’t automatically give you the full benefits of Agile. You get the most value when you empower the team and they’re not just going through the motions. Similarly, you can’t apply Lean Startup to any project with any team in any situation and expect to get good results.

We’re reached an inflection point. The Lean Startup movement is passing from a small group of passionate early adopters to the mainstream audience who will metabolize and adapt these practices until they are no longer new and turn into “the way things are done.” We still have the opportunity to share the spirit of Lean Startup and not just teach people to go through the motions. Working in Build-Measure-Learn cycles requires a fundamental change in they way people think and work. Lean Startup changes the way decisions are made in the organization. We value evidence over personal opinion, learning from customers over collecting requirements and build products people actually want. HiPPO won’t let go easily.

I do sincerely believe that Lean Startup is a profoundly different way to work that brings together the best ideas about how digital products are made.  Let’s not blow it.  Here’s my plea to everyone out there speaking and coaching and teaching Lean Startup in the enterprise–help people understand and embrace the philosophy of Lean Startup and not just master the motions.  If we don’t get this right, we run the risk that people will turn away in frustration and miss the benefits that Lean Startup can offer (We tried Baseball and it Didn’t Work).

Common misconceptions about enterprise Lean Startup

Lean Startup is (NOT!) appropriate for all projects.

Lean Startup helps you succeed in a situations of uncertainty– were there’s an unknown market and an unknown solution. If you are refactoring an existing system with an understood audience and a lot of system dependencies, you don’t need Lean Startup, classic Agile is a great approach.

Lean Startup will (NOT!) help you build the product in your head FASTER or CHEAPER.

Don’t burden the team with requirements to deliver specific features or profitability too early in the process. Create a culture that allows experimentation and celebrates failure. Find ways to measure LEARNING and channel it into the EVOLUTION of your product and process. Find product/market fit and make sure you have a identified a problem worth solving and there’s a market for it before you scale up.

An entrepreneurial environment in the enterprise

Give your Lean Startup team the best possible chance for success by creating an entrepreneurial environment inside the enterprise.

Small team with cross-functional skills. People with skills in development, product management & design form the core team (hacker, hustler & hipster). Keep the core team small to maximize collaboration and minimize communication overhead. Support the core with access to subject matter experts who can provide domain expertise and feedback.  As the project grows, add team members with appropriate specialties (e.g. content creation, specialized design and development resources)

Focus. Dedicate the team members for the duration of the project. Team members cannot be doing this part time alongside their other responsibilities. Get the group away from their normal distractions. Move desks so they can sit together. Dedicate a conference room as a project room. Rent them a garage or off-site space.

Embrace an experimental approach. State your hypothesis & recognize assumptions. Be evidence based and determine clear measures to pivot or persevere. This can be hard if there’s a power-over dynamic in the team. Abolish the HiPPO. Good ideas can come from anywhere. There is no truth until the product is delivered to users and validated with satisfaction and revenue.

Fast build-measure-learn cycles. Use just in time design and agile development methods to define, build, deploy, validate and measure continuously. 1-2 weeks “sprint” per experiment is ideal. (For ideas, see “Conversation, Cadence and Culture“)

Frequent interaction with real/actual end users. Don’t just talk to subject matter experts or economic buyers. Continual customer engagement is the engine that drives validation of the evolving product.

Many small experiments. Lean Startup projects in the enterprise can be short (few weeks/month) or longer (several months). An initiative can be as small as one team or several teams in parallel working on related ideas. One way to kick things off is to hold an initial week-long workshop where teams work on different ideas (like a hackathon in the enterprise). A the end the teams present to each other (or the entire company) and the most viable ideas are selected for deeper/longer investigation and development.

Thanks for reading through to the end. Please let me know about YOUR experiences with Lean Startup in the enterprise in the comments below.

]]> http://www.theapprenticepath.com/2013/03/04/programming-for-non-programmers/feed/ 0 http://www.theapprenticepath.com/2013/01/21/are-you-ready-to-goob/ http://www.theapprenticepath.com/2013/01/21/are-you-ready-to-goob/#comments Tue, 22 Jan 2013 04:36:11 +0000 Lane Halley http://www.theapprenticepath.com/?p=776 Last weekend I was a mentor at Lean Startup Machine at ROC in Santa Monica. Here are the slides and audio from my talk Saturday morning.

Unlike other hackathons which focus on technology and what you’re able to build in a short time, winners at Lean Startup Machine are judged solely on the amount of validation achieved through applying the Lean Startup process. This means you don’t have to write a line of code to participate.

If you have experience with user research, usability testing, design strategy, product design, graphic design or any other design or UX role in a freelance, agency or in-house setting, we welcome your participation. As a matter of fact, designers are often the most sought-after team members on Friday night when the teams form up.

Another benefit of the weekend is that you’ll work as part of a diverse team of people with different backgrounds and skills. In addition to the education and mentoring in Lean Startup Customer Validation that are part of the program, you’ll also learn ways to work more quickly and collaborate effectively in teams by focusing on evidence rather than opinion.

For more information, please check out the Lean Startup Machine FAQ

Speaking at SxSW is a very competitive process (tover 3200 speaking proposals submitted this year!). The programming committee takes popular vote as an important consideration when planning the tracks, so we’re calling on the support of our community.

Please click on this link to view the proposal

If you like what you see, please help us out!

• Create an account and vote for us
• Share to your friends with a personal recommendation (twitter, facebook, LinkedIn)

You can also follow @unicornpanel on twitter, or checkout our website.

The growth of the Web and proliferation of mobile devices has created a huge opportunity for people who can design the look and behavior of digital products. This work spans single-person-single-device interactions through experiences that include multiple people, devices and locations. User Experience Designer (UXD), Interaction Designer (IxD), Information Architect (IA), Web Designer (WD)–whichever way you pitch your skill-set, this is truly a GREAT time be working in our field.

But–How do you get that elusive interview? What if you’re just starting out, or changing fields? How do you showcase your talents succinctly and persuasively? What do recruiters and hiring managers look for in a great portfolio? In this presentation, Chris Chandler and I share our thoughts about how to create a UX portfolio that best showcases your ability and helps capture the elusive interview.

There’s also video available on Vimeo. Part 1, Part 2

• (00:24) How can we covert traditional research techniques to be more quick, visual, collaborative and continuous?
• (03:12) Is it harder to get permission for generative or evaluative research?
• (06:24) How do entrepreneurs change when they understand and implement design thinking and research?
• (08.49) How can teams get to “difficult” users (non consumer/specialists like doctors, brokers)
• (12:50) Some UX practitioners feel threatened when non-UX people get involved, what’s your take on this?
• (15:06) What do you do if you are forbidden by your organization to talk to users?

Take a little time and enjoy the series. You can also watch interviews with Eric Ries, Seth Godin, Jared Spool, Johanna Kollman and Janice Fraser.