You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: source/technical-writing/index.html.md.erb
+27-1Lines changed: 27 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -3,4 +3,30 @@ title: Technical writing
3
3
weight: 13
4
4
---
5
5
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