How To Bridge The Gap Between IT and Social Media
Incorporate the Building Blocks of IT into your Social Media Deliverables
In my many years in IT, as programmer, analyst and tester, I have found that idiot-proofing systems is paramount. This is a variation on the understood meaning, and probably more than a little unfair to those I sought to build systems to defend against. But the concept is simple:
No matter how clear and detailed your documentation is; no matter how clear you are in your instructions to new users, sooner or later, someone will attempt a workaround or shortcut.
And now, in the ADD Era, where attention spans fail to match those of the much-maligned goldfish (8.25 seconds as opposed to 9), there is little chance of people doing anything much more than merely glancing at the instructions you take so much time and care to painstakingly compile. Indeed, most people will only look at your instructions, whether in written or video form, when they can’t figure out for themselves how to use your software.
Where does that leave designers, developers and A/B testers?
Simply, every step of the way, it is important to inhabit someone else’s head!
- Consider the most unlikely scenarios.
- Never let anyone tell you what is worth coding or testing.
- If you thought of a possible course of action by a user of your product, chances are someone else will also
- NEVER discount a possible action as something no person who knows anything about software will ever do.
- Even in 2015, there are people – not all old – who have no aptitude for computers. And boy oh boy, can they ever wreak havoc!
And remember the absolute most important tenet of all:
Among my true pet hates are the words “Nobody will ever do that”!
This article will make only one presumption. If you are reading, you are looking to monetize, plain and simple! The good news is that the methods put forth are transportable, and can be applied to anything that requires development, including, for example, landing page design, advertising campaigns or training courses.
(Mid-article call-to-action alert: Feel free to ask questions below, if you’d like to know how this might apply to your needs).
Assembling your Dream Team
How do you build your offering to account for as many eventualities as possible?
Put together a design team
As well as the usual suspects (designer, developer and graphics person) this should include as many of the following as possible:
- The person you know who asks the questions nobody else ever thinks of
- Someone who finds pedantry to be fun (To my fellow Brits, pedantry is a competitive sport, so that might be a good place to start looking, lol!)
- A potential end user
- If you can convince them to join you, add the person you know who is always complaining that nothing on their computer works right (This person can get websites and apps to do things that nobody else can, and will never know how it happened). We all know one or more person who fits this description, lol!
- A really good tester
The Importance of Early Problem Discovery
Involve the entire team from the beginning
Remember: The sooner you find problems, the easier and the cheaper they are to fix.
I wish I could find the research that was used as the cornerstone of a consulting company I once worked for, but this illustrates the issue quite clearly.
The premise is clear:
- If you catch a design fault early, it is very easy to fix.
- If you go to development with that fault uncaught, you are building a product with an inherent flaw.
- If you find the fault after rollout, you need to apply a patch, if lucky, and a redesign, if less so
This would be a good time to remind everyone of the concept of regression testing. When you make a change, you must ensure that your fix caused nothing else to break! As with everything else in this article, the concept is easily transportable beyond IT. (Hint: compile test scripts in the design phase and reuse/amend them as you progress)
AND PLEASE, impress on all team members that it is never too late to report an issue. It is far better to catch something 2 months later than would have been ideal, than not at all.
And here’s another basic:
Winging it is for The Birds!
Settle on a methodology. As I previously mentioned in this article, you could do worse than use some aspects of Scrum/Agile.
- Always be involved in a 2-week work cycle, called a sprint.
- Have a kick-off meeting for each cycle.
- Schedule a short call at the same time every day to determine if anything might endanger each deliverable
- Have a meeting at the end of the cycle, to gauge its success.
The reason for the above is simple. If you set large tasks, you can veer off course too easily, without a chance of catching it early. And as demonstrated above, the deeper you go after making any mistake, the more costly (in time, if not money) it is to correct.
A World Full of IT Experts? No, It Isn’t Practical!
Lots of people write articles about aspects of IT. How many people actually hire anyone other than a developer, who comes from that world? I’d venture to guess that the answer to that is, few to none. But you know what? You have more than enough to learn in the ever-morphing world of Social Media Marketing, for it to be fair for anyone to expect you to become an expert in the finer points of IT also.
You would surely consider hiring or partnering with a Marketing person or Community Manager, if you felt that your expertise in these areas was lacking (or because you’ve already squeezed enough hours from what once was downtime or even sleep time, that there are no more hours to healthily add to your day)
Do you see where I’m going with this?
Hire someone who has done IT for a living! They may not be any more savvy in your world than you are in theirs, but they know all of those things that some of the best bloggers try to promote.
If you have money, pay them.
If not, try bartering or partnering with them! Give them the inroad into your (for them) untapped field, while utilizing their knowledge that you should not reasonably expect to master yourself.
Do you have problems talking with your uber-geek developer?
Well, guess why Business Analysts became a fixture in IT!
Because they are bi-lingual! They can translate English into nerd-speak and vice versa.
It is one of two skillsets – the other being Quality Assurance – largely responsible for the huge decline of bugs within corporate system development, in my 30+ years in the field.
In a nutshell….. it’s time to stop talking about aspects of IT and time to start incorporating its tried and trusted methods into the future of your company.
Over to you!
Do please leave comments below, even if it is to express disagreement. Certainly though, feel free to ask questions, request more detail about any aspect of the above or discuss any facet of IT you feel should have been included. Happy to open a dialog!
Image attribution: Arno Hoyer, Flickr CC https://www.flickr.com/photos/128621707@N08/17720868828/ Adapted for Curatti
Andy Capaloff
Latest posts by Andy Capaloff (see all)
- The Art of Asking Questions [Interactive] - October 17, 2023
- The Metaverse Is Not Dead. It’s Resting! - September 6, 2023
- How Can You Hire For Jobs That Nobody Has Experience In? Aptitude! - June 13, 2023
