Posts Tagged user needs

EHR Usability

Dilber Usability Comic

As I’ve mentioned in past blogs, usability is even more important in the development of EHR systems. Dr. Halamka gives an insider view of why usability is so important for the development of EHRs. Its a good read for anyone interested in healthcare and the implementation of EHR systems.

Leave a Comment

The Fable of the User Centered Designer

Book Image

I heard about this on Twitter the other day (sorry, I forgot who posted it!). It’s a wonderful little story to help explain some key usability points to teams who have a little time and want to learn more about what we do.

http://www.userfocus.co.uk/fable/index.html

Enjoy!

Leave a Comment

Dilbert’s company needs some user research!

I wanted to share today’s Dilbert comic. It cracked me up. The first thing I thought was, “They need a UCD person to get the user’s requirements right!”

Dilbert.com

Leave a Comment

One of my favorite usability cartoons

I ran across this while I was searching for an image for another blog. This is definitely an old example, but its still rings true. Enjoy!

Comments (2)

EMRs and Healthcare and the 2014 deadline

EMR Comic

Electronic Medical Record (EMR) and Healthcare discussions seem to be everywhere you go  now, whether its the crazy behaviours at protests or the worry about all this is going to be implemented. For those of you who are interested, here are a couple items that crossed my path in the last 24 hours:

Electronic Records For All Patients Mandated By 2014:  

Many who have worked in the medical record industry have been waiting for decades to have an increased governmental push towards adoption of electronic record systems. To date, development and adoption of these systems (of which there are many kinds of electronic medical records) has been an industry led initiative that has proceeded with fits and starts. The Act calls for electronic medical records for all patients by 2014.

Also, tonight there will also be a conference call with David Axelrod. If you are a member of the Organizing for America website, you probably received an invitation.  I registered late last night. On the registration form, you are given the ability to enter a question that might get answered during the call. One of my questions:

I know that having Electronic Medical Records is one of the goals of healthcare reform. I agree this is a wonderful goal that will help improve care. Doing this will be very complicated. Applications are regularly tried and have failed (you can see some issues here: https://tegloff.wordpress.com/tag/emr/). Designing a successful system will require a strong usability presence. I have not heard much about user involvement or professional usability designers being involved in this. What is the plan to ensure that whatever is developed will be accepted by the medical community?

I do believe we need to head in the direction of EMRs. I also believe that if we do not do it in the right way, it will not be accepted by the medical community and/or it could actually decrease the care patients get, rather than increase it. So, lets hope we get EMRs… and lets make sure usability practitioners are involved to ensure it is accepted by the end users!

Leave a Comment

Prioritizing Features

Last Friday I blogged about user features and how we should not give in to every request… Over the weekend, I realized I didn’t give any advice about how to prioritize these features. So, here I am to rectify that! A colleague of mine,  Matt Gregg , shared a technique with my old UX team. It’s called the Kano Method.

The Kano Method allows you to figure out which features really need to be included into your product. According to the method, each feature falls into 1 of 6 categories:

  1. Must have features. Users MUST have these features to purchase/use your product.
  2. Desireable features. These are really useful features that can add value to your product.
  3. Exciting features. Great bonus features that will excite and entice your user population.
  4. Indifferent features. These features are condered ok, but not really worth much notice from the user.
  5. Questionable features. Results for these featuers were not clear. There was conflicting data gathered. Quite likely, your questions were too confusing and should be rewritten, or the user truly does not care one way or another about the feature.
  6. Reversal features. These features may actual cause your users to stop buying/using your product.

To categorize the features, you use a specific survey style. Users rate each feature in a “functional” way and a “dysfunctional” way. So, for example, if you want to rate a password reminder feature. You would have 2 questions (functional and dysfunctional, respectively):

  • How would you feel if you had the ability to request a password reminder on the website?
  • How would you feel if the ability to request your password were not available on the website?

Another example (functional and dysfunctional, respectively):

  • How would you feel if a cooking website contained more recipes than most websites online?
  • How would you feel if a cooking website contained less than the average number of recipes?

Your users would then categorize each question using a set scale. Note: It is not a good idea to list these features and rate them using a Likert-style scale. The user needs to understand that this is NOT a rating scale, instead they are categorizing each feature.

  1. I like it that way
  2. I expect this feature to be in the product
  3. I am neutral
  4. I can live with it that way
  5. I dislike it that way

To analyze your results, you simply calculate how each feature was categorized functionally and dysfuctionally and use the following matrix to analyze the results:

 Kano Matrix

Think through an individual feature, e.g. being able to request your login password. Let’s assume this is a mandatory, must have feature that the user expects. For the first question listed above (How would you feel if you had the ability to request a password reminder on the website?), most users would select category 2 – I expect this feature to be in the product. For the dysfunctional version of the question (How would you feel if the ability to request your password were not available on the website?) most users would select 5 – I dislike it that way. Therefore, an “M” square would be selected in the matrix and the feature would becategorized as a must have.

Now, lets look at a more confusing item on the matrix. Let’s say our feature is addition of a jacuzzi to a hotel room. The functional question could be: “How would you feel about having a jacuzzi in your room?” Let’s assume most users categorize this as a 1 – I like it that way. Next, they read the dysfunctional question: “How would you feed about having a standard tub in your room?” We’ll assume users will select a 2 – I expect this feature to be in the product. So, we have a feature that users like, but it appears like they do not expect it, since they do expect the dysfunctional feature. On our matrix, this feature would be categorized as an “E” – an Exciting feature.

Features can then be ordered based on the priorities of your team and the users. One of the wonderful benefits with using this method is that you can prioritize user interview findings with a large audience very easily via  a web survey. Additionally, it can be useful tool when bartering with your team!

Leave a Comment

Giving users what they want… or what they need

My preschool son loves all the Herbie movies. He gets excited anytime he sees a VW Beetle and yells “Herbie!” and then proceeds to tell us all about him: “Herbie is a racecar.” “Herbie’s wheels and lights.”  You get the idea. We’ve been toying with the idea of getting him a Herbie of his own and finally decided to do it after a string of really good accomplishments (sleeping better, being good in preschool, potty training, etc.).

Two nights ago, we were walking downtown and saw a red, vintage Beetle. My son gets so excited that we run across the street to say “hello.” He proceeds to tell us to get the keys and get in the car. He wanted to drive. He wanted this Herbie. Little did he know his own version of Herbie was coming in the mail the next day.

Herbie - "first release"However, his version of Herbie is not a full size car. It’s a small ride on. It’s not exactly the right style (more like a modern VW). It’s not even the right color. Also, it has a parental override…. a remote control so we can make sure he’s safe. This is not what he asked for…. but its what he needed.

He still loves it. It’s the right size for him. He can reach the pedals. He can steer. It has a funny horn sound and blinking lights. He is disappointed in the color. So, for the “next release” we will update his new toy with a white paint job and Herbie decals – already arrived from Ebay. However, overall, he is thrilled with it.

Now, I’m not saying that all users are like preschoolers. However, as usability professionals, we know our users will sometimes ask for more than they could want or need. Some features, no matter how cool they sound, are just not the right thing to include. Some features would actually hinder the user’s interaction with the software. For example, would it make sense to give my little boy a full sized VW? No way! Its much too powerful and big for him. His new little bug is just right!

Leave a Comment

Older Posts »