How to make quick, useful UI sketches

Click here for an updated version of this class.

As I’ve embraced Agile and Lean Startup methods, I’ve learned to adapt my UX practice so it is more QUICK, VISUAL, COLLABORATIVE and CONTINUOUS. Learning how to quickly sketch screen layouts and user interface (UI) elements helps me think through design problems, communicate ideas to other people, collaborate, and reduce the need for pixel-perfect deliverables.

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.

Free resources to hone your design skills

If 2013 was the year of code, let’s make 2014 the year of design. Here is a list of free resources that can help you develop and improve your design skills, delivered right to your inbox!

Hack Design

HackDesign is “An easy to follow design course for people who do amazing things.” Sign up to get a new design lesson in your inbox each week, hand crafted by a design pro.

Design for Hackers

Design for Hackers teaches the principles of good visual design to programmers, developers, and makers of any kind. Each email from the 12-week course is based upon a chapter of Design for Hackers. You can buy Design for Hackers as a companion book for the course, or just get the emails for free. There’s also a Facebook page where people in the program connect.


Gibbon makes “playlists for learning. Almost all the knowledge is available on the web, all you need is someone to guide you to it.” Specify how much time you want to dedicate per week and the topics you’re interested in and it will send you a list of links in email each week. Topics include design, development and business.


I look forward to the myFonts Newsletter because it’s always a great source of inspiration and education about fonts and the designers who create them.

The Smashing Newsletter

I consider the Smashing Newsletter a must-read for any Web designer. It’s a great way to track hot topics and emerging trends in Web design.


Most UX people are aware of Jared Spool through his writing, speaking and event hosting. When you subscribe to the UIE Newsletter you get UIEtips mailings which contain useful free content, in addition to announcements of paid virtual seminars and events.

If you know a great resource not on this list, please leave a note in the comments. Thanks!

Top books from 2013

When Media Contour asked me to contribute to a year-end wrap up of favorite books, I was happy to participate. I’ve re-posted my selection below. You can check out the full post here which also includes lists from fellow Cooperista Chris Noessel and LA friends Kai Gradert and Jod Kaftan.

Q: What are you currently reading?

I read a lot and hardly ever finish one book before I start another. Here are several favorites from the top of the stack.

Evil by Design: Interaction Design to Lead Us Into Temptation by Chris Nodder
The practice of User Experience design requires an understanding people and their motivations. In this well-written book, abundantly illustrated with examples, Chris examines how the seven deadly sins (Pride, Sloth, Gluttony, Anger, Envy, Lust and Greed) form a framework for understanding human behavior and provides 57 design patterns to make the insight actionable. I’m savoring this book a chapter at a time, because I’m taking so many notes about ideas I want to test in my current projects. I do most of my reading on my iPad or Kindle, but I made an exception for this book because It’s beautifully produced and a pleasure to read on paper.

Design for Hackers: Reverse Engineering Beauty by David Kadavy
David is the author of famous and funny blog posts including “Why you hate comic sans.” I work with a lot of people who don’t have a design background. When they ask me “what’s an accessible book about design?” I love recommending David’s book because he’s such a clear thinker and good writer. He also has done a great job building a community of learning around this book. You can connect with David and other readers of the book on his Facebook page.

Earlier this year, I also enjoyed jQuery for Designers: A Beginner’s Guide by Natalie MacLees. Natalie is a pillar of our local WordPress community. It’s great to see some of her wisdom captured in print. If you enjoy working through cookbook-style tutorials, and have a basic understanding of css and html, following the chapters of this book will give you a great basic understanding of the mechanics of jQuery for use in your next Web design project. I am grateful to Natalie for making this subjct approchable enough I could tackle it in a couple weekend.

Q: What’s up next on your reading list? Why?

I have a huge stack of technical books I plan to skim or reference in the next year. Here are a couple that I’m reading for fun.

The Year Without Pants: and the Future of Work by Scott Berkun
I started getting more interested in WordPress this past year. I’ve been self-hosting my WordPress blog “The Apprentice Path” since 2010. After attending WordCamp LA In September I started to realize the greater potential of the platform and was impressed with the culture and community that surrounds WordPress. I picked up Scott’s book to learn more about how things work behind the scenes at Automattic. I also had the pleasure of seeing Scott speak at the Warm Gun conference in San Francisco a couple weeks ago. You can see a summary of his talk on his blog

