Archive | October, 2012

Effective Feedback – Involve Developers

31 Oct

As a developer I think it’s great if I don’t have to deal too much with customers. They need so much time explaining their complains and most of the time it’s just an issue of wrong configuration, using the software in an unsupported use case or they are not aware of a feature. All these questions can easily be answered by a non Dev person like the support. Of course, we want to fix bugs in the software and get new cool ideas from our customers, so the support can note these and give them in a consistent format to the developers or discuss them in a weekly meeting together with the product owner. That way we developers can concentrate on developing and doesn’t get disturbed by doing support.

The Gmail team is calling this “The Sh*t Umbrella”. They have 4 product managers that protects the 100 developers from customer requests and questions. The developers can concentrate on making Gmail awesome. The product managers take care, that the customers requests get into the product in consistent format. Sounds right?

Well, if you’re doing a product like Gmail it probably makes sense. Gmail has currently 500 million users. That makes 5 million users for one developer. That really wouldn’t work. But do you have 500 million users that uses your product daily and just 100 developers? Do you have a product that is used by your own developers day in and out and you’re able to dogfood with your whole organization? If both answers are “Not really” you should consider to bring developers into the communication with the end users.

DevSups

At Atlassian we have a program called DoS-”Developers On Support”. We put a developer for two weeks into a support team. That helps both sides: The developer get in contact with real customer to learn how to fight at the front line. It’s really important to get the problems first hand from the customer and ask the right questions to understand the root of the problem. The dev becomes a better idea how the software is used in the real world.

But it’s also great for the support people: The developer get to know how the support works. For some problems you probably have work arounds. So the support is telling the customer how to work around a special problem. The development department got a request to fix this ages ago but didn’t hear of the problem anymore just because the support is providing that work around to the customer. Very often developers are saying: “I wasn’t aware that this is still an issue” and will bring it up when he is back in his dev team to fix it. In addition the support can learn from the developers why decisions for the product has been made and can explain that more honestly to the end users.

Direct connection

We also use a public JIRA instance and a community support system that is called Atlassian Answers to connect to the customer. At Atlassian we encourage developers to answer questions through that systems. The good thing: You can do a time box each day (maybe 30-45 minutes) where your developer answer these questions and work without support interruptions the rest of the day. Customer are so happy to get in contact with someone that can fix the issues instead of someone that talks about telling someone who is putting it in the schedule that someone can fix this issue (and most of the time there are even more layers). So it is a win on both sides! The developer get to know what bugs the customer and the customer knows that his issues has made it to the right person. Even if you have to let a customer down on a feature because of technical issues, he will accept the answer better, if it comes from a developer.

The GreenHopper team is discussing all feedback each day in a time box. They come together with the product manager in the morning, looking at all new feedback, maybe set new priorities and answer questions.

Expand the program

But not just developers should be at the frontier line. The management, HR, finance and many more departments should be frequently in direct contact with end users to understand the business better.

Effective Feedback – Blog Series

This is part 4 of my “Effective Feedback” blog series. Here are the currently released articles:

Part 1: Effective Feedback: No barriers 

Part 2: Effective Feedback – Fake it before you make it

Part 3: Effective Feedback – Make it an Experience

Tags: , , ,

Effective Feedback – Make it an Experience

19 Oct

Can you remember the last time you ran into a problem or saw a bug in the software and actually filled out the feedback form? Have you done it more than once? The last blog post was about removing barriers, letting people easily submit feedback. This post is about how to encourage people to finish the feedback in a way that your users wants to do it again.

How to demotivate for feedback

I found an example how to demotivate people to give feedback again and I’m not surprised that it is Microsoft. I just wanted to see how different vendors encourage people to submit feedback and the first application I picked was Word. It was very easy to find the feedback option in the menu. I pressed the button and was directed on a webpage. Well that is still OK, but I left Word for that… so it’s not good in terms of context switching. The feedback form is very simple: Select product and version (even though this could be done automatically) and write feedback. But it is so demotivating for the user that he has to tick the box “I know that I will not be contacted by Microsoft in response to my feedback”. Now the user asks themselves what happens with the feedback? Will somebody from Microsoft have a look at it at all? Why is it so hard to reply to the user with a follow up ticket number or a short comment that there’s somebody looking into the feedback? There will be not many users submitting feedback more than once, if they never hear anything, that Microsoft received it or even will do something about it.

What you want

You actually want people to submit feedback. It is the best way to get an idea, what you’re users are doing with your software and what they are missing. You do want them to come back and submit feedback a second and a third time. So you should make it an experience and help the users wherever you can. Make it fun, so users come back and love to go through the feedback process.

Good user experience

Wikipedia encourages users to rate pages. You can very easily rate how trustworthy, objective or well written a page is. You just need to decide how many stars you want to give each criteria. That’s it. The same applies to rating applications in the App-Store and books at Amazon. Let people rate the usability of your software and other things, that you would like to have feedback for. Don’t get in the way of the user and put annoying pop up windows on top of the application. Make it a side task.

