Editor’s Note: Tracking down Troy Parke (Big Fish Games) and Patrick Neeman (usabilitycounts.com) can be a bit like hunting unicorns. Al Martine caught up with the two as they prepare for their LavaCon 2014 session on UX for Content Strategists and Technical Writers.
Please tell us a little bit about yourselves? From which part of the content world do you come – content strategy, marketing, technical writing, other…
Patrick: I don’t come the content world. I’ve worked in design and user experience in some form for the last 19 years. Previous to that, I worked in print design, working at both small agencies and at a magazine company for a short time as an Art Director. I do have experience in content as both the editor of a community newspaper in Garden Grove, California, and wrote all kinds of reviews for music albums and books.
Troy: I grew up thinking I would be an Architect – combining form and function. I ended up being a consulting Civil (Geotechnical) Engineer. I always had a passion for how something looks and works. That path brought me to Graphic Design, then Interactive Design and now User Experience. I have worked with Writers, Marketers and am looking forward in my current role of working with a team of Copywriters and Content Strategists.
How do you define user experience? What is it not?
Patrick: UX is defined pretty broadly. The definition I point people to is the Nielsen Norman take on it: “User experience encompasses all aspects of the end-user’s interaction with the company, its services, and its products.” It can mean a lot of things to many people. For example, I met a chief experience officer that defined it as the experience developers had when dealing with his company’s products, so that meant easy use of APIs. That’s much different than the type of user experience work I do day in and day out.
Troy: The truth is UX Designers ask this of themselves and each other all the time. Ask 10 UX Designers this question and you will get 11 answers. For some people and organizations, UX is simply synonymous with the output: wireframes or flow diagrams for example. User Experience to me is simple solutions to complex problems. This is first seen in the presentation layer of a product or service – such as the content and visual design. The real experience is “under the hood” – reducing the complexity of a check-out flow from 8 steps to 3. This requires a partnership across design, content, engineering and product/business.
In your LavaCon session summary, UX is mentioned as a skillset – what is the UX skill set?
Patrick: Everyone has a different take on it, but the six “boxes” I consider user experience to be Interaction Design, Visual Design, Content Strategy, Information Architecture, User Research and Analytics, and Front End Development. Each requires vastly different skills, so most UX professionals can do at most three well. If you get someone that has four or five, we call that a Unicorn. Many are mistaken when they think UX and Visual Design are different — Visual Design is actually part of UX. Same with content. Content Strategy is part of UX, and there are some Information Architects that consider Content Strategy their realm. There’s a lot of overlap in the skill sets, but they all have to work together for a great user experience.
Troy: I agree with Patrick’s and Nick Finck’s models of UX being a multi-faceted skillset. As UX Designers, we talk about the “T-shape” a great deal. The T-Shape is starting with deep domain knowledge in one aspect while growing outward to acquire more experience in the other “boxes”. This is how you start your career and grow towards becoming a Unicorn. Experiences are like great movies: the script, acting, direction, score and cinematography coming together in concert. If you look at job descriptions for UX Designers, you will see this desire to encompass all the “boxes”. In my experience, organizations are looking to cover all these aspects as a team. Some on the team will have strength in Content Strategy, others will have a core competency in Visual Design.
Much of technical writing work involves business analysis. Why do you think managers so often leave technical writers out of the upstream work?
Patrick: I think that’s because it’s just the way it’s always been. It was up to developers and product managers to define the product, and then someone to document the process when it’s done. I think many technical writers are also uncomfortable being involved earlier. Getting involved earlier, especially with the process of User Experience, is very uncomfortable for many. The technical writing role was a “back of the bus” process and documentation is rarely reviewed. When you get involved in User Experience, you are on stage, all the time and that’s scary because products can succeed or fail on your contribution. Many people don’t like that, but that’s the job.
Technical writing is seen as a necessary evil and many companies, like Microsoft and Amazon, see it as a cost center to be outsourced to other countries.
Companies like Apple “get it” and involve content strategists early on because they see it as a key to user adoption and consequently sales. Those that get Customer Experience and Service Design understand it’s the voice and tone of all copy that drive it.
Because technical writers haven’t taken a more active role in demonstrating their value other than producing reams of documentation, they are now in a very difficult situation of seeing their role changing for the worse. They can stem that tide by tying the work they do to metrics that generate revenue or a better user experience (for example, less calls to customer support), and if they do that the tide will reverse. That’s the only way they’ll survive and grow — change the purpose of their role to a true contributor of a great user experience instead of a necessary evil.
Troy: What Patrick said. ^_^
The upstream is constantly in flux, decisions made, unmade and then redone again. Being “on stage all the time” means not only constantly defending decisions, but thinking two, three and more moves ahead of political, business and technical issues. I like remind folks that creation is a messy business.
The more downstream you are in a process, more you will feel the pinch – whether it is technical writing, development or Quality Assurance (QA). Many of the philosophical arguments have been made already and it becomes difficult go back on promises, re-open past discussions or even take the time to explain all the ins and outs of how we ended up here.
How can content strategists and technical writers build their company reputations to gain a place in the product development lifecycle?
Patrick: Get involved early in the product definition and design process. Instead of saying, “I have to write a lot of documentation because the product is so hard,” ask who the users are and how we can make the product easier. That really means redefining a lot of metrics at a higher level. For example, instead of defining success as how many pages were written, the metric should be how few pages are written. Other metrics that are used for customer success are if the user has to contact customer support, it’s a fail, and measuring the speed of user tasks.
Troy: One of the best ways I have seen to shift from a production and output mindset to being engaged at a strategic and upfront level is focusing on the question and not the answer. I love the Chip Kidd quote “The best solution is found in the best definition of the problem.” I feel this applies to writing a headline, designing a flow or developing a taxonomy. Before firing out options and answers, take the time to ask the right questions. What is the exact issue that our users are experiencing today? What is the particular business metric we are looking to optimize for or not negatively impact? What does success look like? Stay in problem space, not solution space.
Fixing things in the design phase is always cheaper than needing to correct it after production. How can you estimate the cost reduction when this occurs?
Patrick: One of the basic metrics I’ve seen is the 1-10-100 rule, to fix something, it’s $1 in design, $10 in development, and $100 in production. This seems pretty consistent from what I experience in software design.
Troy: Fixing things early on is cheaper for everyone – design, copy, content, development, etc. In making these arguments, you need the foresight to recognize every role on a project is asking for the same thing.
Business owners will often look at situations from “paying the tax” before or after. The problem is not only quantifying the cost increases, but the missed opportunity of making a good first impression. In addition to a cost savings perspective, frame the benefit of an approach as a competitive advantage or basic expectation making a sale with the customer.
What three tips would you give technical writers / content strategists to help them with UX and their work?
Patrick:
- Take areas of the software they are working on and practice writing contextual help that would remove long form documentation.
- Partner with UX Designers and Product Managers to get involved earlier in the process to help rethink what they are doing.
- Learn other skills like User Research and Information Architecture so they better understand how they can help out.
Troy:
- Start a journal of everyday experiences that are less than optimal and sketch or write out narratives that frame the problem and then solve it differently.
- Practice whiteboarding with partners. It is the language of business models, technical architecture exploration and UX brainstorming.
- Talk to UX Designers, see how they approach things in their role or organization and what pearls of wisdom you can try in your own.
When you’re not answering questions for TechWhirl and preparing for LavaCon 2014 – how do you stay busy?
Patrick: I run a blog (www.usabilitycounts.com), have the day job, and keep the UX Drinking Game going (www.uxdrinkinggame.com).
Troy: I have the distinct pleasure of being a part of a new adventure at Disney and helping grow a design team focused on the Guest. I also try to keep up on my blog UX How http://uxhow.com/ and daily UX notes of interest on Twitter: https://twitter.com/UXHow.
