printf(“Design with your users.”);

Discuss the feature articles on the LDS Tech Home Page.

Do you agree with these principles?

Yes, I agree
15
100%
No, I don't agree
0
No votes
I have no opinion
0
No votes
 
Total votes: 15

User avatar
WelchTC
Senior Member
Posts: 2088
Joined: Wed Sep 06, 2006 7:51 am
Location: Kaysville, UT, USA
Contact:

printf(“Design with your users.”);

Postby WelchTC » Wed Oct 10, 2007 1:51 pm

A good friend and one-time co-worker of mine once sent me a postcard while on vacation. On the postcard was written the following:<stdio.h>

</stdio.h>

Code: Select all

#include <stdio.h>

int main(int argc, char ** argv)   
{   
/* Print the greeting */   
printf("Hello from California!\n\r");   
printf("My family and I are having a wonderful time.\n\r");   
printf("We went to the beach and to some theme parks.\n\r");   
printf("The weather has been wonderful.\n\r");   
printf("I should be back to work next week.\n\r\n\r");   
printf("Your friend\n\r");   
   
/* Exit the program with a success status */   
return(0);   
}
<stdio.h>

For those of you who are wondering, this is programming source code written in the "C" programming language. If this were an actual program on your computer, it would generate the following results when executed:

</stdio.h>

Code: Select all

Hello from Califonia!
My family and I are having a wonderful time.
We went to the beach and to some theme parks.
The weather has been wonderful.
I should be back to work next week.   
       
Your friend
<stdio.h> My friends and I had a good laugh at the postcard. Because we are all technical, we easily understood the message and identified with how the message was delivered (in source code). However, when I showed it to others who were not technical, they stared at it with a puzzled look. If they looked at the postcard long enough, they were able to get the message that the card was trying to convey. Once I explained to them that it was written in programming source code, they were able to understand why the message was written that way.

As technical individuals, we often assume that everyone using technology has the same background as us. We assume that if we can easily figure it out, others can as well. We assume that people understand technical jargon that is part of our everyday vocabulary. Because of this, I feel that we should not design for our users, but we should design with our users.

I remember a very important lesson that I learned about this principle. When Microsoft Windows 3.0 was first released, I wrote a personal information manager (PIM) program that helped people manage their day. This program had been well received by my co-workers and the company that I was working for. Everyone thought that the product had great commercial potential. Being an early adopter of the Windows platform, we were invited to go to Microsoft to show them the product. We showed the application to about 50 Microsoft employees, who appeared to receive it well. Afterwards I had a meeting with one of their top engineers, and we discussed the program. This engineer, a key developer on the Windows team, let me have it. He did not spare my feelings as he tore the program apart, mostly from a user interface perspective. He explained that because Windows was new to most people, we had to keep the interface simple and had to make it adhere to the standards that Microsoft had spent a lot of time and money testing and promoting. Most of my technical friends clearly understood how to use the program, but looking back, I can safely say that most non-technical people would have scratched their heads and wondered what to do.

Although I was somewhat humiliated by the experience by comments such as, "This is the worst user interface that I have ever seen," I learned a valuable lesson. Involve your users in the design of your application. Within a few short months of that meeting, and after long nights of programming, we released our product with a new user interface that had much more input from users and adhered closely to Microsoft’s standards. That product went on to become very successful and won many industry awards, including best product of the year by a large national magazine.

I'm not going to get into a technical discussion of rights and wrongs when it comes to user interfaces. There are numerous studies, style guides, books, and Web sites dedicated to this topic. However, I would like to share with you a few of the techniques and principles that I have utilized over the years.

The Spouse Test

I have always called this the "Wife" test or the "Grandma" test. If you can, take your spouse or some non-technical close relative, explain the purpose of a program (or feature), and then have this person try to perform a series of tasks. It will teach you a lot about what you can do to make your programs easier for users. Big corporations spend tens of thousands of dollars in creating usability labs where they invite individuals to try and perform tasks on software, and every aspect of their experience is recorded. I remember a few years back when I was at an international conference in Spain where a large technology firm was showing films that were shot at their usability labs. The films were of individuals trying to use some software. I learned a few new tricks, but many of the issues identified by these films are issues that I'd learned from observing my wife's experiences. I'm not saying that these labs are not valuable, as they clearly can teach us a lot about how humans interact with computers. I simply believe that many of the usability issues that these labs can teach us can be learned through simply having your spouse or other close relative use the software. The other benefit of using your spouse is that she or he is not afraid to be brutally honest with you.

