MSSolve UX Roadmap Discover Phase Summary September 22, 2008.

20
MSSolve UX Roadmap Discover Phase Summary September 22, 2008

Transcript of MSSolve UX Roadmap Discover Phase Summary September 22, 2008.

MSSolve UX RoadmapDiscover Phase Summary

September 22, 2008

Research | Findings1. Roadblocks hold up the workflowTo satisfy needs of support engineers and their customers, MSSolve must enable engineers to rapidly problem-solve without breaking their “flow.”

Capturing support data is critical to Microsoft, but must be done in a way that does not compromise engineer efficiency.

Performance measurements shouldn’t interfere with performance.

Research | Findings | RoadblocksCREATING A PLANThe intent of the Plan activity is to create a To Do list, and also to document status for someone reviewing the case. However, it can often be more of an administrative burden than a useful resource.

“The first task that’s always there is the Solution. So you have to keep re-sequencing to move it to the bottom.”

“I have to reverse order my tasks so that solution is number 1. The process really isn’t clear on which process you’re supposed to follow. I don’t really know why I have to do that. I would say I put in a good 5 minutes just re-sequencing tasks on each case I work.”

CASE OWNERSHIPSome SEs mentioned process issues with taking a case from the queue and assisting with a sub-case.

“There are some things about opening and closing cases that get in the way more than they help. For example, I was asked to call back a customer on a closed sub-case. But I couldn’t yank a closed case. Only the case owner can do that, and he was out.”

“Sometimes when you yank a case, somebody else can yank it away from you.”

DOCUMENTING SCOPEIn MSSolve, SEs are required to complete and send a detailed scoping document before they can work with the customer of a case. We were told by a stakeholder that this gated process has had two unforeseen consequences.

1. SEs sometimes enter junk data, which then is automatically emailed to the customer, just to get past the formal scoping and on with the work.

2. The perceived formality of scoping is slowing some SEs down because they are concerned about “getting it right.”

Research | Findings 2. Too many things in too many placesEngineers rely on numerous tools and resources to do their jobs. Not only is it challenging to learn where are all these are and how to use them, going back and forth between them creates extra work and confusion, and wastes time.

Ideally, engineers should have at their disposal a single, integrated front end for tools and resources.

Research | Findings | Too Many PlacesSEARCHING RESOURCESCTS staff described a variety of resources they use throughout the day. They spend a lot of time moving between these resources, and copying data from one to another.

“There are too many different tools to use. To me it seems that time would be better utilized if we had the right tool for all those things.”

“Since we have to switch tools a lot, we need tools that default to a safe location so you don’t accidentally change or lose data.”

“The combination of the three tools is what’s currently working for me: Clarify, Team Metrics, and SharePoint.”

SHARING FILESSEs told us that the frequent task of sharing files with customers is arduous.

“There ought to be a button to just click to create a file share. Right now, I have a link on my desktop to file server. I right click it, create a new folder, go back to Clarify, grab the SRX number, copy it, paste it into the name of that folder, then open the folder, and then go and copy whatever I’m gonna copy off to that folder.”

“If an SE puts a file on a share, it’s not enough that their TL can get to it because we do a lot of collaboration; at the same time, you want to limit access for security. We need to make sure we document where it is and what is there.”

Research | Findings | Too Many Places INTEGRATIONSEs want to have a better sense of control by doing everything from one place.

“In a perfect world we would have one tool for everything. I wouldn’t have to run OnePhone on a separate machine, and when I answer the phone it would be part of the case log so when a case is assigned to me and I open it up, it would know that I’m on the phone and start a timer. I’d write all my notes in there. It could remind me that I need to change the case status from Needs Contact to I’m talking to the guy. It just needs more integration...”

“Unfortunately, sub-case queries are separate in Clarify, so I have to do a separate set of queries just to see the sub-cases. So I’ve got multiple places for the queries.”

EMAIL & IMSEs are resourceful in their means of communicating with customers and each other, but working outside the tool creates a problem for logging those communications.

