It’s All About AI. The Data Told Me So.

AIA conversation with a (junior) colleague this morning started off with “How did you decide to reformat your Best Practices Guide?” and moved on to things like “But how did you know that you should be working in Artificial Intelligence and VUI for this search stuff? I mean, how do you know it will work?”

I couldn’t help but chuckle to myself.

“Rest assured,” I said. “Part of it is just that you know what you know.  Watch your customers. Rely on your gut. But more importantly, trust the data.” The response was something of a blank stare, which was telling.

All too often, tech writers – software writers especially it seems, although I do not have the requisite studies to support that claim – are too steeped in their actual products to reach out and engage in customer usage data, to mine engagement models and determine what their users want when it comes to their doc. They are focused on things, albeit important things, like grammar, standards, style guides, and so on. This leaves little time for customer engagement, so that falls to the bottom of the “to-do” list until an NPS score shows up and that score is abysmal. By that time, if the documentation set is large (like mine) it’s time for triage. But can the doc be saved? Maybe, maybe not.

If you’re lucky like I am, you work for a company that practices Agile or SAFe and you write doc in an environment that doesn’t shunt you to the end of the development line, so you can take a crack at fixing what’s broken. (If you don’t work for a rainbow-in-the-clouds company like mine, I suggest you dust off your resume and find one. They are super fun! But, I digress.)

Back to the colleague-conversation. Here’s how I knew to reformat the BP Guide that prompted the morning conversation:

I am working toward making all of my documentation consistent through the use of templating and accompanying videos. Why? Research.

toiletAccording to Forrester, 79% of customers would rather use self-service documentation than a human-assisted support channel. According to an Aspect CX survey, 33% said they would rather “clean a toilet” than wait for Support. Seriously? Clean a toilet? That means I need to have some very user-friendly, easily accessible documentation that is clear, concise, and usable. My customers do NOT want to head over to support. It makes them angry. It’s squicky. They have very strong feelings about making support calls. I am not going to send my customers to support. The Acquity group says that 72% of customers buy only from vendors that can find product (support and documentation) content online. I want my customers’ experience to be smooth and easy. Super slick.

In retail sales, we already know that the day your product is offered on Amazon is the day you are no longer relevant in the traditional market so it’s a good thing that my company sells software by subscription and not washers and dryers. Companies that do not offer subscription models or create a top-notch customer experience cease to be relevant in a very short span of time thanks to thanks to changing interfaces.

Image result for artificial intelligence

I’m working to make the current customer support channel a fully automatable target. Why? It is low-risk, high-reward, and the right technology can automate the customer support representative out of a job. That’s not cruel or awful; it’s exciting, and it opens new opportunities. Think about the channels for new positions, new functions that support engineers. If the people who used to take support cal

 

ls instead now focus on designing smart user decision trees based on context and process tasks as contextual language designers, it’s a win. If former support analysts are in new roles as Voice of the Customer (VoC) Analysts, think about the huge gains in customer insights because they have the distinct ability to make deep analyses into our most valuable business questions rather than tackling mundane how-to questions and daily fixes that are instead handled by the deep learning of a smart VUI. It’s not magic; it’s today. These two new job titles are just two of the AI-based fields that are conjured by Joe McKendrick in a recent Forbes article so I am not alone in this thinking by far.

His research thinking aligns with mine. And Gartner predicts that by 2020, AI will create more jobs than it eliminates.

So as I nest these Best Practices guides, as I create more integrated documentation, as I rely on both my gut and my data, I know where my documentation is headed, because I rely on data. I look to what my customers tell me. I dive into charts and graphs and points on scales. The information is there, and AI will tell me more than I ever dreamed of…if I listen closely and follow the learning path.

Neural-Network-640x360

 

 

 

Refiguring The Primary Measure of Progress

pencilIn Agile Software Development,

“working software is the primary measure of progress” and the manifesto values “working software over comprehensive documentation.”  That is all well and good, but as a writer, I often pause on that one word – comprehensive. I take a moment there and wonder who determines what comprehensive means, and whether sometimes we leave the customer, and the customer’s needs, in the dust when we use that word.

instructions2