I’m really excited to see that Mary and Tom Poppendieck have a new book “The Lean Mindset: Ask the Right Questions” Everyone who is interested in “Lean Startup” or “Lean UX” or “Lean” anything will do themselves a HUGE favor by going back to the source and reading Mary and Tom’s writings about Agile and Lean Software Development.

Q: What is your favorite book and why? What are the key takeaways?

Am I allowed to say “my sketchbook?” What, you mean a PUBLISHED book? OK then.

I had to think carefully about which books I’ve read more than once. And then I noticed “101 Things I Learned in Architecture School” by Matthew Frederick on the shelf near my desk. This small, lovely and useful book is a collection if thoughts and practices drawn from architecture and relevant to many other disciplines. Sometimes when I am stuck for an idea (or procrastinating!) I flip it open at random and find just the answer I need.

Best wishes for the new year, and Keep Reading!

Update: Combining UX and Development Stories

About a year ago I wrote a post “Combining Design and Development Stories in Tracker” for the Carbon Five blog. In that post, I describe my experience writing separate UX and development stories in one backlog. Recently, a few people have approached me to ask my current thoughts on the topic. Do I recommend Tracker for managing UX activities? What do I think about combining UX and dev activities in the same story? My thoughts are below. What’s your experience? Please leave me a comment!

Q: Do I recommend Tracker for managing UX activities?

A: A tool is just a tool. I used Pivotal Tracker because that’s what my team wanted to use. My advice would be pretty much the same if we were using Trello or JIRA or Confluence or paper cards or any other issue tracking tool. The point is the conversation that happens and who participates.

Q: What do I think about combining UX and development activities in the same story?

A: My current thinking on the subject is that there’s an adoption curve. Teams grow more comfortable thinking about UX and development work holistically when they understand the “big picture” of the project they are working on and have engaged, collaborative working relationships with each other.

The Agile UX Adoption Curve

Through my own projects in the past year, and by listening to other people share their own experiments with this, I think there’s an adoption curve. Designers show up, provide value and form relationships and UX work is gradually drawn into the team’s process. I’ve seen teams move through stages that are roughly like this:

  • Designer shows up at standups to consciously represent they are part of the team and learn what’s going on. UX work is discussed with PM and not visible to the development team.
  • Designer works closely with PM and participates in iteration planning meetings to guide the scope of stories written. Designer shows comps/wire frames at the start of an iteration planning session and facilitates conversation to help the team envision what they are making.
  • Designer maintains work in some parallel system, for example, Pivotal (development stories) Trello (PM/design stories) or two walls of cards in a team room. Dev team has visibility into design activities but it’s not integrated.
  • After trying to deal with the complexity of work on two boards and blocking issues, team realizes that ux design and validation work has to be pulled into stories, team starts to use tags and epics to identify stories that contain various activities (design, validation, styling). Designers and developers start to pair more at this point.
  • Team realizes that it all has to be considered together and starts to write stories that include development and design work together. Teams start to break down the distinction between “developers” and “designers” as strict roles start to blend into each other.

I’ve noticed that “complication factors” (power dynamics, huge team, distance collaboration, team members shifting in and out) tend to keep teams in the first steps of this journey. Teams that work together closely over time tend to get farther down the list.

I’d love to know what you think about this. Please share your own experience in the comments below.

Agile & UX Together at UX Week 2013

At UX Week in San Francisco I spoke about “Agile & UX: Two Great Tastes That Taste Great Together.”

Many UX designers are introduced to Agile as a set of practices (standups, sprints, backlogs, retrospectives). At the core, agile is based on a set of values. By considering and connecting with these agile values, UX designers have an opportunity to connect with developers to cultivate better understanding and smoother working relationships.

I encourage UX designers to cultivate an agile mindset by keeping these six objectives in mind:

  • Be part of the team
  • Create conversation
  • Run experiments
  • Reduce waste
  • Find your cadence
  • Expand your toolbox

Please take a look at the deck and tell me what you think in the comments below!

Workshop: How to Draw Quick, Useful, UI Sketches

