Skip to content

Commit 49e2e6c

Browse files
Merge pull request #27 from alphagov/claireashworth-patch-1
Update content on tech writing
2 parents f7887ef + 791482a commit 49e2e6c

File tree

1 file changed

+27
-1
lines changed

1 file changed

+27
-1
lines changed

source/technical-writing/index.html.md.erb

Lines changed: 27 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,4 +3,30 @@ title: Technical writing
33
weight: 13
44
---
55

6-
# Technical writing
6+
# Technical writing
7+
8+
Technical writers create guidance and documentation to help government technologists making technology decisions. They break down complex technical concepts into clear language. The technical documentation we produce describes how a product or service operates.
9+
10+
## The ways we work
11+
12+
Tech writers at GDS use Docs as code to write and manage content. By applying a software development approach to the accompanying documentation, we can maintain consistency and updates.
13+
14+
You can read more about why we use this approach in [the blog post published on the Technology in Government blog](https://technology.blog.gov.uk/2017/08/25/why-we-use-a-docs-as-code-approach-for-technical-documentation/).
15+
16+
We also:
17+
18+
- undertake research either with the User Researcher or, in a more simplistic way, independently to discover the need for the documentation and what users need
19+
- manage existing content to make sure it remains accurate and relevant for the users
20+
- use pair writing with the subject matter expert to form a mutual understanding of the work and how content can best support it
21+
- use interviewing techniques to discover more about the work and the content requirements
22+
23+
## How tech writers define their skills and work
24+
25+
Based on conversations with the tech writer community we’ve found that tech writers:
26+
27+
- need to think about and understand concepts, topics and tools in the abstract
28+
- need to be comfortable with not knowing, but thinking abstractly to create their own understanding
29+
- happy to ask questions, sometimes repeatedly, until they feel the content is as clear as possible
30+
- make a positive contribution to product design and understand design problems
31+
- need clarity on who our users and stakeholders are for each piece of content
32+
- need to understand and use a wide range of tools

0 commit comments

Comments
 (0)