Before every developer everywhere has a head explosion, I think we can all agree that expansive documentation is silly and frivolous. So maybe I would swap out comprehensive for expansive. Perhaps I’d have chosen “frivolous documentation,” or “needless documentation.” I’m just not sure I would have chosen the word comprehensive. I get what the manifesto is going for. I do. I want to create lean, usable doc every time. I don’t want to give more than is needed. I want to respond to change fast. My goal is accurate, deliverable doc that addresses stakeholder needs. I suppose I would like to think that, by definition then, my doc is complete, or…comprehensive…in that it includes everything a customer needs. But I agree that I don’t want it to include anything more. I just want to avoid coming up short.

What if I rewrote the twelve principles from a doc-centric focus? Would they work just as well?

  1. My highest priority is to satisfy the customer through early and continuous delivery of valuable documentation.
  2. Welcome changing requirements, even late in documentation. Agile processes harness edits for the customer’s competitive advantage.
  3. Deliver accurate documentation frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
  4. Business people, developers, and writers must work together daily throughout the project.
  5. Write documentation around motivated individuals. Give them the environment and support they need and trust them to get the doc written.
  6. The most efficient and effective method of conveying information to and within a writing team is face-to-face conversation.
  7. Clear, concise documentation is the primary measure of progress.
  8. Agile processes promote sustainable writing. All team members should be able to maintain a constant pace indefinitely.
  9. Continuous attention to linguistic excellence and good design enhances agility.
  10. Simplicity – the art of maximizing the amount of writing not done or words not written – is essential.
  11. The best architectures, sites, and manuals emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to create more effective doc and then adjusts accordingly.

Okay, so some of this is silly, and I just wasted twelve lines by playing it out all the way to the end, but it was for good reason. Continuous deployment can happen not just with techmanualdeveloping software, but in the embracing of documentation as part of that software, but instead it is often “kicked to the curb” by many teams as a misinterpretation of that one element of the original manifesto.

 

 

It’s not that documentation should be cast aside; it’s that comprehensive documentation is being misunderstood as frivolous or extraneous documentation.

I did not realize that this was a pernicious issue quite so much until I was giving a workshop to a small class of new developers from across my company, hailing from a variety of offices, and they looked at me funny when I described some of how my team does doc (we are pretty good at the whole agile thing, but sometimes we regress into “mini-waterfalls” and I hate them). One of the young devs was astonished that I manage to get my developers to hand over documentation early in the process so that I have it in a draft state, while the code is still being written, not after the code is all in place. It’s a struggle, I’ll admit, but when I this happens, the result is a joyous celebration of shared workload and well-written doc. We can collaborate, change, shift and learn. And the sprint goes more smoothly with only minor changes at the end, not a doc dump in week 4.

To teams who are not doing this: cut it out with the waterfall, guys. Doc is essential, and your users need it. Otherwise, they are calling support and costing your company thousands with every call. Change your practice and build your doc while you build your product.

You might be asking, “How can you possibly write the doc when you haven’t written the code?”

You are not the first person to ask this, trust me. The answer is pretty simple. A long, long time ago, you couldn’t. Or, at least it wasn’t wise to, because it was a redoubling of work. When writers put their stuff into pdfs or word documents, and then had to make major changes, it meant a bunch of editing and rewriting things. Therefore, developers got in the habit of writing all of the code, then examining the processes and hunkering down to crank out the doc. Fair enough. Now, though, we developed wiki spaces and collaborative tech writing tools that now allow inline editing and let developers look at the cool formatting and linking that tech writers have done with our work.

