Thinking and Making

Seven barriers to UX: The Organization doesn't VALUE design

Austin Govella — Tue, 20 Sep 2011 05:25:52 GMT

Part two of my series on the organizational barriers to good user experience is up on the Follow the UX Leader blog.

We’re starting our deep dive with the first barrier: your organization seems like it doesn’t value design. If you’re interested, I’d love to hear you feedback.

“The seven barriers to UX: the organization doesn’t value design.”

Lean UX and Agile interview on Epic Bagel

Austin Govella — Tue, 13 Sep 2011 18:53:00 GMT

Epic Bagel’s Jon Bolt and I took some time last week to sit down and talk (via Skype) about my experiences with agile, user experience, and lean UX. Jon’s posted audio of the discussion on his blog: Lean UX and Agile with Austin Govella.

Win a copy of Blueprints for the web

He’s also giving away two copies of Information Architecture: Blueprints for the Web. Check the post for information on how to enter to win.

(When you’re listening, you can hear me sniffling. It’s not odd for allergies to plague my innocent, docile mind, but this time, it’s because there was so much crap in the air from the wild fires. See, even when peril looms close, I continue my dedication to user experience and agile teams.)

Barriers to UX series on the Follow the UX Leader blog

Tue, 13 Sep 2011 17:36:21 GMT

Lately, it seems like all my posts are more promotional than informational. Please bear with me. I’m trying to get the word out and share my experience and thinking with wider audiences. I’m still writing, but the posts publish at other places.

A case in point:

I’ve been a fan of Jeff Parks’s Follow the UX Leader workshops since he launched them a couple of years ago. Recently, Jeff invited me to contribute to the Follow the UX Leader blog. I’ve started a series of posts that expand on organizational barriers to better user experience. I’m expanding on the barriers covered in my Big Design presentation, How to Farm Miracles.

The first post went up last week, “Seven organizational barriers to designing better experiences”.

We plan to continue the series. The second post should go live in the next day or so, with more to follow.

More conversations; more feedback

One of the reasons I’m trying to publish in other venues, is I’m trying to get more feedback from a wider group of people. As I continue to refine my thinking and approach, real-world feedback from a diverse group of people is super important.

If you have any comments or feedback on anything I’ve been talking about, please leave a comment, or drop me an email at ag@agux.co. I’d love to talk about this with you. I really do sit up at night thinking about this stuff.

Houston UX meet-n-greet next Wed, Sep 14

Austin Govella — Thu, 08 Sep 2011 03:15:06 GMT

Houston Experience Design has a UX meetup next Wednesday, September 14 starting at 5:30 pm at the Nouveau Antique Art Bar just outside downtown.

There will be free drinks, and an entire library of Rosenfeld Media books for a giveaway, so it should be a pretty good time.

Here’s a link to the event listing on the group blog:
* http://houstonexperiencedesign.wordpress.com/2011/09/06/wed-sep-14-back-to-school-meet-n-greet/

About Houston Experience Design (H.E.D.)

Houston Experience Design is a local group of Houston user experience professionals that get together to talk shop, share tips, and network with Houston’s burgeoning user experience and digital community.

They cover a focused range of user experience topics:

Content strategy
Design thinking
Interaction design
Information architecture
Mobile design
Service design
Social media
Usability, and
Visual and web design

There’s a slate of upcoming events that include networking, presentations, job fairs, and workshops with Houston’s stellar design community.

Visit the website for more information: houstonexperiencedesign.wordpress.com.

Agile+UX, Lean+UX, and Balanced Teams

Austin Govella — Thu, 28 Jul 2011 11:27:00 GMT

Agile+UX almost gets there. Lean+UX defintiely colors in the rest of the picture, but if you only make your process more lean, you’re not building better organizations and balanced teams.

What’s a balanced team?

First, it’s not a binary designation. One team can be more or less balanced than another. Second, a more balanced team has a higher design literacy among its members than a less balanced team. The balance in “balanced team” refers to the imbalance in design literacy across the members of your organization. If your information architect is the only person on the team with any user experience knowledge, then your team is very imbalanced.

It’s important to note that the goal is not an “agile” or “lean” user experience practice. The goal is to raise your team’s design literacy so its design thinking is more balanced among the varied perspectives and experiences that your team members bring to the table.

The goal is to build balanced teams, not better interfaces.

