I was using Lync to start an online meeting. The place where I work uses Lync as an online chat, phone and screen sharing tool – it is like a variation of Skype. What I like about it is that I don’t need to use a phone and can access a meeting quickly. What I don’t like about it are the perpetual confirmation screens asking me details about what I want to do.
The button options are clear – phone, chat, video, screenshare, invite other people. Not a lot of question there.
Although the buttons are clear, Lync still asks a lot of questions:
- Do I want to use Lync for my phone, an outside line, or have Lync call me?
- Do I want to share my entire desktop or an app only?
- Do I want to chat on the screen with the phone call?
All of these questions all the time is more than annoying.
How would you feel if you saw this screen every single time you made a Lync call:
Sure, there is a checkbox so I can remove the window, but why not after the first experience, encourage the user to save what was selected as a preference?
Or better yet, why is there a need to show this window at all if the user has a headset plugged-in to his computer?
I have been slightly late to calls because I forgot to make an extra click to remind the app that I use a headset through my computer. Or I didn’t share my screen properly because Lync wanted to know if I wanted to share an app or my desktop.
In UX design, you have to make some educated guesses as to what the user most likely wants to do. Some guesses are based on data; some guesses are based on common sense; some guesses are based on research.
5 ways to determine what the user really wants to do:
- If there are peripherals plugged into a computer that the app can leverage, most likely the user wants to use them. Apple does a great job with this. If a headset or headphones are plugged into a computer, the system automatically uses them. It doesn’t ask “Do you want to use your speakers? Do you want to use your headset?” That’s just silly. And if the user wants to use system speakers and the headset is still plugged in – the user will catch on when he doesn’t hear anything. Skype handles this well too. If I’m trying to call someone through Skype, most likely I’m not going to want to use my phone. And if I do want to use my phone, I’ll probably use Skype through my phone. My phone number is there, but why would I use it? If I didn’t have a a headset plugged in, sure, I may to use a phone. Ask me that then.
- Collect data in the app and default to the most popular case. Apps can collect information about users and what they tend to use. If you create an app, try to do this. Web apps often do this. It’s free usability data!
- Usability Testing. I know, I’m being captain obvious here. But you can learn a lot from usability testing. Ask your users what they prefer in a session reviewing your app. I’m sure asking them question after question and showing the same screen all the time isn’t appealing to them. Let them give input into how it should work.
- Default to the most inclusive case and allow exceptions. For example, default to sharing the desktop and include a way for the user to narrow his scope. At least the sharing process is started and goes to the most complete solution. It is always easier to narrow; easier than having to select an option.
- Build a memory into the system to remember what the user typically does. If a user has a headset plugged in and frequently uses the headset, have that be the default case and give the user an easy way to do something else. Don’t ask the user every time what he wants to do. Or if the user always shares the desktop, offer that as the default. If the user often shares PowerPoint, default to sharing that. And if that app isn’t on, present a message on the screen reminding the user that app isn’t open and share the desktop instead.
Users don’t need to keep deciding. I think there are 2 reasons why we revert to this paradigm:
- We believe that asking more questions will direct the user to what he wants. We do this with phone systems. The challenge is that people will often select “0” in a phone system because the questions get tedious. .
- Microsoft introduced the option: “Don’t show this window again,” after confirming an action the user selected yet again. That’s not a usability strategy. That’s a way to get around building a system that remembers how a user works to create a personalized experience for him. Ideally, a user should select an action and the computer should execute it. Why do you need to confirm that you want to exit a program? The system should automatically save documents and close them. Sure, it takes extra work to program this in, but it’s far more user friendly and what a user expects to happen.
Stop second guessing your users. If your button/link is clear – they will do what is needed as they expect. Don’t make it harder on them.