Use Plain English


While working at Linspire, our focus was to sell Linux to the mass market as a replacement for Microsoft Windows. We realized that many of our users would not be Linux experts. Because of that, we spent a lot of time changing the names of various popular Linux programs. For example, we changed the popular Mozilla Web browser to say "Internet Browser," the popular instant messaging program called Kopete to just say "Instant Messenger," and OpenOffice Writer to say "Word Processor." Many in the open-source community criticized us by saying that we were trying to hijack the product and re-brand it. However, after talking with potential users, we realized that someone not familiar with Kopete would not know that it was an instant messaging program. This "re-branding" took us a lot of time and effort, but the results paid off and eventually the community adopted the standard of having a product name (Kopete) and a user-friendly name (Instant Messenger Program). Sometimes fancy product names or terminology just get in the way. It is best to use simple, descriptive terminology.

The 80/20 Rule


Rarely do programs progress over time by stripping features. New programs always gain new features. Program bloat does not seem to be diminishing. Many times new features just get in the way. The 80/20 rule states that you should make the features that are used 80% of the time very easy to get to and hide the features that are used 20% of the time. People learn step by step. Inundating them with many features all at once is both confusing and counter intuitive.

Ask, Don't Tell


Programmers are very good at telling people how to use software. When people have a question, we tell them how to solve their problem. What can be worse is that when a user questions our design, we go into a long discussion as to the technical reason we had to do something the way that we did. This does not help the user, but it may get us out of having to rework the user interface. When people ask how to accomplish a particular task in a program, instead of telling or showing them, ask them, "How do you think it should be done?" You will be surprised how much you can learn by what they say.

Use Standards


Use standards unless there is a very good reason not to. People get used to how something should work. They become familiar with common icons, phrases, and design principles. Don't try to reinvent the wheel. I remember several years ago when my oldest son was young and we were riding in the car. He had rolled the car window down. I asked him to "wind" it back up. He did not know what I meant by "wind." When I grew up, cars did not have automatic windows. You had a handle that you "wound" to go up or down. That was part of my vocabulary. However, to him, he simply pushed a button to move the window up or down.

Don't Be Defensive


Although listed last, I feel that this should be the #1 principle that you live by when working with users. Just because a user does not understand how to use your design does not mean that you are not an excellent programmer or designer. Don't be defensive and try to justify your design. Listen to all feedback and work with the users to figure out new ways to make the program more intuitive. By being patient and truly listening to what users have to say, you will gain their trust and confidence, and they will feel more committed to the project.

Let me know your ideas, principles, or comments about designing with your users.</stdio.h></stdio.h>

User avatar
brentboylan-p40
New Member
Posts: 9
Joined: Sun Sep 30, 2007 4:47 pm

Postby brentboylan-p40 » Wed Oct 10, 2007 3:58 pm

