Maslow’s Hierarchy of Needs Applied In Technical Content Publishing
Maslow’s hierarchy of needs is well known method when applied for people’s motivation. Once certain level of a need is addressed the person pursues the higher need. It starts with basics like food and shelter and ends with creativity and self-realization or self-actualization as Maslow puts it.
Here is how I applied it when creating highly desired content for specific audience – developers.
First I identified key buckets of what developers would want to have in terms of content and guidance. This is how I came up with Information Architecture for developers using Steven Covey Habits Applied In Technical Content Publishing. When it comes to new technologies developers need the following guidance and content artifacts to be effective and successful:
- Getting started. This is great as an ice breaker. It usually offers low bar code sample or walkthrough, Hello World style. The idea here is to give confidence to developer about the technology and that it’s easily doable. The downside is when it comes to solving real world problem the Hello World example is not enough by any means.
- Features descriptions. This is great to have a “static” non-actionable explanation of what’s available shedding some light on the technology and its internals. The downside is that while it can give some clues how to solve real problems developers usually left to their own devices when trying to apply the features to solve.
- API reference. This is fundamental part every developer usually want to have. It describes each and every little thing about the technology. The downside is as with the features descriptions developers need to resort to the trial and error approach that is full of friction.
- Scenarios and solution approaches. This is great and effective when trying to find an answer to the question “does it fit my case?” It mitigates the risk of wasting time as in the case with feature descriptions content. The down side is that scenarios and solution approaches content relies heavily on other content types and cannot exist on its own.
- Step-by-step How-To’s. This is prescriptive walkthroughs. It’s about taking horse to the water and it relies heavily on API reference effectively giving it a meaning.
- Non-functional (quality) guidelines such as security, performance, troubleshooting. This is great for times when developer in the know how to make things work, and especially when they break. Usually it is critical for production systems vs. evaluation phase.
- Code samples. This is great when a developers don’t want to start from scratch rather they want to cannibalize readily available working code. The downside is that in many cases it takes ton of effort to make the samples work, and even longer to extract relevant parts that are applicable to specific scenarios at hand.
Said all that, this is the simple model I came up with – the hierarchy of developer’s needs:
This simple model reflects on the fact that in most cases developers, before they start coding, need to understand if the technology can solve their problem. If so, then it would be great to quickly assess it by following simple instructions from zero to working demo. After that it would be great to have some code samples and deep dive features descriptions. Obviously Scenarios and Solutions content is of high value. On other hand, it’s impossible to create high value content out of the thin air, one need to create relevant lower level artifacts such as API reference.
To use this model consider planning and execution phases.
During planning phase you work top down – you collect relevant scenarios that people seek solutions the most. Best is engaging your field representatives and other field authorities. Just collection the list of scenarios. This will serve as a seed of generating the How-To’s list. Looking at the scenarios you will naturally start asking How-To questions. Once the list of How-To’s generated it will ultimately drive the relevant API’s that needs to be documented.
Such simple and streamlined approach leaves less room to think when creating the content – a good thing for content creators. It also reduces the friction when researching and searching for relevant content – a good thing for content consumer. Thinking less and doing more is one of the principles outlined in the book by Steve Krug Don’t Make Me Think where he outlines the principles of creating friction free content on the Internet. And that is a really good thing.
Maslow’s pyramid seems to me universal tool when approaching any domain. It helps identifying fundamentally needed and highly desired artifacts and then plan and prioritize what to deliver to achieve optimal results.
- Steven Covey Habits Applied In Technical Content Publishing
- From Consultant To Consultant In A Box
- Content Usability: Design Pages For Scanning
- First Law Of Usability – Don’t Make Me Think, And Other Facts Of Life On The Web
image by Victor Bezrukov25 July 2012