“An engineer sends an email to a customer that has great information... but if you copy that into the notes it pulls in the entire thread, and keeps appending. It makes readability very difficult.”

“When we’re on the phone we communicate by IM.”

Research | Findings3. Lack of signposts slows the journeyHaving to double-check takes time. Providing subtle cues to direction, next steps, and state changes, are crucial to providing a streamlined, supportive workflow.

Research | Findings | Lack of SignpostsDIFFICULT TO QUICKLY ASSESS CASE STATUSWhen CTS staff take on or review a case, they need to get up to speed quickly. Currently, there is no good way to do this.

“You’re… supposed to change the title of the case as you go, but I don’t do that... I don’t know why we’re supposed to do that. Maybe clarifying it, giving a better description of what the actual current problem is? I can see that that would be helpful for my manager or my Tech Lead if they are reviewing my case load…”

NO CONFIRMATION OF ACTIONSIn our expert evaluation, we observed that MSSolve gives no consistent feedback on changes resulting from a user interaction. Examples:

1.No indication when something is saved.

2.No feedback on duplicate entries (e.g. logged time).

3.No indication of next action or where you’ve been.

4.Poor or misleading errors if something goes wrong

5.No feedback on actions of others.

NEED FOR ALERTSCTS staff need to maximize their efficiently. Giving them appropriate alerts at the right times would help them use their time wisely.

“I want to know if there’s a couple people before me in line or I’m next in line. I don’t want to be heads down in something and then get pulled out.”

“Multitasking is what I do.I don’t use Outlook tasks because of the limitations on sorting and filtering, and because I want to make sure my team knows what I’m doing.”

Research | Findings4. One size doesn’t fit allThe less structure there is to get in the way of a support engineer solving a problem, the better it is for the engineer. But to maintain quality and capture needed metrics, some global structure is required. A solution that maintains a structure while allowing flexibility in the way it is accessed and populated will best serve the engineers, the customers, and the business.

Research | Findings | One Size Doesn’t Fit All

MSSOLVE DOESN’T MATCH ENGINEER WORKFLOWSEs currently using MSSolve did not like the imposed structure. They did not see a benefit, and it made their work harder.

“I really don’t know why they imposed a structure on [the workflow]. Maybe so anybody could go in there and look at the last task and see where you are at that moment.”

OVER-PRESCRIBED FRAMEWORK WILL BE CIRCUMVENTEDIn pursuit of their goal of quickly solving customer problems, SEs find ways to get around imposed structure if they see no benefit to it.

“If I were spending money to provide a support tool for my engineers, the tool should be intuitive to what they do to support a customer.”

“Being less restrictive would give us the freedom to be more productive.”

A FIXED PROCESS IS SOON OUTDATEDCTS and COE need to be able to keep up with rapidly-changing demands without having to revise the platform every time.

“Having something configurable rather than customized is nice because if you’re going to upgrade the software, you don’t have something “one-offed” that you’re struggling with now, and [you] can make it fit [your] business instead of making [your] business fit the tool.”

“Different business groups have business needs. Development is different from Core. It gets more unique as you move up the escalation chain.”

Research | Findings5. Garbage in, garbage outWhen faced with conflicting goals of solving mission critical customer issues or documenting steps taken, engineers are tempted to enter anything into the rigid documentation sequence so that they can get back to problem solving. These types of workarounds negate any potential value in imposing these inflexible entry sequences.

Research | Findings | Garbage In Garbage Out

ENTERING JUNK JUST TO GET BACK TO WORKSEs are under pressure to solve problems. They are conscientious about following procedures they view as important to that goal; however, some admitted no tolerance for what they viewed as “busy work.”

“A Tech Lead can have up to 150 cases to review, and if people are putting poor information in there, your life is bad.”

“What wastes my time? When people won’t follow the process and having to enforce that.”

LOGGING LABORSEs are confused about how to categorize their time, and don’t want to do it manually.

“I don’t know whether to log time I talk with the customer as communication or labor – or both.”

