Not Everyone is an Expert
I originally posted this on my blog but I think this audience might find it interesting. Yesterday I was having a conversation with the User Experience Program Manager on my team regarding two icons where one is supposed to represent an override of the other. It’s a deceptively simple problem. First, it seems there is no standard glyph for override. This means we have to invent something. As we set off doing this we have many things to consider. First, the icons have to be the same but different. Second, the differences must have meaning; we want them easy to understand and remember. For an expert user this is pretty easy. They’ll use the system everyday and quickly become comfortable with the icons. However, the novice user (or casual user) could end up getting lost and worse could make a bad decision if they don’t understand the differences between the icons. Most of the time it’s not readily apparent to customers or end users how much internal discussion goes into every detail of every feature; you just see the final result. If you could be a fly on the wall for a day, week, or month I think you’d walk away with a new appreciation of how difficult it is to develop great software and how much the SQL Server team loves doing it!
<Begin Original Posting>
In my day to day work I interact mostly with experts in the field of database technology and database administration. Every once in a while I get a gentle reminder that not everyone is an expert. Those reminders often come from forum questions from newbie and intermediate DBAs. When I come across one of these questions I’m thankful for it. It’s a great reminder that there is a spectrum of experience level out there.
Believe me, it’s hard work to make a feature easy for a newbie while at the same time powerful for an expert. One of the tricks we use to accomplish this is the script option on dialogs in SSMS. The dialog supports newbies (either new to SQL Server or new to the feature) whereas the scripting support gives them the option to learn what’s happening behind the scenes and build their expertise.
As we develop a new feature we’re intrinsically the resident expert. We take for granted certain knowledge of the internals. If we don’t challenge this we can easily end up shipping the wrong experience which can result in a few bad things, such as delaying the adoption of a new feature. One of the easiest ways to avoid this trap is to conduct usability studies early and often. We recruit DBAs of all experience levels and have them run through various tasks. Sometimes we got it right (when this happens we like to high-five each other and talk about how awesome we are) and other times we have to go back to the drawing board and make corrections in the experience (these are far more somber moments).
As a DBA I’m sure you encounter newbie through to expert users (other DBAs, developers, and end users). Do you change the way you interact with each person based on their experience level? next time you have a newbie come to you with a question, think about how you can help them become an expert.