Posts

Posted on

Documentation Rule #1: Break It

“How do you ensure thorough mobile responsiveness testing?”

One of the most important things to consider was the thoroughness of the progress testing with their checks and balances. A deadline should not define the testing procedures of a project; those procedures and processes and their timelines should be built into the project’s time budget.

Emulators can help, especially for larger projects provided they can be scripted or automated to ensure a fully holistic approach to the test.

Regarding its effectiveness and ease of use, Luddite testing is essential to any project. Establishing the minimum level of technical adeptness needed for the project requires building a focus group to test with.

More to follow…

~ Edward Caissie

I have taken the above from a recent LinkedIn invitation to share my perspective. This is the following…

Testing can play a significant role in the support processes for any application, whether it be a mobile project, a desktop project, or any other project genre. The group assisting when needed should be involved in how it is used and utilized. While there may be a bias toward in-house support services, this is where their training also needs to come into play.

The project’s documentarians also need to be involved in the testing processes. In their case, the most straightforward rule of thumb is to “find ways to break it.” Suppose you know how to break something, with the ideal being extreme edge case usage. In that case, you can provide documentation that leads the reader, or viewer, depending on your medium, to not fall into those potential issues. Please document how to use the project while steering clear of any possible problems.

When faced with a shortened timeline or one that may have been unrealistic, your documentation and those who write it will likely be the best way to provide the final testing a project needs.

Could you find ways to break it?

Could you ensure documentation avoids these pitfalls and, more importantly, provides information on achieving the same goal or obtaining the same information?

The first rule of documentation is to find ways to break it.

Posted on

Lead. Follow. Friend.

positive diverse friends with bike walking on street

Managing your team is a lot like coaching your family. In some cases, you like the person, and there is mutual respect, so the management is easy. In other cases, you simply did not choose your family, but there they are all the same.

Don’t walk behind me, I may not lead.
Don’t walk in front of me, I may not follow.
Just walk beside me and be my friend.

Anonymous

Through many years of experience, I have learned the above does not apply, so why do I want to share this somewhat well-known quote as part of this conversation?

Let’s break down the whole thing to understand better how you can use this all the same.

Don’t walk behind me, I may not lead.

Yes, you can work with the understanding that your team will blindly follow your instructions, but they should be helped and coached to accomplish the goals you set for them. Please work with your team to maximize their skills and talents.

Don’t walk in front of me, I may not follow.

You should not be following behind your team to pick up the pieces. Your job is to manage your team so they can recognize when something gets missed and how to reconsider best and pick up their pieces. Following behind is tantamount to micromanaging, which ultimately will drive down productivity.

Just walk beside me and be my friend.

This quote is almost valuable on its own. However, what it means to be a friend should still be considered, as should creating a friendly atmosphere. A very fine balance needs to be maintained in this case.

Developing a friendship with a team member can have many valuable benefits, but it can also create an atmosphere where directions are not followed or ignored. The friendship can smooth over the indiscretions, but that does not get the work done. Creating a friendly atmosphere will promote better, more transparent conversations and more constructive feedback in both directions.

In life, take the full quotation as you will, but with work-related situations, remember that, in general, and at best, the quotation is both a guideline and a warning. Make sure it serves you well in either case.

Posted on

Character Not Characters

This is a departure from my usual topics. Providing support (my generic term covering all the “C” acronyms: Customer Service, Customer Success, Customer Experience, etc.) will always be the responsibility of the team that is responsible for these tasks.

Sure, there may be a “manager” role involved, but ultimately, it will be about how well the team works together, and apart, to provide the most assistance and, yes, support to your customer base.

Although experience can be significant, this is another potential fallacy: Knowing the product beforehand will not give you the knowledge you need to assist another person using it. A good manager can train any of their reports to understand and use the product as it was designed. This requires intra-team communication to ensure these intended functionalities are accurately described.

Keep in mind that the properly prepared underlying documentation will be the training resource. This again points to proper integration between the relevant teams.

This integration is going to be supported by the character of the individuals working together. This is not about employees being characters but the moral and intestinal fortitude and the commitment to their organization, i.e., their character.

A person of character can be trained. They can be incentivized with the proper management. They can be provided the tools to succeed and left to do that.

Persons of character will succeed if provided this impetus and allowed to shine. They will provide more successful and innovative approaches than any amount of forced management of their skills could ever present.

Persons of character will always be a boon to any organization but beware of characters that are not about the organization. Their thinly veiled intentions will always shine through under scrutiny. They will show themselves in unexpected ways, and it will be challenging to make the hard decisions that need to be made.

Character versus characters: choose the former to succeed; do not give in to the latter.

Posted on

Do Right. Be Right.

man with headphones facing computer monitor

Do the right thing, and be the right person.

Stop! Think about what you are about to do. This is essential and extremely easy to do when writing, especially when responding to a request for assistance.

Do the right thing. Ensure you are reaching that point where you are providing a benefit to the person asking the question or reaching out for assistance.

Be the right person. Recognize that some conversations may start from a very stressed individual that first needs to be talked off the ledge they are peering over and then providing the information they need to take a step back and resolve their issues.