“I just estimate my time, round it to the half hour.” (EE referring to research time)

SKIPPING STEPSWhen time is limited, SEs will only do what’s necessary to solve the case, or at least has a clear benefit to them.

“If SOs are coded correctly, articles will get written quicker, and they’ll be easier to find.” (Manager indicating that SEs don’t always take the time to code SOs correctly).

“There’s nothing to require me to do it, so sometimes I just don’t think and don’t do it. Maybe when I get more into this I’ll do it.”

Research | Findings6. Smart people will create workaroundsMSSolve’s workflow should mirror the user’s mental model of the work. If the tool doesn’t meet users’ needs, they will create a workaround solution that does – making “using” the tool just another required administrative task that doesn’t help them achieve their goals.

Research | Findings | WorkaroundsEXPERTS BUILD EXPERT TOOLSSEs are software experts. If the tool they have doesn’t support them, they make their own. They’ve been doing it for years and they’re very good at it.

“We have a lot of people here who have the initiative and the ability… so when they develop their own tool it does exactly what they want it to do.”

“I don’t have quite enough of what I’m looking for and that’s why the team has ended up creating the Team Metrics spreadsheet.”

“Composter was a local, homegrown tool where you could reuse the same responses over & over.”

HOMEGROWN DATABASESWe observed a number of SEs who had created their own private databases, which they either shared with the team or kept for their own use.

“I have a database that contains articles that are useful to me.”

“I do all my work in an Access database. I have a tendency to keep my notes there – like a backup.”

“When I was on Frontline I was trying to keep track of my own cases; I created an Excel spreadsheet.”

“I’ve created a Sharepoint site that’s public, so my SEs can see what I’m working on and get an idea when I will get to them if they have asked me for help. I also use [it] to track cases that I want to keep on my radar, or if I’ve asked for feedback from escalation services. That’s how I keep organized.”

Research | Findings7. Engineers must do bookkeeping for the systemEngineers want to focus on solving customer issues. Any tasks unrelated to that goal should be handled by the system whenever possible.

MSSolve currently forces SEs to manually enter and track many things that the system should do automatically.

Research | Findings | BookkeepingTRACKING LABORSEs are confused about where they should log time – and don’t want to do it manually.

“Clarify … automatically starts the timer, and we can adjust it. That’s how it should be in MSSolve too – not manually.”

“As a support technician all you want to do is solve the customer’s problem. Administrative things, like manually logging time, get in the way of that.”

“One of the things we’re always having problems with is making sure labor is recorded properly.”

MONITORING CASESCTS staff need to know the ongoing status of open cases. Currently, they have to hunt for it.

“Team Metrics – unfortunately it’s a day old because we can’t go querying against the system, it’s already slow enough. Anything I can get from queries in Clarify is better so I can get fresh data.”

“Sometimes I like to see them all together to gauge overall health, sometimes I like to see them just in buckets. A view of doing things by labor, by age, by SE would be very useful.”

“Triggers – they don’t come to me. It would be useful.” (Tech Lead)

CLASSIFICATIONSEs are not always the best source for case classification. They admit to being confused about how to do it, or just view it as an administrative task not helpful to their job.

“You have to classify a case in order to close it, but I should probably be doing that as I’m going along. But I haven’t been doing that. I only do it when I have to...”

“I think the most common mistake engineers make is they code it to the symptom, not the root cause. That’s what I would usually see.”

STATUSCTS staff should not have to spend time determining status of cases or performance (utilization rate, closed by content, etc.). These should be made readily available - automatically.

“Lately people have been forgetting to take ownership of cases in a queue. It would be nice if it happened automatically when it should happen.”

“I think I’m running 100% this year. Every case I’ve closed has been linked to a KB article.”

“If a tool is clever enough to be able to facilitate clear, cogent information, that would make it very compelling to use.”

Research | Findings | BookkeepingMISSING FUNCTIONALITYCTS staff spend a lot of time doing manual searching and sorting tasks that could be more automated.

