I have recently been working as a content designer for the creation of a playbook. Brought in late, my first decision was to take a call on how to present the document.
And I had 24 hours to take that decision.
Firstly, in case you don’t know exactly what a playbook is, Accenture defines it as:
Playbook includes process workflows, standard operating procedures, and cultural values that shape a consistent response—the play.
A playbook reflects a plan; an approach or strategy defining predetermined responses worked out ahead of time.
If you would like to learn more about playbooks and what they comprise of, head over to Atlassian. In my personal opinion, they are the playbook kings!
Coming back to my project. The product is a solution for conducting remote examinations, which my organization is planning to sell to other educational institutions.
A multi-million dollar project, I was actually amazed at how late I was brought in to work on the playbook.
As for the playbook itself, the draft spanning 50+ pages had been created in Google Sheets. The expectation was to have the final version as a PDF document.
My initial thoughts
My very first thought was – for any user, it is going to be difficult navigating a 50+ page document.
And to add to that, the whole information in the document was very media dependent. That is, there were a lot of web-links connecting to external content – videos, excel sheets, web pages, MS Project files, etc.
Thinking about how the reader would have to continuously alternate between the PDF document and the browser, gave me a headache.
It was then that I thought of the option of designing the playbook as a web page instead of a PDF.
Pros of designing a playbook as a web page
- Better user experience – It is a much better experience to read on a web page as compared to a PDF. There would be no issues with regard to screen size.
- Easier navigation – If we need to link to external documents, it might become annoying for a user to shift between a PDF and the browser. Having the content as a web page makes navigation easier.
- Easy to include multiple types of media – A web page allows easier embedding and linking to external media. We are not restricted by the constraints of a PDF to what we can include.
- Better use of real-estate – In every page in a PDF, we lose ample real-estate to header, footer & margin. This increases the need to scroll.
- Easier to update & hence fewer man-hours needed – It is easier to update the web page (and keep it updated) as compared to the PDF. And hence, lesser need for manual effort in creating & updating the content. We are also not limited by the ‘size’ of the PDF.
- Easier to share – It is definitely easier to share a link as compared to a document. Especially when sharing with external organizations who might have a limit on file size being received via email.
- Comparatively easy to search for content – it is much easier to search and find the relevant content on a web page as compared to a PDF document.
Cons of designing a playbook as a web page
- Not easy to print content – Printing a web page wouldn’t look as good as printing a PDF. But if you are anyways planning to include a lot of media, printing a document wouldn’t add a lot of value either.
- Version control – It is easier to track the different document versions when the content is a PDF. This could still be done for internal purposes, and update the web page to keep only the most recent content.
This way, for internal needs you can track the different versions of the document, and at the same time not be worried about which ‘document’ you are sending out to the other users/stakeholders.
- Unwanted access to the playbook – There does arise an issue that anyone with the link can access the content. But that issue arises with the PDF too. The PDF can be sent to anyone by someone already having a copy.
For making the web page not being publicly accessible, it can be designed to not be crawled by the search engine. In that case, only people who have the link can even know the page exists.
Obviously, the scenario and requirements are different for each organization. What works for me might not work for you. And vice versa.
So make sure that you understand the end requirements of your user well, before you make the decision of going with either of these options. Who knows, in the end, you might decide an altogether different way to present your playbook.
I’ll be really glad to hear if you have designed your playbook any other way.
Want to join our small but awesome community? Just drop in your email below and I’ll buzz you in.