Great user experience

The real fun comes with Google feedback. If you want to provide feedback to Google, you have to enter a sentence, then you can add a screenshot and highlight or blackout data. This way users don’t have to explain too much. It’s fast to give feedback if you just say: “I want to be able to add pictures to my comments”, highlight the comment area and press submit. Google is adding data automatically like OS, browser version, installed plugins,etc. That way it is fun to submit feedback and I definitely want to do it again.

At Atlassian we use Bonfire for getting fast feedback with a great user experience. Bonfire comes with a browser plugin that needs to be installed. That way you get a lot of possibilities to annotate the screenshot with circles, text and blur effects. Bonfire was developed by our QA to help and encourage internal users to submit issues when actually working with the tool. No context switching and you get addicted by the cool annotation features.

The same surprising effect has JIRA Mobile Connect. It’s actually similar to Bonfire, but runs on an IOS device. The best thing with this tool is, that your developers can write messages directly to the user who gave feedback. This way the user knows, that somebody cares about his problems.. not like Microsoft.

Make it fun

If you want to have lots of feedback for a new product, make a funny competition. Ask people to give feedback and let a jury or the community vote for the 10 best improvement advices. Give away some t-shirts. Let people send feedback via twitter and give a free license each day. Use your own imagination.

 The feedback experience

Care about the experience during the feedback process. Make the user feel good and get in contact with your user when they submit feedback. Even if it’s just a ticket number to follow up. If the user has fun giving feedback he will come back. You should care about your feedback experience if you seriously want to improve your software.

Effective Feedback – Blog Series

This is part 3 of my “Effective Feedback” blog series. Here are the currently released articles:

Part 1: Effective Feedback: No barriers 

Part 2: Effective Feedback – Fake it before you make it

Part 4: Effective Feedback: Involve Developers

Effective Feedback – Fake it before you make it

4 Oct

Building great user interfaces can take some time. You want to be sure that your first released version points in the right direction. How can you get feedback from your customers before you deliver a real product or a working prototype? What is the best way to try things out and be able to throw them in the garbage can afterwards? People tend to have problems throwing things away if they have already invested some time and this is exactly the reason why you should try out your ideas in an easy and cheap way.

Stage 1: Paper Prototypes

Probably the cheapest way to test the usability of an idea is to create paper prototypes. You don’t need a lot of things do produce your design:  some sheets of paper, a scissor  a pen, some glue and imagination! At Atlassian we’re using this technique to try things out. We’re doing one or two day design sessions when we’re trying to create the interface for a new feature or change the usability of an existing one. Our designers are sketching the interfaces on paper and trying them out by using there fingers to virtual click on drawn buttons or drop down menus. Take a look at this video to find out how a paper prototype works.

Your sessions are getting even better when you involve customers at a later state. If come up with 5 alternatives you should do some sessions with existing customers to receive feedback.

 Stage 2: Sketching Tools

Paper prototypes are good to collaborate if you’re in the same room. It tells you something about the interaction with the new feature. But what if your team is distributed? Tools are made for this. You can send your design by email or work together in an application on a prototype. If you want to ask a broader audience it is also way easier using tools to show your ideas remotely and collect feedback.

I would use a tool when I have three to five favorites to ask more stakeholder for feedback. There are pretty good sketching applications out there. My favorite is balsamic mock ups. It looks like you’re just sketching the feature. You’re not designing a polished interface, it just looks like a sketch. That way people are not expecting that this will be the final design and concentrate much more on the big things than on the details. You can also do interactions like drop down boxes and define actions when clicking on buttons. Use a VNC app or the Skype / Google HangOut desktop sharing feature to look at the screen of your stakeholder. Record the session to discuss the results with the rest of the team.

 Stage 3: Nice looking empty software

That way you should be able to have two favorites. Now you can make them nice. With some HTML / CSS knowledge it’s not that complicated to create a nice looking interface. Mock some functionality just to show how the final design would feel and look. At Atlassian we have created our design elements like menus, fields and buttons with Keynote (Apples Power Point). That way everybody can make a nice looking screen to try the final designs. It is a little bit harder to show interactions but also keynote has some nice animations. Don’t use them too intensive, it will give your programmers a hard time when they should make the real app ;)

Faking before making!

So fake it before you make it. That way you’re not so connected to designs that will be thrown away again. Ask as many different stakeholders for feedback as you can get. But be careful just with all the feedback you get: If you’re doing something totally new and revolutionary, most existing customers and some managers will be afraid of the change. Sometimes you need to risk things to get better.

Effective Feedback – Blog Series

This is part 2 of my “Effective Feedback” blog series. Here are the currently released articles:

Part 1: Effective Feedback: No barriers 

Part 3: Effective Feedback: Make it an Experience

Part 4: Effective Feedback: Involve Developers

Tags: , , , , , ,

Follow

Get every new post delivered to your Inbox.

Join 26 other followers