problem solving
Successful communication of information is an age old problem – how do you ensure your message is clearly comprehended by the audience?
Most communication activity occurs because there is a problem in need of a solution – yet unclear communication can quite often complicate the problem, making it worse rather than better. Set someone a task and, if they fail, you might get an excuse like ‘I didn’t understand what you meant’ or ‘I thought you meant I should do this rather than that’ – in other words, the task wasn’t clearly communicated. The same principle applies to publishing – you may want to convey a particular message or allow a web site visitor to learn or do something specific, but getting it right is often quite difficult.
The best way to solve the problem is to go back to the starting line and clearly define what you are trying to communicate.
m’khala can help – we analyse your communication needs (your problem) and create a finished product (solution) in which your messages will be understood the way you intended them.
four small steps
The following isn’t a magical or patented business improvement formula, it is simply a proven approach to understanding and solving communication issues that arise on a daily basis. Underlying the four steps is the simple principal of awareness – unless you understand something you can’t really be informed by it.
These steps may seem a little abstract at first, but they are an amalgam of basic communication theories (information transmission and semiotics):
- what is the message?
- how do you communicate it?
- how will it be ‘seen’?
- are your assumptions correct?
1. analysis
We use your briefings, combined with followup research, to digest and understand the information and content you want to use in your communication project.
Whether you provide this information as a shopping list of ideas, found examples, final content, or a selection of images – we use what you provide to develop a clear picture of what we think you want to communicate.
If we’re not sure about something, we might ask you to explain it further or to clarify some points.
Then we make sure that our picture matches your requirements.
m’khala will provide you with a written analysis of your needs and ask you to approve this before proceeding with step two. Depending on the size of your project (and your budget) this could be anywhere from a one-page email to a comprehensive business requirements document.
2. componentising
This is just as relevant to publishing a report or building a web site as it is to stress management - once the project has been broken down into small, easy-to-handle parts, it’s often easier (and less stressful!) to deal with each part one at a time.
Whether your project is a web application or a complex book, it makes sense to:
- identify the smaller parts that make up the whole
- determine in which order these parts occur
- define the detailed requirements for each part.
Once the smaller components are defined, it is easy to see how the individual parts work and what function they serve in the bigger ‘communication picture’.
Again, m’khala will provide a written report outlining the components of your project and ask you to approve this before proceeding. This report might simply be another email or it could be a detailed functional requirements document.
3. construction
The ‘building’ phase is where our hard work makes your content come to life – we create a print design, or assemble a web page template, then follow a ‘construction plan’ (based on the documents from steps one and two, and sometimes called a ‘project plan’) to bring together all the elements of your project and produce a completed product.
The term construction is important because, by this stage of the project (whether we are building a web application or assembling the content of a book) we will be working to a pre-approved plan.
At a number of ‘milestones’ during the construction phase (e.g. after we create the visual design, and once each component is finished), we will provide you with samples or ‘mockups’ of the work-in-progress and will ask you to approve these before we continue.
Once construction is completed m’khala will provide any further documentation that is required. This might include a technical implementation specification, a user manual or simply a digital copy of the project on CD-ROM.
4. review
This might be listed as the final step, but it also happens throughout the life of a project. While we’re busy analysing, componentising and constructing – we are also continuously testing our assumptions and checking that your expectations, needs and requirements are going to be meet.
The review process also includes reality checks. For example, after documenting a web project’s functional requirements we would perform a logical analysis – ensuring we don’t overlook a key component of your project or develop unnecessary functionality.
The final review step is ‘proofreading’ – where we re-check a layout, or web page, for any errors or omissions.
After we have proofread your project (and made any necessary corrections), we will provide you with a final printed mockup or working web site – you must give your approval before we will actually commit anything to print or publish it to the Internet.