“I use Team Metrics because I like to sort by (case) age, and I like to sort by total labor in a case. And Clarify absolutely doesn’t give me those. When the customer says they don’t want to go over 10 hours, we have no way of knowing when we have reached that. That’s definitely functionality that’s lacking.”

“I like to search for cases where I have no labor on them, so I can follow up on anything that I might have overlooked. Definitely need that. Total labor and my labor are very important to me.”

LOGGING DATASEs recognize the need to record their problem-solving activities, both for themselves and others who may be reviewing the case. However, they are sometimes confused by the number and types of data they are required to log.

“If communication is already included in the Task, then it’s redundant to also put it in the communications log. And then with the labor log for both locations, it’s confusing. You’re just repeating the same work.”

“There’s stuff that I need to do, but it hasn’t become natural for me, and I haven’t thought about doing it yet. I have to get more comfortable answering questions before I can do all the administrative tasks.”

Research | Findings8. Incident management is the tip of the icebergKnowledge capture and access must be a key element of MSSolve if user, business, and customer goals are to be met.

A huge amount of expert knowledge resides in the engineers’ heads. Ways to streamline or partially automate the knowledge capture process would greatly benefit all engineers.

Automatically capturing and surfacing previous successful searches would reduce search time by proactively sharing “tribal knowledge.”

Research | Findings | Knowledge Management

SHARING KNOWLEDGETechnical support is expensive for both Microsoft and its customers. This cost can be reduced by improving the methods of sharing knowledge and automating knowledge capture.

“Capturing and disseminating knowledge should be both internal and external. If an engineer anywhere solves a problem, we want everyone to benefit from that investment.”

“Most of the time the people around me can help. I tend to pop up like a cubicle prairie dog. If I have time to do research I will, but if someone is on the phone, it’s a lot quicker to go pester someone.”

“If I get a really hard problem that’s when I should contact my Tech Lead, but he is in Dallas and I don’t have a relationship with him. So that’s when I find someone here to help me.”

FOSTERING SELF-HELPMany SEs recognized the value of self-help tools both internally and customer-facing.

“We’ll never ever get to 100% self-service, but most people want that. We’re in a society that supports that.”

“You provide varying avenues that meet the needs of what the person is trying to access. Is it a KB article? Is it a tutorial? Something where they can very quickly find a solution themselves. That’s the cheapest way to provide support and it’s key.”

“The most expensive support is onsite. The second most expensive is somebody on the phone. So from a cost perspective, the best support you can have is self-help tools.”

Research | Findings | Knowledge Management

KNOWLEDGE SHOULD STAY FOUNDCTS staff spend a lot of time “re-finding” information they have used before. Doing a better job at resurfacing this knowledge for them will be a big win.

“There’s a lot of casual information sharing. People might ask “do you know something about this?” and I might remember “yeah, I remember reading something on a blog somewhere, let me go find that for you.” And then I have to go remember where to find it again.”

“If an engineer leverages a resource like Live Meeting, is there a way that when we provide support in that context we can incorporate it, and avoid redundancy of doing that again and again. If we solve this problem once, we should not have to try to solve it again and again. It should be an automated process then. We need to be as efficient as we can. That’s what a support tool should do in a perfect world.”

KNOWLEDGE SHOULD BE INTEGRATEDIn addition to maintaining knowledge, SEs expressed that MSSolve should surface relevant, previously found resources that may be useful to a current case. SEs currently maintain spreadsheets or databases of KBs they frequently use. The tool should do this (and more) for them.

“We have an elaborate way now of doing KB articles, but a good support tool should always be able to facilitate providing KB articles because that’s a form of support.”

“The tool should be able to help disseminate… information. There are certain things that are very common to a certain type of problem, so the tool should be able to extract useful information and help somebody quickly come to a resolution.”

“It would be nice to be able to just click on a page that helped, and it’s done.”

“If you were in a perfect world, you could even build dynamic real-time call scripts from the knowledge already stored in the system. Then you’d have no problem getting engineer to use it. They’d go “THIS ROCKS!””