Last updated on Sep 22, 2022
David Connis, UX/Technical writer at Skuid joins us in this episode of Knowledgebase Ninja and shares his experience and passion towards documentation and UX writing. Check out all the other episodes of Knowledgebase Ninjas.
Connect with David and view Skuid here:
David’s documentation journey
David started his journey into documentation as a freelancer which included: writing, editing, copywriting, and technical writing services. It’s been 9 years now, and David is accepting a variety of gigs for technical documentation to build up his portfolio.
He later joined a small startup that was trying to enable developers to work on open-source projects. He began to start writing knowledge-based articles that transformed into technical instructions, such as manuals for developers’ ease. At the time he was learning front end development, a friend of David recommended him to Skuid, where he currently adds value to technical and UX writing.
The difference between technical and UX writing
David defines both as similar in a lot of ways, however, a prominent difference was that a technical writer looks into in product text, features and what it does, whereas a UX writer has a unique way of writing, that has drastically developed since 2017. This is primarily concerned with In-app text, tooltips, label, properties, and onboarding flow charts. We basically investigate similar to journalists, we need to dig deeper, to see if a developer mentions something that we don’t understand, and then we ask questions. The scope and evolution of a UX writer is through having a design background, this helps the tech writers in developing more and more “Human-centric copies”, says David.
The extensive documentation process at Skuid
David’s team is spread out across various departments, they perform multiple writing and documentation tasks. For documenting a new feature, the team adopts a detail-oriented process flow of getting in touch with the designers, developers, and engineers, asking tons of questions. This is to ensure clear functionality descriptions through several aspects.
David’s most important factors in documentation
According to David, the most important factor in documentation is clarity. when a document is clear and transparent a user is able to understand it easily. Content should consist of simple words mixed with a little bit of fanciness, which should describe challenging concepts in the most easiest and engaging manner. “Technical writing should not sound like an AI robot, but should be user friendly”, says David.
Another crucial factor in the documentation, as David mentions, is developing excellent customer relations teams. At Skuid, the customer relations team works effectively through conducting check-ins every week, which helps them cross-check and improvise on any information that may be required in the document.
How to measure ROI through document success?
Utilizing analytical tools is David’s go-to for measuring a documents’ success. Google Analytics allows you to gauge the hardest part which is the users’ touchpoints, you are unable to pinpoint the exact motives of the user to keep using your product. Giving people answers instead of more questions is the secret of retaining a user.
According to David, it is hard to say that these are easily measurable. However, the constant dig can get you there.
One piece of advice David would give to his 20-year-old self
It is more important to be clear and simple. Simplicity is elegant, don’t write fancy and sophisticated words that seem cool to you.
Who has inspired David in the documentation:
David said that WriteTheDoc’s has been a big influence on his career. A lot of people have mentioned them because they are infamously known for their community and knowledge.