Finished a new work-related book called Lean UX.
A trimmed-down version of the Amazon description is as follows:
Lean UX has become the preferred approach to interaction design, tailor-made for today’s agile teams. […] how product teams can easily incorporate design, experimentation, iteration, and continuous learning from real users into their Agile process.
A bit dry, I know. And some of you may be thinking, “Okay, Tami. Just because YOU work on a Scrum team using Agile developmental principles that is striving to incorporate a more lean user experience methodology, that doesn’t mean -I- need to care about this book.”
Right you are, my bizarrely-buzzword-knowing friend. However … if you’re a writer, you may find some of these very problems, principles, and solutions to be eerily similar.
Diving right in ….
I know, I know. I hate it when things start with vocab lists as well, but at the same time there are some concepts that make the discussion easier.
Waterfall Method – Doing all the planning up front, with the expectation that things will go more or less according to plan.
Agile/Scrum Method – Planning as needed, with the expectation that things will go cattywampus and the plan will need to be changed.
Businesses struggle to leave the seeming comfort of the Waterfall Method, but software developers gravitate towards the Agile Method because they deal with uncertainty in their code on a regular basis.
Where Does “Lean UX” fall in all this?
Well, in a software development framework, UX (or User Experience) is often quite difficult to fold into the mix.
UX asks, “How is this working for the user?” or, more to the point, “As this changes, how does it affect the experience the user is having?”
UX is also traditionally done in a Waterfall style. The experience, interface, screens — all the way down to the exact language to be used on a page — are often developed before a single scrap of code is written.
Integrating a cycle of re-examination and re-evaluation of the user experience at the same time as development is uncovering changes and business units are reacting to changes … well, that’s going from two strands to three.
So the purpose of the book is to talk about those difficulties and suggest solutions.
And the reason this matters in a WRITING context is because when you’re a writer, you’re the business unit, the developer, AND the UX professional.
As a business unit, you have a GOAL.
Writing just for fun? Maybe your goal is to “Write A Book”. (Refine that to “Finish a Book”. Refine it further to “Finish a Book That You are Proud Of” … on and on, but this post isn’t about refining goals, so I’ll stop there.)
Writing with intent to publish? Your goal may look more like “Write a Publishable Book”.
Already published? Your agent or publishing company may be helping you refine your goal.
Once you’ve got your goal, it’s the Developer and UX portions that take over actually implementing it.
This one’s easy. You’re the one banging out wordcount, encountering problems, and developing solutions. Most writers probably identify most strongly with the “developer” tag.
The “UX” portion is the bit that cares the most about the user/reader experience. This is the part that wants to make sure a character comes across in just the right way. The one to make sure that the pacing is right, the drama is perfectly tuned, and the climax is worth feverish page-turning.
And just like with software development projects, it can be difficult to inject UX throughout the project life cycle.
As an excellent keynote speaker recently said at a UX conference I went to, user experience is like the blueberries in a blueberry muffin.
It’s really difficult to add them in after the muffin is baked. 😉
So. Back to the book.
“Embrace the notion that your first idea will inevitably need refinement and change.”
We all know that first drafts suck. We’ve heard the advice a million times and no doubt given it out ourselves in turn.
… but if we’re being completely honest, we all kinda think that maybe OUR first draft won’t suck.
This is a safe space. You can be vulnerable here.
Nobody WANTS their writing to suck. But there is a feeling of freedom that comes when you truly embrace that notion that it’s not only okay, it’s EXPECTED. It’s normal, and you have the power, time, and tools to fix it.
“Revision and iteration make for better products.”
This follows naturally from the previous quote. If you assume that your first work will need revision, then naturally revision will make it better.
I’ve also seen this while part of the Saucy Writing Group — every round of critiquing and editing resulted in a better story.
The takeaway for me (because this quote may seem dreadfully obvious to all of you) is that I should EXPECT iteration. Not just one round, but multiple rounds. I should plan for it and build it into my mental model of what writing looks like.
Paraphrasing here, but one of the examples given in the book was about pottery students. One group of students was told their grade will be based on a single pot they make at the end of the class. The other group was told they will be graded based on the combined weight of all pots created during the class. The second group created the BEST pots by the end of the class because they created MANY pots quickly, learning from failure and iterating quickly.
The takeaway from THAT was to write. DO THE THING. Let it suck. Fail. Learn. Repeat. Fear of failure is often the only thing standing between me and writing. (I don’t know if I’ll ever get over this entirely, since it’s been a recurring problem for me.)
Principle: Work in small batches to mitigate risk.
In software development, this means building small things. Instead of building a whole website, build a page. Test the page. See what we’ve learned, evaluate what we know. Then build the next page.
How can this be applied to writing? One chapter at a time, then pause to evaluate how that changes what I know and understand about the story and the characters?
It definitely means NOT writing the whole book before evaluating how it’s going and if it’s working.
Principle: GOOB – Get out of the Building.
Could I have shared that principle without using the non-word “GOOB”? Yes, but don’t even pretend it’s not fun to say. Go ahead, say it out loud. I won’t tell anyone.
Ahem. The idea behind “get out of the building” is to give your users a chance to provide feedback. In software development, it is SUPER easy to assume your users think the way you do and that the experience you’ve designed for them is what they need.
Reality rarely works that way, and the sooner you ask them what they need and what they like, the sooner you can build them a truly wonderful experience.
In writing, I think this is where Alpha readers come in. You want someone with you AS YOU WRITE to give you the right kind of feedback. Is this character working, does this scene fall flat, have you hit the right notes? You may think you’ve written the best scene EVER but you won’t know if it actually works until you ask your readers.
“… Be open to collaboration … Find a group of people who challenge and inspire you, spend a lot of time with them, and it will change your life.” ~ Amy Poehler
This works. I know this works, because that’s what the Saucy writing group was. Those of you still reading this ramblefest of a blog ARE those people.
The takeaway from this quote is that I need to leverage you guys more often. I need to talk to you about my writing. I need your feedback and your partnership.
And I want to be that for YOU as well. I’m not entirely sure where this particular tidbit is going to take me, but I have some ideas brewing for a separate blog post. Feel free to add any thoughts in the comments below if it also tickles YOUR imagination. What can we do, how can we use the incredible power of this group?
What does a User Test look like for writing?
In software development, we whittle down the people to find the right kind of user, then we have them USE the software and answer questions about what they did and how they felt about it.
The key is those questions, though. We can’t just say “what did you think about it” … we have to carefully construct our questions so that we’re not leading them and we get the answer to the questions we have. (I actually super love helping to craft the questions we use in our user tests. There’s a definite “trick” to getting them right, and I love it when we really nail it.)
So if I wanted to user test my writing, I would want to do so before the entire novel is read. Maybe hand out a chapter along with a very specific questionnaire. Not just “did you like the chapter” but “how do you feel about X character” and “did you find yourself skimming at any point?”
I think that sounds pretty doable.
What are low fidelity artifacts for writing?
In UX design, this is like using whiteboards and dry erase markers to design an interface rather than diving right into the code and working with pixel-perfect precision. In Lean UX, they want you developing (and trashing, and redesigning) user interfaces using these low fidelity tools because (as you know) they expect that the first couple of ideas aren’t going to be the winners. So why spend all that time developing them if you KNOW you’re going to throw them out?
So what does that look like for writing? I think it would be avoiding the hard-core editing and the deep grammar and sentence structure style fixes. I think it’s letting the first draft be sloppy and rough.
What does collaboration look like with writing?
In UX, it means letting multiple people show you what they think. Giving them then dry erase marker to use the whiteboard, getting their opinions on things and asking them how things do, could, or should work.
“Design by Committee” doesn’t work — you still have to have one person making the final decision and being in charge of (and responsible for) how it turns out.
In writing, I think it could be much the same. Bouncing ideas off of people to find out what they think could be done or getting some potential plot ideas.
And, of course, there’s the sort of collaboration that some of you remember from Choose, which I have not forgotten …
What is an MVP for writing?
MVP stands for “minimum viable product” and basically means “what’s the least amount of work I can do that will result in SOMETHING the user can have?”
The value of an MVP is that it’s something you can test. Something you can iterate on. Something you can use to see if you’re even headed in the right direction.
A rough chapter maybe? You can get feedback and make sure you’re evoking the right reaction in your readers?
Or would early artifacts look more like a loose synopsis?
I’m not really sure, and the additional notes past-me left for today-me border on cryptic. I’ll share them here anyway.
- Get to the point. Distill to your core idea and present that.
- Prioritize ruthlessly.
- Use clear call to action to determine interest.
- Stay agile.
- Don’t reinvent the wheel.
- Measure behavior.
- Talk to your users.
None of which seems like BAD ideas, but I was at the end of a single-session technical book binge-read, so I forgive myself for not fleshing the thoughts out a bit more thoroughly.
So what’s the point of all this?
Well, firstly, I just like learning stuff. And secondly, I can draw parallels from lots of obscure things right back to writing if I want to badly enough.
But for me, the biggest point was taking some of the advice I listen to when it comes to my developer life and seeing if it could also be applied to my writing life.
And working through what that might LOOK like has been a fun mental nut for my hamster-wheel squirrel to gnaw upon.
Now! I’ve been trying to end this ruddy post for a while now, as I’m sure most of you have gone glassy-eyed.
And the final, decided result?
I’m not sure, but I DO know that the question I want to ask all of you shouldn’t be tacked on to the end of an already rambling blog post. Stay tuned for tomorrow’s much shorter post in which I ask it. =]