What is Lean UX: Efficacy

Posted by & filed under business, design, lessons learned, thoughts.

Last week I did a knowledge sharing presentation reporting back on my March trip to Lean Day UX in NYC. I’d been getting a lot of questions about lean UX. So the presentation had become more focused on the what, why, and how of lean UX and less on my trip.

The day before I presented I got some final feedback and found myself feeling like I still hadn’t nailed it. I was missing the what in simplest terms. That’s when I managed to boil it down to these two ideas:

Lean UX is:

 

1. Collapsing [documentation] steps by concepting in a predetermined set of real code (eg. Bootstrap or Foundation) in order to speed execution (i.e. efficiency).

 

2. Making all hypothesis testing [vision through tactics and business creation through customer use] more iterative and explicit in order to improve focus (i.e. effectiveness).

 

Simplification could be taken a step further in focusing on the why, saying that the combination of efficiency and effectiveness is efficacy (i.e. The ability to produce a intended result.) so that lean UX becomes the pursuit of efficacy. However, at that point the how, ability, or means by which to produce efficacy is lost, and the definition could be used for any type of lean activity.

Focusing only on the how, collapsing steps and emphasizing testing, would eliminate the value of why lean UX should be pursued.

Thinking these things through helps me with how to communicate why I think what I think. Let me know what, why and how you think in the comments below. Thanks! David

Content Strategy in One Google Search

Posted by & filed under business, lessons learned, summaries.

So, I set out to get a braindump on content strategy. I Googled “content strategy,” and as I sifted the wheat from the chaff I had to keep structuring (the below doesn’t quite qualify as writing) my post to try to do justice the information I was gathering. Here are the the bullets.

9 Hard-Hitting Content Strategies for Small Business Blogging

by Neil Patel

Mind your…
objectives
readers
calendar
process
images
message &
maintenance
Strive to make your content…
original
correct
informational
not promotional
relevant
saveable
shareable
printable
useful
substantive &
positive

Content Marketing Strategy Worksheet and Template to Jumpstart 2013

by Susan Gunelius

Questions to ask yourself before writing or rewriting content for your website.

  1. Who are you?
  2. What, where, and why do you want what you want?
  3. What, where, and why can you offer what you can offer?

Ask the same of your channels, complements, customers, suppliers, substitutes, entrants, and competitors.

10 Must-Have Templates for Content Marketers

by Michele Linn

Grab tools you can use and a site that is oozing with content expertise.

What I Learned this Week: People Need Something to Look at.

Posted by & filed under business, design, lessons learned.

I recently attended Lean UX Day in NYC. It was great. There were a lot of the same tools and concepts that have been going around the user experience (UX) design community for several years but with some new twists, all of which I should write about soon.

One of the new wrinkles I’ve been reading about is the move away from creating documents like wireframes  (i.e. line drawings) and visual mockups. The IT industry has been doing less documentation for several years in the spirit of iterative (i.e. agile) development, and UX is getting there too.

What I learned the hard way in the last week has been that people will always need something they can see, or better yet put their hands on. Back in NYC one of the stories told was about the designer, business lead, and developer all sitting around the table talking about ideas and when they had something solid the designer asking the developer if he should create some wireframes or mockups, but to everyone’s surprise the developer responded, “No, I think I’ve got it just about built out here.” Nobody had noticed he’d been using libraries of publicly available code to build a 80% polished experience.

Right away they had something to look at, to touch. There was no lag between the idea generation and experience creation. Back on the job, I made what is now an obvious mistake. The schedule was tight and people already had their plates full with other work.

I pressed our content manager/builders for a few pages worth of a proof of concept, but even after we had some technical issues worked out, a bit of copy, and a view visual design ideas put together, the overall concept didn’t hang together. Nobody, except for me, who can have a propensity for seeing things in my head but not always communicating every detail to teammates, could see it.

The problem, you can’t do lean non-documented design, without creating something. The beauty of lean design is that its practitioners have worked to discover how to (1) get really good at targeting exactly what the objective of a design is, sometimes called the minimum viable product (MVP) and (2) get really good at building the infrastructure to quickly assemble the parts and pieces needed to deliver that objective by creating and using libraries of components rather than hand crafting every aspect of an experience.

The solution, In order to  actually do lean UX, you’ve got to focus on making sure you have your business criteria (MVP) and if you don’t actually create something, people won’t understand it.

If all you do is rush people, keep iterating, and don’t quite have anything tangible to show when others expect specific requests and time to work all you’ll have are frustrated people around you.

You have to make something.