(To a great extent, I’ve appropriated the “balanced team” phrase from others. For me, it encapsulates my three core principles. But, before you lump my ramblings with the balanced team approach, I encourage you to make up your own mind by checking out .)

A Manifesto for User Experience Design

Austin Govella — Wed, 27 Jul 2011 10:15:00 GMT

Translated into Brazilian Portuguese by Daniel Souza for Web Insider.

Translated into Spanish by Sergio Ortega.

Over the last six years, I’ve watched how teams work together to create products. Much of this watching happened with agile development teams. During this time, my personal user experience practice evolved from a focus on how to improve the design to how to improve the organization. Shifting my view from the interface to the organization revealed three principles:

1. Designers don’t design anything. Organizations design everything.

That one person in your organization who doesn’t “get it” creates a drag on every product or service you produce (just as your best thinker is an accelerator). To create better experiences, you have to create better organizations. You have to improve your organization’s design literacy.

2. Organizations face seven barriers to designing better experiences.

The barriers are value, focus, time, memory, talent, process, and improvement. Sometimes these cultural barriers get codified into your organization’s process. These barriers represent the distance between you and the balanced teams your organization needs to create better experiences.

3. Don’t change what you do. Change how you do it.

Your design activities don’t change. Change how you work with your team. Change how you do it, so your goal is always a better organization instead of a better product. Change how you accomplish the design, so that you are always improving your team’s design literacy.

Transparency reduces organizational failure

Austin Govella — Sat, 23 Jul 2011 14:02:56 GMT

Victor Lombardi notes a great article on transparency from the New Yorker.

In it, a very successful hedge fund cites it’s success on the concepts of transparency, evidence-based decision-making, and honest feedback.

This is the kind of culture you can help engender by making your design process as visible as possible.

Techniques that help this include design critiques. Check out the presentation on critiques by Adam Connor. Critiques teach how to give and receive honest feedback.

Transparency can also be helped by simple steps like putting your process on the walls. I detail this in my presentation from Big Design on miracle farming.

Transparency can also be engendered through the use of design studios. Will Evans and Jeff Gotthelf have been detailing their process with studios at TheLadders on Will’s blog.

I used to phrase design’s most important tenet as being about communication, but communication is too fuzzy a word, suggesting a broadcast with the magical hope of someone understanding. Instead of communication, we we’re really working towards understanding.

We really are in the understanding business.

UX Miracle Farming

Austin Govella — Fri, 15 Jul 2011 21:18:58 GMT

Update: Friday, September 2

I updated the slides with complete speaker notes, so each point is now fully explained. In addition, I’ve added a PDF version of the talk that shows the slides and speaker notes on the same page.

Austin speaking at Big Design, 2011. Photo by Russ Unger. I look like Lisa Loeb with a goatee.

I presented “A Guide to Farming Miracles” at the Big Design conference in Dallas on Friday, July 15. There was a great audience, and I presented seven barriers that organizations face when trying to build better products and services:

The organization:
...doesn’t VALUE design.
...can’t FOCUS on everything it needs to do.
...doesn’t have TIME to accomplish all design.
...has no MEMORY about its design decisions.
...has a low QUALITY of design by others.
...has no UNDERSTANDING about what it takes to do UX.
...can’t validate IMPROVEMENT.

Livia Labate’s UX practice diagram is an example of a design story. Photo by Will Sansbury.

Alongside identifying the problems, I offered seven tactics for overcoming those barriers that are simple enough to take and implement on Monday. Unfortunately, time kept me from introducing the the scads of other tactics UXers can use to improve design at their company.

Fortunately, that means I have lots of juicy blog fuel for the future.

I uploaded today’s Miracle Farming slides to Slideshare and embedded them below for convenience.

You can also download a PDF version of the talk that includes slides and full speaker notes.

The audience appeared to enjoy the talk. You can see some of the response on Twitter using the hashtags, #miraclefarmer and #miraclefarm. Being able to see audience response like that really helps tweaking presentations and performance.

A Guide to Farming Miracles (for UX teams in tough environments)

UX Health Check presentation at SXSW 2011

Austin Govella — Mon, 14 Mar 2011 01:00:15 GMT

This morning I spoke alongside Fred Beecher and Lou Rosenfeld in a workshop at SXSW Interactive, “UX Research and Web Analytics: X-Ray Insights”. Fred showed several case studies where UX and analytics worked together (or against each other in one case). Lou demonstrated both the value of search engine analytics, and how easy it was to begin analyzing your search engine logs today to make useful immediate changes.