I while ago, I read "Understanding Usability" (I think that is what it's called.) By the time I was done I was aching to be a usability tester or consultant or something because of the number of websites I've seen that are horribly unusable--and I'm a geek. There is tremendous frustration on the end user's part when things don't work the way they think they should. Or you can't find what you know has to be there somewhere.

When the new MLS program came out I no longer had a calling that required me to use the ward computer. But I heard a lot of negative comments from the Ward Clerk about it. Mainly the fact that once he figured out where to find something it would be somewhere else on the next update.

I just thought of something. How about a "dummy" version of new MLS releases that the LDS Techies could have access to online to smash about, with fake data of course. We could run it through the paces before it goes live to give feedback, etc.

Oops. Got to go to Cub Scouts now.

User avatar
WelchTC
Senior Member
Posts: 2088
Joined: Wed Sep 06, 2006 7:51 am
Location: Kaysville, UT, USA
Contact:

Postby WelchTC » Wed Oct 10, 2007 4:07 pm

brentboylan wrote:I just thought of something. How about a "dummy" version of new MLS releases that the LDS Techies could have access to online to smash about, with fake data of course. We could run it through the paces before it goes live to give feedback, etc.


Interesting idea. I'll pass it along to the MLS guys. If they were to do it, there would need to be work done to disable certain features (such as transmitting information to the Church).

Tom

russellhltn
Community Administrator
Posts: 20779
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Wed Oct 10, 2007 4:47 pm

tomw wrote:If they were to do it, there would need to be work done to disable certain features (such as transmitting information to the Church).


Already done. There is both a test ward and test stake. When you enter those "magic" unit numbers, MLS will create the data for you. And yes, transmit is only simulated.

User avatar
brentboylan-p40
New Member
Posts: 9
Joined: Sun Sep 30, 2007 4:47 pm

Postby brentboylan-p40 » Wed Oct 10, 2007 7:07 pm

So is that for internal testing only? Are there 'beta' testers that act as end users?

russellhltn
Community Administrator
Posts: 20779
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Wed Oct 10, 2007 10:19 pm

The idea was to give the clerks a way to play with MLS and learn it without messing up the ward. While the idea sounded great on paper, I don't know as it really worked out all that well. See, the problem is, all the people are fictional. The person doing the testing has no idea if "Sister Brown" is a Young Woman, Married or an older Widow. So the names on the report meant nothing to the clerk trying to learn MLS.

User avatar
bhofmann-p40
Member
Posts: 272
Joined: Tue Feb 06, 2007 9:47 am
Location: Tulsa, OK
Contact:

Postby bhofmann-p40 » Thu Oct 11, 2007 7:06 am

Quick question for Tom. Why are you posting your blogs in two places? You seem to get better responses in the forum so I figured you might be testing the various methods. I was just curious.

User avatar
brado426
Member
Posts: 314
Joined: Sun Feb 11, 2007 9:50 pm
Location: Foothill Ranch, CA
Contact:

Postby brado426 » Thu Oct 11, 2007 7:56 am

tomw wrote:Ask, Don't Tell

Programmers are very good at telling people how to use software. When people have a question, we tell them how to solve their problem. What can be worse is that when a user questions our design, we go into a long discussion as to the technical reason we had to do something the way that we did. This does not help the user, but it may get us out of having to rework the user interface. When people ask how to accomplish a particular task in a program, instead of telling or showing them, ask them, "How do you think it should be done?" You will be surprised how much you can learn by what they say.


Many times there is added cost and time when trying to meet every user request. In my company, we usually try to negotiate for a realistic, cost-effective solution. Some of our users would have us developing for years and redesigning every single one of our other systems to meet all of their requirements. :) I understand the point you're trying to make, Tom. I just think there are many occasions where the user does need to be told how it is going to work in the spirit of saving time and money.

RussellHltn wrote:The idea was to give the clerks a way to play with MLS and learn it without messing up the ward. While the idea sounded great on paper, I don't know as it really worked out all that well. See, the problem is, all the people are fictional. The person doing the testing has no idea if "Sister Brown" is a Young Woman, Married or an older Widow. So the names on the report meant nothing to the clerk trying to learn MLS.


Russell: This is the exact problem I had with testing the HT/VT Reporting application. With fictional data, the individuals testing did not really know for sure whether things were working properly because they were not familiar with the names and relationships used in the test data.

Brad O.

User avatar
thedqs
Community Moderators
Posts: 1038
Joined: Wed Jan 24, 2007 8:53 am
Location: Redmond, WA
Contact:

Postby thedqs » Thu Oct 11, 2007 8:26 am

bhofmann wrote:Quick question for Tom. Why are you posting your blogs in two places? You seem to get better responses in the forum so I figured you might be testing the various methods. I was just curious.


It could also be to get more coverage. I just read the forms and not many of the blogs so I get to read his blog when he posts it here.
- David

User avatar
jeromer7
Member
Posts: 228
Joined: Thu May 17, 2007 11:46 am
Location: Bellevue, Nebraska

MLS Beta Testing

Postby jeromer7 » Thu Oct 11, 2007 10:34 am

brentboylan wrote:So is that for internal testing only? Are there 'beta' testers that act as end users?


Yes there is a cadre of MLS Beta testers. A stake clerk in a neighboring stake has been testing MLS Version 2.7 for several weeks. In fact, I noticed yesterday that MLS 2.7b5 (5th Beta version) was posted to the MLS download site with instructions on how any stake could participate.
JLR


Return to “LDSTech Featured Article Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest