Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Writing an influential essay is like crafting a bridge between your ideas and the impact you wish to achieve. It’s about persuading, informing, and moving your audience. But how do you transform a mere thought...
The post How to Transform Ideas into Impact: A Step-by-Step Guide on Crafting an Influential Essay appeared first on 85ideas.com.
I have written before that the most important trait in a new hire is coachability. What a shame it would be if you went out and hired an extremely coachable talent, and then failed to effectively coach.
No doubt, there is skill involved in giving effective and meaningful feedback. Here are my rules of thumb, which will hopefully make it easier:
If you’ve designed and built a website for someone else, then you know the feeling of dread that can surround feedback time. Multiple emails from multiple clients with subject lines that read a bit like Re:Fwd:Website feedback due three days ago, which may or may not have the same feedback or bugs reported as the very similar email from yesterday. It’s enough to give you a headache, and that’s before you’ve even opened the emails to see vague feedback like “I don’t think this pops enough” or “there’s a bit on the page that looks odd”.
Good website feedback is clear, actionable and trackable. Let’s break those down a little more.
Good feedback makes it obvious what is wrong and what needs to be fixed. It contains information that makes it easy for someone else to see and understand what you are referring to. Vague feedback like “I don’t really like this colour” is less helpful to the recipient than “This is not our brand shade of blue, please use the brand colour.”
Good feedback makes it easy for the receiver to do something with it. It contains information that helps the receiver to decide what’s wrong and how to fix it.
Emails can easily get lost in a jumble of similar sounding subject lines, or worse, completely overlooked in the back and forth communication. Tracking feedback shouldn’t be difficult or stressful.
Giving feedback doesn’t need to be difficult. Providing good feedback means that it will be actioned faster too.
Here’s a handy checklist when giving feedback to make sure it’s great. Not all the information will need to be included all the time, but it will definitely help.
Don’t load up with multiple bits of feedback at the same time. Break it into smaller sections. Keep it simple, people!
Include the URL of the page you’re referring to.
If a picture is worth 100 words, including a screenshot or screen recording may prove easier than trying to explain what you’re experiencing or referring to.
Include information such as your operating system. What browser you are using for websites and web applications. Include whether you were using a desktop or mobile, if it’s not already clear.
If your feedback refers to a bug or problem with the website, include the “steps to recreate” the problem. When a bug is replicable (able to be recreated) it’s easier to work out what went wrong and to fix it.
If you’re getting a specific error message or code, it will be helpful when pinpointing if there’s a bug and how to resolve it.
Does the same thing happen every time you do something? This information is super helpful to developers for fixing any issues.
On a website, does the feedback refer to something broken, is it cosmetic, does it affect how people use the website?
All these things help to determine the severity and help prioritise the order that feedback is actioned.
Typically severity varies from Very High (it stops you from working completely) down to Very Low (cosmetic changes).
A tool like BugHerd can help a lot with making feedback from clients clear, actionable and manageable.
To begin, BugHerd can do a lot of the work in making feedback clearer. BugHerd pins feedback to a webpage, captures the technical information and helps clarify feedback. Here’s an example of how BugHerd organises information for a feedback task.
A – What is wrong and what it should be
B – URL (location)
C – Operating system, technical information for replicating and solving
D – Screenshot
E – Severity
F – Additional information
Feedback is pinned to a website, so you know exactly what each piece of feedback is referring to on the site. In cases where further clarification is required, BugHerd makes it easy to comment on a task and request more information from the person leaving the feedback.
Managing feedback is one of the toughest parts of handling client feedback.
With BugHerd, all feedback is sent to one central location – a kanban style board. Here you can track feedback until it’s completed, assign tasks to team members, communicate with clients and ensure every piece of feedback is dealt with.
The post What makes good website feedback and how do you get it from your clients? appeared first on Codrops.
An argument with a coworker — conflict of opinion. Working on a project that doesn't energize you — conflict of interest. Didn't get the promotion — conflict of growth. Working super hard with no time for personal life — internal conflict. Saying yes to work that doesn't align with your goals — conflict of priorities. Committed a mistake, but can't come to terms with accepting responsibility — conflict of values. We don't realize it, but most interactions at work lead to a major or minor conflict.
When it's a minor conflict, we feel a sense of discomfort in our body but can't pinpoint the exact source of the discomfort. Most of the time we ignore this conflict while it sits within our subconscious as we go on with our daily life. A major conflict, though, looks and feels very different. Even though there's no real danger, our mind perceives the conflict as a threat.
When we think of giving feedback, we promptly think about correcting others. But giving feedback is as much about telling others what they are doing right as it is about telling them what they are doing wrong. It’s as much about reinforcing good behaviors as it is about eliminating bad ones. It’s as much about singing praise that comes off easily as it’s about giving constructive criticism that makes you uncomfortable.
If you are a manager or a leader, telling people what they ought to hear is not your job, it’s your responsibility. You are the person standing in the way of hundreds and thousands of employees who count on you every day to grow. Not making an effort to tell your people how they are doing and what they can do better, only because it makes you uncomfortable is an act of irresponsibility.
User feedback is vital to the success of our projects. It can help us identify which new ideas we should pursue as we develop and can keep us focused on delivering just what users need.
We have all seen projects that didn’t have the right user validation and feedback. We know this information is important, but getting it, and using it effectively, can be difficult. This can be especially problematic with new projects where you can get into that tricky phase of being slightly ahead of where the users are. It may be tempting to wait to proceed based on user feedback, but that leads to a “chicken or egg” scenario. The faster you can provide meaningful improvements, the greater the adoption, which means greater feedback.
This post is originally published on Designmodo: Userwell Review – Product Feedback Management Software
Customer reviews are essential for the analysis of your e-reputation. They reflect your influence and your popularity on the web. When we know that nearly 70% of Internet users read customer reviews before buying, it is essential to pay particular …
For more information please contact Designmodo
Doling out advice, hurling negative comments, passing mean remarks – we have all done it. Given an opportunity, it’s easy to assume the role of an expert and tell others how wrong they are, why their product isn’t good enough, why their idea will never work, how they should behave, what they should do. Why seek permission when we feel right in our criticism?
Now let’s turn this around. Are your critics telling you the blunt facts you need to hear? Think for a moment about how you feel when you are on the receiving end of this criticism – angry, defensive, resentful, frustrated, sad, maybe even a little bit devastated.
All managers struggle with the fine balance between doing work that achieves short term goals vs investing time in activities with long term benefits. Output that's immediately visible may give a feeling of satisfaction in the moment, but it soon fades away and demands more energy to keep up with the pace of growth and scale of the company. Focussing too much on progress in the short term eventually slows down every manager in the long run.
Energy spent in growing business may help you achieve some outcomes, but the same energy invested in growing people can produce remarkable results.
Technology plays a huge role in everyone’s life and we all are dependent on technology. Today we have various emerging technologies that we use to accomplish various tasks in our lives.
I've worked with Developer Relations for many years now, and I think it's a fascinating topic with many takes on what it is and how to do it! I wanted to share my view on it here, and what I think it encompasses.
Last year I gave a presentation called "Have you tried listening?" at the DevRel Summit which I think outlines a number of the main DevRel concepts and areas, and examples from my personal experiences with them.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
This is one of the principles behind the Agile Manifesto. While following all the principles is essential to being agile, one might argue that without tuning and adjusting team behavior on a regular basis, productivity gains will be hard to achieve.
Unfortunately, many read the above principle and only associate it with performing team retrospectives at the end of a sprint, or periodically in kanban. But if you seek to build a high-performing team, there are many more improvement activities you should consider adopting.
While there isn't a one-size-fits-all sprint length that software development teams should universally adhere to, I think we can all agree that when it comes to sprints, somewhere in the neighborhood of two weeks is the sweet spot. And more than four weeks simply won't do. Here's why:
Since Scrum is an empirical process, the notion of small batch sizes (aka short sprints) is based on the Theory of Constraints, which says that a system is less limited in achieving its goals by a smaller number of constraints. In software, some of these constraints are backlog items (inventory), throughput (velocity), and ROI (customer value).
"If you decide to build a feature you should live up to at least a basic standard of execution on the experience side." ~ Ryan Singer
Many developers take the "Minimum" in "Minimum Viable Product" too literally, which eventually leads to skimping on the design as well as the scope stage. Technically, the concept of MVP is agreeable when it comes to putting in minimum possible effort and time for testing your product in the market. But that doesn't mean the product should be literally minimum.