I introduced the UX Health Check to the SXSW audience. Unlike previous talks, this was more of an “about the health check” and less of a “how to”. (For more of a how to, check out the IA Summit UXHC presentation Livia Labate and I did.)

I uploaded today’s Health Check slides to Slideshare and embedded them below for convenience.

The User Experience Health Check

As always, if you have any questions, please let me know. I’d be happy to help you implement the health check—in part, or in full—at your organization.

UX Research & Web Analytics: X-Ray Insights

Austin Govella — Tue, 15 Feb 2011 12:17:00 GMT

Do you want your website to meet both your business goals and your users’ needs? Understanding what people do on your site gives you the x-ray insight crucial to effective business decisions.

Fred Beecher was kind enough to invite Lou Rosenfeld and I to present a workshop talk at this year’s South by Southwest Interactive. We’ll provide a practical framework for squaring quantitative evidence and qualitative insights, and we’ll see concrete examples from search log and click path analysis. We’ll also learn how you can continually measure the quality of a site’s user experience.

The talk, “UX Research & Web Analytics: X-Ray Insights”, runs Sunday, March 13 at 11:00 AM. (From the talk’s page, you can add it to your personal SXSW schedule.)

In my part of the talk, I’ll introduce the UX Health Check and show how you can measure the user experience when you don’t have analytics to analyze. And, I’ll also use click-path analysis to show how you can use the Health Check alongside traditional analytics to measure continuous improvement in your designs.

Lou will be presenting on finding user insights in your search logs, previewing material from his forthcoming book on search analytics.

Agile+UX: Your process should be healthy, not lean

Austin Govella — Mon, 14 Feb 2011 11:27:00 GMT

UX should be healthy, not lean. View larger versions of the deliverables on Flickr.

There’s a dangerous, anti-deliverable meme lurking about that damages good teams.

First, it removes the need for engineers and managers to think critically about what problems they need to address, and what methods they should use to address them. Second, it suggests user experience professionals are not as capable as other professionals on the team to make decisions about what work needs to be done, at what fidelity, and with whom.

That irks me. It’s a quick fix more useful for lazy teams than for lean start-ups.

I’ve put together a collection of deliverables on Flickr that help identify, clarify, or evaluate important problems and opportunities facing organizations. These deliverables were good. They took time. And they’re demonstrative of how “deliverables” add value to the _organization_ ,help create _better products_, and help _improve how teams think_.

Deliverables are not the problem. User experience practitioners are not in the deliverables business. We’re in the business of finding and evaluating problems and solutions.

Site Architecture Stencil for OmniGraffle

Austin Govella — Tue, 19 Oct 2010 19:01:38 GMT

View a larger screenshot on Flickr.

I’ve used EightShapes’s brilliant Unify deliverable system for about four years. It’s excellent.

Out of the box, Unify is designed for use with Adobe InDesign. Lately, however, I’ve been site mapping in sweet, luscious OmniGraffle, and I created a Unify-inspired OmniGraffle stencil for making site maps.

But, there’s one problem with lots of site maps.

In your typical site map, you show the page’s title adjacent to the little box for that page. Unfortunately, clients and developers and designers don’t always what kind of page the page will be. In other words, if you have a page titled, “Orders”, it’s not clear if that’s a dashboard, a list of orders, or even a form form for adding an order.

So I added a line for every page on the site map where you can offer a _very_ brief description of the page.

If you’d like, feel free to download and use the site map stencil.

File Name	Version	Platform	Size	Download
Site Architecture.gstencil	0.6	OmniGraffle	138kb	Download

And if you have any ideas for making it better, please comment below, or —better yet—email me: austin.govella@gmail.com.

Take this social media study

Austin Govella — Tue, 07 Sep 2010 15:37:24 GMT

Javier Martin (@mantruc) has launched a study examining your use of social media tools like Facebook and Twitter and email and IM. Support a kindly researcher and take the survey. It’ll take about twenty minutes of your time, and you are eligible to win one of two $100 Amazon gift cards, but really, you should take it to help further our understanding of each other.

The survey is up onlne: “http://bit.ly/SMstudy”:http://bit.ly/SMstudy

Automated community moderation for reducing spam

Austin Govella — Mon, 30 Aug 2010 18:05:44 GMT

Some ways to improve online community moderation, and I wanted to get some feedback. But before we jump, three assumptions:

First, the community has a reputation system. This can be explicit as a reputation score visible in the interface. Or, implicit as a score you manage behind the scenes.

Second, you can assign members to levels. Specifically, I’m thinking of a “new user” who is defined as any member with a reputation score below 10 (where ten is an easy to reach number, but just beyond casual one- or two-time use).

Third, there are classes of users: free, watched, moderated, and banned.

Free – community members we trust to do anything community members are able to do
Watched – community members we feel need oversight after the fact
Moderated – members we don’t trust
Banned – people who have been ostracized from the community

(A lot to assume, but I’m not trying to theorize. I’m defining specific things in a specific system.)

(The names aren’t important. They’re just handles for conversation.)

Training wheels – New users (reputation below 10) are automatically “watched”. They can post, but their posts are automatically emailed to moderators so they can be managed. New members can join and participate, but moderators can catch spammers very early.

Time out – If a new user (reputation below 10) posts more than three comments in one day, switch them from “watched” to “moderated”. They can post, but posts are held, and they’re are told they’re moderated. Posts are emailed to moderators for approval. This stops massive spamming on weekends when mods aren’t paying attention.

Ministry of Truth – Content by banned members is immediately hidden. If there is child content by valid members, it’s hidden, too. If you have threaded conversations and you ban member A’s initial post, then responses by member’s B, C, and D are also hidden. This removes flames, trolls, and whining from your communities history.

Speed trap – If any member posts content with more than two links (or some appropriate threshold), graduate them one “class”: from free to watched, from watched to moderated, or from moderated to banned. This lets the system catch spammers if they manage to hack the accounts of trusted community members.

Big kid’s table – Don’t count when new users (reputation below 10) boost another user’s reputation. This prevents spammers from creating fake accounts and boosting a shill’s reputation, so they move out of watched status. (New users should still be allowed to accrue their own reputation through behavior on the site.)

These would all be in addition to your normal tools for marking spam and abuse, and this assumes you have a system with “moderator-useful touch points”; especially good notification emails. The emails should include links to move members up or down classes (free, watched, moderated, banned), as well as to approve, hide, or delete content. And a way to message the member. Maybe the new user is really excited and posted ten good comments with fifteen useful links in each.

Any feedback on how to vet new users, limit abuse, and automate some of the moderation would be awesome.

Concept is to baby as execution is to bathwater

Austin Govella — Mon, 30 Aug 2010 15:27:11 GMT

Li Ming Hsing’s design for a crosswalk sign illustrates the gulf between concepts and execution.

The designer explores two important concepts. First is the idea of communicating states and their duration. Not very sexy, but critical. The second, capturing, or recycling, waiting time.

I enjoy the solutions the designers used to explore the two core concepts. But if you threw this design into the “sweatbox”, I’d have no problem imagining the client killing design for being too whimsical for a crosswalk. However, the two core concepts are still really good. Making sure you anchor discussions on the goals and the concepts you are using to fulfill them will help ensure good concepts aren’t thrown out just because the execution isn’t approved.

Design is your strategy

Austin Govella — Mon, 30 Aug 2010 14:56:22 GMT

Great presentation about how strategy is about convincing yourself you know enough to to act and test your strategy. That’s what design is.

(The Medecci Group’s Frans Johansson at the 99% conference.)

Agile+UX - remembering what a team's sposed to be

Austin Govella — Wed, 19 May 2010 01:35:49 GMT

The inimitable Dan Brown passed along an email from a friend of his:

At my current job, we have an on staff UI/UX person and since we adopted Scrum across our entire team about two months ago, she has been struggling… I fear our UX person has basically just stopped participating in team activities to everyone’s detriment… I’d appreciate any thoughts on how I might help her re-engage and figure out how she might adjust her work to fit in better with an agile process.

Some sad Scrum master

My Life as a Panther

I was a Boy Scout when I was younger, and in Boy Scouts, groups of 5-10 boys are organized into units called _patrols_. And everyone in the patrol is about the same age, so it ends up being a peer group. Every patrol has a Patrol Leader and an Assistant Patrol Leader who are tasked with managing 5-10 rowdy boys who spend a lot of time playing with knives and lighting fires. It’s a good time.

