Content Strategy
The content strategist is responsible for overseeing all content requirements and creating all content strategy deliverables across the project life cycle. The content strategist works closely with the client to help manage and document existing content, new content, the content creation process, editorial guidelines and SEO considerations.
While most web projects only focus on the engineering of the site, the most critical component for a successful site launch is the content. All too often the content is an afterthought; a last minute exercise of copying old content from an existing site.
However, content is the reason visitors are coming to your site at all, whether that content is text, video, images, or audio. How easily the content can be found lies in the domain of information architecture, but what gets found is the domain of content strategy.
As a content strategist I may be involved in many different tasks during the project life cycle, from acting like the project manager for the content to actually writing and editing content. Each project is unique and has its own set of requirements, budget, and resources. We’ll work together to ensure your content creation and maintenance process is appropriate for your organization.
Requirements Writing
“If you don’t know where you’re going any road will do.”
I work with clients who “want a website.” This is akin to working with a contractor and telling him you “want a house.” If you’re not specific then any house will do. But you wanted three bedrooms? And a two car garage? The devil’s in the details.
Writing clearly defined requirements is the single most important thing you can do to ensure your project, website, or software application works the way you want it to.
Requirements are descriptive of the features and functions that make your website or software unique. They describe how things work- the means an end user will take to accomplish his or her goals. Requirements should describe in enough detail the system. Requirements allow you to:
- Accurately estimate the cost of the project
- Prioritize features based on schedule and budget
- Assess whether the end product does what it was intended to do
- Clarify all aspects of the system and remove ambiguity
- Inform your QA and test plans
- Protect against scope creep by clearly defining the boundaries of the project
- Instill confidence in the developers and engineers that you actually know what you want and what’s expected of them
One can make a distinction between “business requirements” and “functional requirements” but this doesn’t mean that multiple documents need to be created. Business requirements ensure the rules of the business are accounted for (e.g. Priority Overnight Letters can not be more than 10 ounces) and functional requirements ensure the inner workings of the system produce a certain results (e.g. a new registration will generate a welcome email after the email address has been successfully verified).
Corporations are notorious for creating massive requirements documents that take hundreds of man-hours to write, edit, revise, approve, etc. The truth is that requirements can take a myriad of forms: Word documents, Google docs, wiki pages, etc.
Regardless of their form the most important thing to remember when creating requirements is that they are clear and leave no room for ambiguity. They should be succinct, simple statements and contain no more than one idea or function. This is crucial since the requirements will directly impact your development, design, and marketability of your product.
Whether you’re creating a new mobile application or the next social networking website do yourself and your developers a favor and create a requirements document. There’s no better way to ensure success than through clear thinking, workable boundaries, and a well-defined goal in mind.
Need help with requirements? I’ve worked with clients for fifteen years helping to define and document requirements.