UX & Technical Writing Self-Assessment

JavaScript isn't enabled in your browser, so this file can't be opened. Enable and reload.

Benchmark your developer portal’s UX and technical writing against industry best practices with this comprehensive report, which includes a developer health score and key areas for improvement.

What to expect

Filling in the form takes only about 15 minutes. In 5 working days our team will get back to you with a report with the evaluation of your submission. We also provide insight on how our services can help you to elevate User Experience and Documentation quality on your portal.

You don’t have any obligations and the report is free of any charges.

Please share the link of your developer portal *

1. Generally speaking, what blockers might you be facing? *

The offerings and documentation are presented randomly on the developer portal. It is not clear what value they offer our users. There is no unified experience. We’re unsure how to address this.

We understand what value the developer portal provides to producers and consumers. Now we need to figure out how to implement those insights. We might face blockers, such as siloed teams, and a lack of specialists.

Most internal teams are on board and there is alignment on how to write documentation and on how to structure our offerings on the developer portal. Unfortunately, we haven’t achieved ROI. We’re unsure what’s wrong and what we can do about the problem.

Our developer portal has clear goals. Our use cases help users forward and reflect what we want to achieve as a business. The portal provides a unified experience. We might still want to discover how to move on from here to become even better.

Other:

2. How do your portal’s content and features address user needs? *

We do not yet tailor for any specific audience.

We have some content/functionality for different audiences, but coverage is incomplete.

We have basic tailoring in place, but for one audience group only (developers).

We have done some research, and the content is now mostly tailored to key audience groups.

We have fully tailored content for all identified audience groups, which we regularly update based on user feedback.

Other:

3. Do you collect feedback and keep on innovating accordingly? *

We do not collect user feedback on documentation or user experience.

Feedback is collected occasionally, but there is no structured process for reviewing or acting on it. While some analytics (for example, portal usage data, or user behaviour) are tracked, they are not systematically used to inform planning or drive improvements.

We collect feedback in a more structured way (for example, through surveys, feedback forms, or user interviews), but it’s not regularly analyzed or used to update content.

Feedback is consistently collected, analyzed, prioritized, and incorporated into documentation updates and design decisions. User input and analytics are collected systematically to make informed decisions and refine the vision and purpose of the portal. This way, we track the effectiveness of what's being offered and improve upon that.

Other:

4. Who is responsible for UX design and documentation writing? *

UX and documentation are not or inconsistently addressed, no-one is assigned owner.

There's no clear ownership for UX work and documentation writing, we solve it on demand (mainly developers).

Dedicated individuals are responsible for UX and documentation, but the roles and responsibilities are unclear or overlapping.

Roles and responsibilities are defined, with clear ownership for UX work and documentation writing across all teams.

Other:

5. Do you follow a documented editorial style guide and API documentation standards? *

There is no style guide or documentation standard.

A style guide exists but is not documented (for example, standards are followed based on a verbal agreement based on a "habit"), nor shared across the involved teams.

A style guide exists but is inconsistently applied (titles, capitalization, or tone vary).

A style guide and API documentation standard (like OpenAPI) are documented and mostly followed, with occasional deviations.

A style guide and API documentation standard are documented, shared, and strictly followed across all content.

Other:

6. Is there a clear workflow for creating, updating, and maintaining your documentation? *

There is no defined process for updating documentation.

Updates happen ad-hoc with no assigned owners or review steps.

Documentation is updated during product releases, but small changes (e.g., minor fixes) are missed.

A workflow exists (through reviews and approvals), but documentation updates sometimes lag behind product changes.

A clear, documented workflow ensures documentation is updated in sync with product changes, including both major and minor updates.

Other:

7. Does your documentation cover user onboarding, key request processes, and troubleshooting? *

Onboarding, key request processes, and troubleshooting sections do not exist.

Onboarding, key request process, or troubleshooting content exists but lacks step-by-step instructions.

Step-by-step instructions exist but are missing key examples.

Onboarding, key request processes, and troubleshooting sections have clear steps but are missing visuals, links, or common error explanations.

All onboarding, key request processes, and troubleshooting sections include clear steps, examples, visuals, links, and common error resolutions.

Other:

8. How would you describe the overall quality and usability of the API reference documentation across your portal? *

Documentation quality is inconsistent across our APIs; some have minimal descriptions, while others follow higher standards.

We have documentation guidelines, but adherence varies across teams. Some APIs lack descriptions, examples, or default values.

We have a well-defined documentation standard, and most teams follow it, ensuring consistent, high-quality API references.

Most APIs have well-structured reference documentation, but try-out functionality is not consistently available.

All APIs in our portfolio adhere to strict documentation standards, including descriptions, example requests/responses, default values, and an interactive try-out option.

Other:

9. Do your API docs and process guides include code examples, visuals, and tables? *

There are no code examples, visuals, or tables. Or if they exist, they are outdated.

Code examples exist but lack context, such as missing descriptions of their functionality.

Code examples are included but are inconsistent, such as being unavailable for all important processes.

Code examples and visuals exist for most processes, but complex data is conveyed using long text instead of tables.

Code examples, visuals, and tables are consistently used to simplify processes and improve understanding.

Other:

10. Are changelogs, release notes, and versioning well-documented and easy-to-use? *

There are no changelogs, release notes, or version history.

Changelogs or release notes exist but are incomplete or hard to locate.

Changelogs and release notes are provided but only for major updates.

Most updates are clearly documented and accessible, but version history is unclear.

All updates, including major and minor changes, are clearly documented, versioned, and easy to locate.

Other:

11. Is your documentation structured logically and easy to navigate? *

Content is unstructured and lacks headings or clear section titles.

Content has headings, but pages are long and not broken into short, scannable sections.

Content uses headings and sections, but titles are generic (e.g., "Overview") and do not clearly describe the content.

Pages are broken into clear sections with descriptive titles, but navigation between topics is unclear.

Documentation has short, scannable sections with descriptive titles, and navigation allows users to find content easily.

Other:

12. Does your documentation consider accessibility best practices? *

No accessibility features (e.g., alt text, readable link labels) are implemented.

Some visuals or links exist but lack alt text or descriptive labels.

Alt text is used, but visuals are decorative and don’t enhance understanding.

Most visuals have descriptive alt text, and links use meaningful labels instead of raw URLs.

All visuals and links follow accessibility best practices (e.g., descriptive alt text, clear link labels).

Other:

Anything else you would like to share?

Clear form

Never submit passwords through Google Forms.

This form was created inside of Pronovix.

Does this form look suspicious? Report

Forms