Once, when I was a Patrol Leader of the Panthers, I had this one kid named Nathan who was more of a recreational scout. You know: there for the camping, axe throwing, and co-ed activities with girls from Explorer Troops. Now, in Boy Scouts, whenever you go on a camping trip there’s a set of chores the patrol has to do. Someone has to cook. Someone has to do the dishes. Someone has to dispose of the trash. Someone has to collect firewood.

There’s no use arguing about it. Those chores have to get done, so you make up a chart with the boys names down the left side and the chores across the top and you put X’s next to boy’s name when it’s their turn to do that chore. And you rotate through so everyone does every chore in turn. It’s a fair system.

Except for Nathan. He wasn’t into any of it. Especially dishes. Whenever it came time for him to do the dishes, without fail, I’d have to go help just to make sure he did some of them. I helped because it was my job as the Patrol Leader. If the team chore didn’t get done, the team didn’t eat, or didn’t have a fire, or would have to fight off bears in the middle of the night. When Nathan failed, the team failed.

The bullshit behind agile+UX

There are a lot of agile teams where we like to say “the UX person has been struggling”. We talk about culture clashes, misunderstandings, wagile, sprint 0, and scrums. And there’s often a good bit of derision and disrespect that drips from the engineering community about UX, in general.

I would like to take this opportunity to call bullshit on UX not integrating with agile.

BULLSHIT

Agile is built around teams. Your UX person isn’t struggling, your team is struggling. If one person fails, the entire team has failed. Your burn downs, WIP charts, bug triaging, and velocity mean fuck all if any member of your team from any discipline “is struggling”.

What you really should be saying is “my team is struggling with UX and not one person in a room of engineers can do anything to help her out”. Really? No one can help her? Is the asshole quotient so high, that she’s actually stopped participating?

Working as a team

Team’s aren’t rocket science. Differences in the way designers and engineers think are important, but they’re not stopping you from succeeding. It’s not the difference in process. It’s not different goals. It’s not the length of the sprint. When you phrase the problem as a team problem, and not a UX problem, it’s obvious how you can better integrate UX.

Do you need wireframes but not have them? Then help your team member with the wireframes. Do they say you need personas, but not have any, then learn how to make personas. Do they say you need to do some testing, then help them do some testing. Do you not understand why you need wireframes or site maps or personas or testing? Then learn about wireframes, site maps, personas, and testing. Does an engineer who takes time out of their sprint to help a team member then complete less code? Yes.

But there’s no use arguing about it. Those chores have to get done. Your team member said they needed to get done. The same team member that never questions when you say a chore needs to be done, has said a chore needs to be done. If the chores don’t get done, the team fails. Not one person. Not one discipline. The whole, entire team. If you release something with shitty UX, it wasn’t UX’s fault. The Team Released Something Shitty.

The fact is, a lot of engineers on a lot of teams are Nathan’s. They’d rather light fires and throw axes and chase Explorer Scouts. But someone’s got to do the dishes. And whether you like it or not, UX is the dishes, and you’ve got to get it done.

Next time you think your team has an individual problem, rephrase it as a team problem and see how _the team_ can make sure all of the chores are done. If UX isn’t integrating well, I’m willing to bet the few UXers are less likely to be the culprits than the many engineers. Just playing the odds…

Information Architecture: Blueprints for the Web, 2nd ed.

Austin Govella — Tue, 18 May 2010 23:07:57 GMT

Steve Krug’s Don’t Make Me Think is the one, best book that teaches you to how to think about your users, and it always will be. If you’re going to buy one and only one book, that would be the one.

However, if you’re looking for the best introduction to user experience, Information Architecture: Blueprints for the Web is the book you should buy.

h2. A comprehensive introduction

In Blueprints, we collected the key user experience issues and wrote an introduction to each. To that extent, I believe we’ve published the single, best, one-chapter introductions to business and user requirements, navigation, application flow, page layout, and search.

We’ve also included the single best introduction to social media design you’ll find anywhere.

You’ll learn how to approach each of these issues and how to best use personas, scenarios, site maps, wireframes, card sorts, and the ever-popular sitepath diagramming.

This isn’t a book about design. It’s about the architecture behind the design. We take you from concepts, requirements, and needs all the way down to laying out the page and stop just short of individual page elements. This is the book to read if you’re a product manager, engineer, visual designer, or student looking for a quick on-ramp into the world of user experience.

h2. Learn the way you learn best

As book-lovers, Christina and I wrote a book that would be both easy and a pleasure to read, warm, and inviting. It’s obsessively crafted for reading and for readers; every point illustrated with clear examples.