In almost all cases, your response should be designed to step up to the edge with the person and then walk them back to a point where they can see the problem for what it is. Then, you can move towards the best solution to sort out the circumstances they have found themselves in where they reached out for help.

Do the right thing. Find and relay the simplest solution, and more importantly, remember this may not be the most straightforward, but it will be the one that works best.

Be the right person. Know that taking care of a request for assistance rarely has any relevance to take personally. Making every effort to empathize with the request for assistance and the person making the request will go a long way in helping them accomplish their goals.

Posted on

Providing Documentation

When providing documentation, there are almost always going to be a great many factors to consider. However, going back to a simple system of asking the “W5” will get you focused in the best direction.

Who – who is going to be reading this? Who is the documentation being focused on? Who did read it?

What – what is being documented? What does it do? What could it do? What might it best be used for?

Where – where should it be located? Not only where, in general, the documentation should be located but where updates and additions should be added to the existing documentation.

When – when will this documentation be read? When should the documentation be read? When was it read?

Why – why is the documentation necessary? There are several schools of thought on why something should be documented. However, in a perfect world, the documentation is only for those not using the service or product, to begin with, as the UX/UI itself should be designed in such a fashion that it is intuitive and self-explanatory. This may not always be the case, but we also don’t live in a perfect world.

Think of the analogy of sitting down to a bowl of soup with utensils. Granted, most people will understand the soup is food and can be eaten and choose to eat in a manner comfortable to themselves — they may pick up the bowl and drink from it, or they may use a spoon provided. Others may need to be “spoon-fed” as this is something new, and they are not certain how best to eat the soup… think of documentation as “spoon-feeding.”

Remember that too much documentation or documentation that is too complex may be seen as the equivalent of force-feeding another bowl of soup after the diner is full and satisfied with their meal. No matter how great the meal, there will always be a point where you need to stop eating.

Photo by Lightscape on Unsplash

Posted on

Personalize Responses

Responding to customers in writing daily could lead to a form of “writer’s block” where although you may know the correct answer, you still stumble over getting that information out.

One thing to consider for these situations is “canned responses” — not form letters, but more basic templates to get the ball rolling and the creative juices flowing. Communicating with customers is all about getting the information across in a form best understood by the person receiving it. A “saved reply” provides the basics; you can fill in the “blanks.”

Always use an appropriate salutation and personalize the response to the subject and the recipient.

Also, keep in mind that if the customized “template” you are going to send feels a bit “canned,” it will mostly come across as such. In some cases, this may be fine, although, for the most part, it will always be a good thing to read, edit, re-read, and edit your response some more before sending it out — make those little tweaks so your response will be more personalized and on point.

Remember, writing begets writing; consider some off-topic personal writings to shake things up and give yourself some ideas and methods to improve your written communication skills. Maybe start a blog about support?

Photo by Nick Morrison on Unsplash

Posted on

Written In Whatever Works

yes written in the sand

Wow, it’s been a while, but I’m back… at least for this post.

There are times when it does become a question when trying to establish guidelines if you are taking the “written in stone” method or the more ambiguous and flexible “written in mud” approach.

“Written in stone” implies this is how it is, and there is virtually no wiggle room for you to move outside the guideline. You essentially have to work within them which is excellent in the beginning. However, as time goes on and things evolve, you might start to see bits and pieces of your stone tablet starting to chip away.

Those strong and idealistic guidelines proved very helpful in establishing your processes and creating the environment you are working with. However, they also may have become even more restrictive than you expected as these guidelines now control your work versus you controlling the work product you want to produce.

Hence, the idea of “written in mud” comes to light. Yes, as the phrase implies, it could get messy. Still, because it offers some ambiguity and more flexibility than the stone practices, that messiness allows you to try out new things within reason and carry on with your evolving workflow.

Your written-in-mud guidelines can evolve with the times versus needing to be carved out of another stone tablet that will likely fall prey to the same ravages of time the first set of written-in-stone guidelines did.

Which approach is best for you and your projects will ultimately be your decision, although it will eventually come down to the approach: written-in-whatever-works.

Posted on

Get It Right The First Time

You’ve only added two lines – why did that take two days! ~ Matt Lacey

The above is a great read and another aspect of providing support. In this case, the premise is “fixing a bug” and getting it right the first time.

Ideally, every time you have an interaction with someone in support you will be able to provide them with a solution in your first response… and sometimes that may take a bit longer than usual but most of those times getting a solution will be much more appreciated than a quick response prolonging the support request.

Photo by Dan Gold on Unsplash

Posted on

No Shortcuts

Learning a new shortcut can often take longer than the long way you already know.

When offering a new strategy or approach to something, keep in mind following the tried and true methods will always work. Sure, it may be great to find a new and better way but not at your customer’s expense or reducing the quality of care you would have provided before spending the time to find the new approach.

This doesn’t mean to say you shouldn’t find ways to improve and enhance your approach — only that it should not be at the expense of others when you do.

Photo by Andrew Neel on Unsplash