And – before the code even gets written, there is a design plan in place, and usually a design document to go with it. There are code specifications, right? You can have a nice chat with your friendly tech writer and go over this, either through a face-to-face (see Agile point #6) or via any of the vast number of other tools designed to communicate with your team. Before a developer starts coding, there is a project plan – share that plan. Once the general information has stabilized, it’s okay to let the writer have at it. The benefit is that the writer is having her way with the general plan while the developer is coding away. At the end of both work days, the writer and developer have each created something. In a typically short iteration, it is unlikely that the coding will change significantly, so the two can touch base frequently to mark changes (See Agile point #4).

Are there risks to this process? Of course, just like there are with waterfall. Remember that with waterfall, there were a fair amount of times that programming crept right up to the deadline and documentation was hastily delivered and could therefore be sloppy and lacking. And in this method, it is far easier to tell you about writing documentation continuously than it is to actually do it. It takes time, it takes effort, and it takes dedication – because the primary risk for doc is the same as it is for the software: that the customer’s need will change midstream. That problem was (more or less) solved by short iterations in development, and it is (more or less) solved the same way in documentation.mario

The benefit is this – by writing the doc alongside the development, you can be sure that you deliver the doc in sync with the product. You’ll never sent the product out the door with insufficient instruction, and you will never cost your company thousands of dollars in support calls because your customers don’t understand how the product works or how to migrate it. But deliver a product without comprehensive – yes, I’m back to that word – deliver it without a complete doc set, and you may regret it. Trial and error is okay if you want to see how fast Mario can get his Kart down the hill in order to beat Luigi and save the princess, but do you really want to rely on that when the client is a multi-million dollar bank?

I’ve been teaching writing and writing processes for a very long time, and believe me, the action of draft, revise, revise, revise is not new.

It’s just Agile.

 

#Ilooklikeatechwriter

 

International-Womens-DayI know I just posted yesterday, but I have had a working draft of this piece in the hopper for a while; it just never quite grew its feet, as I like to say. And I can’t put a piece on the blog until it has its own feet. But today, being Women’s Day and all, the piece found its feet.

I recalled Isis Anchalee – remember her? She’s the bright, talented, strong, and yes, beautiful platform engineer from the Tech Startup OneLogin who asked her to participate in their ad campaign, which then sparked the #ilooklikeanengineer hashtag movement. It didn’t take long for the misogynists among us to determine that Isis was simply too pretty to be a “real” platform engineer. There’s just no way a smart brain could be housed in that attractive body.

The movement caught on fast, but it has faded just as quickly. It’s not enough to repeatedly have lists like Forbes top 30 women under 30, although that’s a great list. I say it’s not enough, because when a company like Microsoft reveals its diversity numbers to reflect the staggeringly awful truth: over 75% male and 60% white, with an only 29% female workforce globally, that’s alarming. And then comes the real hit: only 12.5% of Microsoft’s senior leadership in America is female. (Source: Forbes). This is happening even though we know that women are generally better at coding tasks than men.

But we also have to reveal the truth that, according to the US Department of Labor, only 12% of Computer Science graduates today are women.

Why? What about this environment is blocking women? Are we really just not cut out for this field?

ways-to-celebrate-international-womens-day-online

Not really. According to Gayle Laakman McDowell, author of Cracking the Interview, and a coder herself, it’s primarily that girls, when they are girls, are mostly sent the message that, “hey, this stuff is not for you.” Subtly or overtly, young women are, from a very young age, steered toward the humanities while young men are steered toward hard sciences. (We’ve known this for a long time, but I’m providing ethos here. I’m a writer, so to show you I have backup, I provide a subject-matter-expert, okay?)

So we tell girls and young women that they just don’t look like coders. They look like teachers, they look like nurses, they look like bank tellers or whatever, but they do not look like they fit in the cubicle-hive style pressure system that is software development or platform engineering. Is that it?

In other areas of their lives, we are telling them to be “totally natural,” or to be proud of what they look like. We tell them to embrace their body types and to live their lives with gusto. Kate Winslett recently signed a modeling deal with L’Oreal that has a “no Photoshop” clause, and we applaud this honesty and truth to herself.

But we haven’t told young girls that if their true beauty is in writing code, that they are totally entitled to that gorgeousness?

The percentage of women who work in tech companies remains consistent, at around 30%. So there ARE women who do this stuff, but it’s stagnant. It is failing to grow. Even though more women go to college, and an even greater number of women attain graduate degrees, the percentage stays flat. Now, what I find truly remarkable is that the percentage of women in technical or leadership roles – roles where they can actually influence the direction the company takes, is even lower. This difficulty may be the result of well-known sexism in the technology sector, or at least an unwillingness to combat it. The New York Times ran a great piece in April of 2014 called “Technology’s Man Problem,” documenting just this trend, and not much has changed in the last two years, but some things have.

It is not just a matter of moving more girls into a pipeline of studying STEM, because the high rate of attrition in tech moves them right on out the door just as quickly. Teaching women and girls that the tech field is appealing, lucrative, and open to them is not the quick fix we hoped it would be. Instead, fixing the culture that says, “you don’t look like an engineer, coder, tech writer…” THAT is the solution, or at least part of it. In the UK, a campaign called “This Girl Can” strives to connect young women through physical activity and inspiration, while here in the US, Target recently launched an ad campaign called Target Loves Every Body.

I believe we need a culture shift that defines, or redefines, the landscape to show that coders look like lots of things, and writers look like lots of things. Women in many careers have been trying to reshape their images from Hollywood to magazine covers, so why not in Silicon Valley, too?

Women helping women is the key to confidence and the key to success. If tech culture is going to change, everyone needs to change. The emotional and professional cost is simply too high not to. So on this, Women’s Day, the challenge is to reach out to a woman in your field – or a woman not yet in your field – and mentor or inspire, encourage or reassure her. That is how it gets done. Make a pledge to yourself that you will make room in tech for one more young woman, or that you will make additional room for one more established woman. It’s a jungle in here. Even women who have worked in here for years can get lost in the tangle of tasks, so have lunch this week, next, and next month too. There is networking to be done, and we could all use it. Today does not need to be the only Woman’s Day you have this year. Let the women in your life, especially in your tech life, know that they LOOK like accomplishers, achievers, builders, and leaders.

And then, if you are a woman, make sure you accomplish, achieve, build, and lead.

iwd-women

Want The Very Best in UX? Hire a Writer

Saying that all technical systems, website creation teams, and indeed software development companies can benefit from a User Experience Designer is like saying that all human bodies can benefit from water. It’s a simple assertion. We all know it, and yet some development groups assume that they know what is best for their customers, or worse yet, they assume their customers know what they want.
What they (the companies, not the customers) do not realize is that the easiest way to enhance the user experience is to hire a good writer. UX design encompasses art, yes, but it must essentially encompass understanding. This seems intuitive, and yet when we look to engage a User Experience professional we do not always assume that he or she is a talented writer.
How do I know this? Well, I used to teach within a professional seminar for the MA in Human-Computer Interaction at a highly-respected university where they were grooming tomorrow’s User Interaction Designers before I took this primo job writing amazing documentation for this crazy-talented company cranking out top-notch software. Surprisingly, though, when I landed here, we did not have a UX guru on our team. I was a bit taken aback that we didn’t have someone like that on the job, but I figured I was new, so I didn’t make waves. Besides, I knew all on my own that really, if there is no art involved, you don’t need interactiondesign, you need interaction writing. So UX talent is not required – a trusted relationship with your writing team is.
I’m not saying that a writer can replace a designer – that’s just bad math. A company that wants to succeed in designing good software, web interface, and more, needs to hire the people who have expertise in software development and web design. After all, writers can’t develop code! But what writers can do is parse the meanings of things. We have the highly developed talent for taking complex ideas of language and inference, metaphor and symbolism, and making meaning from them. And we can tell you when it just doesn’t work. And many of today’s writing programs require classes like Document Design, Communication Design, Visual Communication, and more – things that are akin to how users interact with the ways we are trying to reach them.

storytelling
Writers understand story. We tell stories. And in agile development, what do we call the very things that are on the table for development? Yes! Stories! In scrum meeting after scrum meeting, we task out stories for development, and the scrum master even relies on scenarios to help the team imagine how those jobs will be completed. It is proven in release after release that picturing how a certain element of the product will be used, valued, and consumed by the customer or end-user is a useful tool to the development team. Storytelling allows agile methodology to work, from start to finish. Good writers understand tension and pain, so writing a story or scenario helps to flesh out the documentation that will guide users through installation and troubleshooting. Writers are instrumental in sensing where and when the struggle points will hit for the team long before the software is released for general audiences.
Writers “get” emotion. We deal with it all the time in storytelling. Put a writer in the room in every scrum meeting and just watch how a talented one can help diffuse tense moments over hours invested in an idea that didn’t pan out. It isn’t foolproof, but a writer is also a good catalyst for humor, empathy, kindness and redirection in the heat of the moment. Many writers have a genuine interest in the investment of people, and writers can often help find a silver lining – if there is one to be found – and can redirect the energy. The User Experience is not always found on the outside of the room. Part of the experience is getting the product out the door without trauma.

traumaThe common argument against having a UX person on the team is cost, so often companies toss out the notion as a line-item veto in budget discussions. If there is a place for everyone at the table, that is fantastic, but in the current economy, often we are asked to develop multiple, portable talents. Those who can carry talents across the table are asked to do so. And they should.
The next time you are wondering how your customer might perceive something, I’d ask you to look across the table at your gifted technical writer, your talented copy editor, your incredible documentation specialist, and say, “How does this read to you? What do you think our customers will say? How does this look? What story does it tell?”
You might just be pleased with the answer. You may have found a user…with experience.