It’s a quick read at approximately 250 pages, but almost half of the book consists of full-color screenshots and diagrams. We were obsessed with including visual examples for everything so you can see the concepts while you read them.

h2. Not the first edition

It’s not the 1st edition. Not even close.

The chapters on search, navigation, application flow, and social media are completely new. The rest of the chapters has been totally revamped, rethought, and re-explained with new examples from the modern world. (And several chapters from the first edition were cut entirely.)

I’m really proud of the book we put together. So proud, that I never feel smarmy when I recommend it to people. If you’re looking for an introduction to user experience, I heartily suggest you check out Information Architecture: Blueprints for the Web.

Internet piracy

Austin Govella — Fri, 14 Aug 2009 07:10:07 GMT

Aiden, age 2 and 5/6ths.

He loves pirates more than he loves ice cream or puppies.

(More) tips for writing well

Austin Govella — Wed, 08 Jul 2009 19:16:27 GMT

As an editor, I’ve noticed several ~~recurring bad habits you heathens would do well to disabuse yourselves of immediately.~~

~~Almost without exception, these bad habits instantiate themselves as a series of stock~~ phrases and constructions that reflect a lack of focus, a lack of fully developed argument, or the kind of intellectual laziness that sets in as you slog through your first draft.

These things happen, ~~That’s ok. Editing helps you save yourselves from these offenses before your thoughts hit the world and everyone knows your dirty secrets.~~ but you can edit yourself, and you should. Use the following ~~checklist as a~~ guide to tighten~~ing up~~ both your words ~~as well as~~ and what you mean.

16 things to check when you edit

Be vicious when you edit. Vicious. Follow these recommendations with zealous fervor. They help your writing say what it should in a way we’ll understand.

1. I think, I’d say, im my opinion, what I’ve found, in my experience… Yeah. We know. You wrote this. These are your thoughts. If they’re not, provide a reference. If they’re yours, the byline is enough to remind us.

2. Delete all adverbs and adjectives unless they’re absolutely, totally, inherently necessary. Each unnecessary word weakens your impact and clarity.

3. Remove prepositional phrases. Prepositional phrases are less important than your main point. If it’s not important enough to deserve its own sentence, it’s not important enough to read.

4. Active not passive. Kill “to be” verbs. All of them. Always.

5. Kill -ing words. Restructure your sentence so the -ing is an active verb.

6. Lead with the bottom line up front: BLUF. Then include an example, re-state the bottom line, include an illustration, and when you end restate the bottom line. For every point you make, follow this pattern. That’s bottom line, example, bottom line, another example, and then the bottom line (again).

7. Telegraph and signpost what you will say and why we care. We’re not reading mystery novels. We want to know who died, how, who killed them, and why we care up front. That way, we know why we want to read before we begin.

8. Use clear, informative headers. Cute or artsy might be pleasant on the first read, but when we reference it later, the cute header makes it a pain to find things. What you’re writing is worth going back to, right?

9. Introduce new terminology in the intro. If you’ve created a new term or applied a new phrase to describe something, define it at the beginning, and use the new terminology throughout your writing. Readers need the entirety of your piece to learn and assimilate the new phrasing.

10. Typically, sometimes, often times, usually… Yeah. We know. You don’t have to tell us.

11. Say “you” and “your”. Don’t use nouns when talking about your audience (like “User Experience Practitioners”). And don’t use “one”. Speak to us.

12. Ditch clunky words. Instead of “via”, write “using”. Instead of “upon”, say “on”.

13. Remove cliches and common phrases. Every time you take a common phrase shortcut, you’re telling us it’s not worth our time.

14. Use contractions. Write with proper grammar, and people will read. Write like you talk, and people will listen.

15. No pronouns. Repeat the noun over and over again. If you get tired of that, use synonyms.

16. Delete your best lines. We don’t care about poetry, wit, or slyness. We care about what you want to say.

After you edit…

The finished piece should be so tight, terse, concise, and clear that it’s boring.

Boring.

Then sand off the rough edges.

Write like you talk. Where the concise feels awkward, add conversational. Where tight lacks nuance, tease details. Where terse is cold, be warm.

The first 16 recommendations remove fluff and force you to think and communicate. Once you’ve finished editing’s intellectual work, go back and make sure you write like you talk. Writing begins a conversation. If we feel like you’re talking to us, we’ll listen.