OPODZ, Los Angeles, September 18, 2013

Quick, Useful, UI Sketches

In this fun, hands-on workshop, I’ll lead you through a series of exercises which help you learn to draw good-looking, quick, useful, user interface (UI) sketches.

This class will cover:

  • Types of sketches
  • Why sketch?
  • Sketching materials
  • Grids, containers and functional groupings
  • Developing your personal UI shorthand

This workshop is appropriate for designers, product managers, Web developers, software engineers or anyone else who needs to think about or communicate concepts for digital products. No prior artistic or drawing experience necessary. If you can draw a circle, a square and a triangle, you’ve already got the basics covered!

Learning how to quickly sketch screen layouts and UI elements helps you think through design problems, communicate ideas to other people, collaborate, and reduce the need for pixel-perfect deliverables. Join me for this two-hour workshop and pick up some new skills you can use right away in your own projects.

Workshop: Lean UX for Digital Designers

Hands-on Lean UX Workshop for Digital Designers

I’m pleased to announce that I’ve joined Jaime Levy or JLR Interactive to present a 2-hour, hands-on workshop geared toward digital designers. Join us to learn Lean UX techniques that can be used immediately with your clients and teams.

Practice pragmatic Lean UX techniques

The following topics will be covered along with hands on exercises:

  • What is Lean UX?
  • Defining the Product & Customer
  • Exploring Key User Experiences
  • Validating the Customer and Idea with Qualitative Research

Learn with the experts

Lane Halley is a product designer at Carbon Five, where she uses Lean UX design and Agile construction methods to create Web and mobile products. Lane’s a popular teacher and speaker on the subjects of user experience (UX), Lean Startup, Agile and product design. Recent speaking engagements include The Los Angeles UX Meetup, The Lean Startup Conference, QconSF and Agile UX NYC.

Jaime Levy has been a pioneer for over 20 years in the creation of innovative browsing and non-linear storytelling experiences for digital products and services distributed on disk media, mobile devices, the Web and iTV. These days she runs a User Experience Strategy and Design consultancy in Los Angeles called JLR Interactive that caters to startups and enterprises who are open to practicing “lean” principles for transforming their business concepts into sustainable and scalable online solutions. Throughout her career, Jaime has been a part-time college professor, for 7 years at NYU ITP and is currently teaching UX Design in the Fall/Spring quarters and UX Strategy in the Winter quarter at UCLA Extension.

The Origins of Lean UX

A lot has happened since 2007 when Desiree Sy and Lynne Miller published “Adapting Usability Investigations for Agile User Centered Design. Many people who were influenced by that paper created related material under the terms “agile ux” “agile experience design” “balanced team” and “lean ux.” If you’re interested in learning more about the influences and thinking behind “Lean UX” as it evolved, check out some of the presentations from the people below:

Anders Ramsay
Desiree Sy
Janice Fraser
Jeff Gothelf
Jeff Patton
Johanna Kollmann
Jonathan Berger
Josh Seiden
Lane Halley
Tim Mccoy

Desiree and a bunch of the people in the above list collaborated to produce a Balanced Team conference in 2011. Many of these same folks also participated in the Agile UX NYC conference in 2012 and the Lean UX NYC conference in 2013.

If you’re interested in upcoming events, check out
Lean Day: West Portland OR, September 2013
Balanced Team San Francisco CA, November 2013
Lean UX NYC New York NY, April 2014

I am sure I’ve forgotten people who should be included here. Please add a comment with the name and URL for anyone else you feel should be on this list.

Iterative Design

Why Iterative Design?

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.


Suzanne from AppNexus describes how her team used a designer/developer pair and iterative design methods to share an initial concept with users and evolve towards a successful solution. Note that the team had an idea going into the project that was not validated by the users. Through multiple iterations, showing things to users and getting feedback, the team eventually found a great solution. Also note that these technical users required realistic data before they could provide specific feedback about the concept.


In this project, Mark and the Heroku team used a prototype built in the Sinatra framework, using spaghetti code and inline styles, with read-only access to a live database.


So remember, it isn’t about the technique you use, it’s about the learning you want to gain.


Nurturing Lean Startup in the Enterprise

Lean Startup in the Enterprise?

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.