Archive for Uncategorized

World Usability Day 2012

So, it’s that time of year again! World Usability Day is coming up! Not heard of it? Check out their global site: World Usability Day

This year’s World Usability Day theme is the Usability of Financial Systems. This should be a huge theme for St Louis. We will celebrate the day at the St Louis Science Center on November 3rd from 10-2. Come check it out! Or, better yet, contact me and volunteer! All volunteers get a T-Shirt and free parking for the Science Center. I hope to see you there!

Leave a Comment

Issues with Skype’s Firefox add-on, slows down Firefox (and, thus, Protoshare)

Just as a quick heads up to all of you out there, I was working in Protoshare and it was running painfully slow. It turns out that Skype’s Firefox add-on can slow down Firefox tremendously. By uninstalling the add-on, everything came back up to regular speed and Protoshare was working beautifully again!

So, if any of you are having Protoshare speed issues ( or Firefox browser issues) and also have Skype installed, check out your versions and try uninstalling (or, at least, disabling) the add-on.

Some other people were having the same issue:

The versions I’m using…

Firefox: 3.5.3


Good luck and happy prototyping!

Comments (1)

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!”

Leave a Comment

Colors and Emotions

Colors can play a large roll in website design. I recently read an interesting blog about colors and a dentist’s website that illustrates how the wrong colors can affect a user:

Comments (1)

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: 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

Balancing User Needs… aka Bartering


In a perfect world, user needs would rule and the usability engineer can change any detail on the interface and add/remove any feature based on user interview data….. but the real world doesn’t work that way.  In reality, there are deadlines to meet and a lot of people who have a say in the final output. The development team has its own beliefs about what should go into the product and how it should be designed.  Additionally, they have to worry about the feasibility of building the actual product. The product team also has their beliefs and a vision that may go beyond what the users are currently thinking. The sales team wants something that will demo well. Even if the “demo-able” features are not always useful in the real world. So, how do we deal with this?

I try to really think about each of the features. I always ask for the entire list of changes/features that the user data points me to; however, sometimes I have to be willing to barter. Learning what to barter is where the art comes in. Any good usability engineer will rank or prioritize everything they feel should go into the design. Based on this prioritization, you can design what HAS to go into the site and what can be dropped. I try to ask myself the following questions:

  1. Is this something the user actually NEEDS or does the user just WANT it? If its a need, how many users need it? Is it something everyone needs? Then it should be high on the priority list. If you are told it is not possible to build, talk to the team and find out how much of the feature can be implemented. See if it can be completed over the next couple of releases, but try to get it in. If its a want, you can haggle. Let the team know you can push this feature off, if you get some more NEEDS in. 
  2. Will it hurt the users interaction with the site if its added/removed? This is not a feature that should be bartered with. If removing an old feature or adding a new one will actually cause difficulties for the user, it should not be done. If it is something that’s required for a sale, see if you can put it in the least harmful location.
  3. Is this a feature/design element that YOU want (as the designer) or does the USER actually want it? Sometimes, it is possible to get your wants for the software confused with what the user actually wants. Stick with the user data and this will not be a problem. If it is something that you like to add to sites as a value add, etc., it can be hard on your ego to let it go. However, remember that our job is to speak for the user. These are the items that we can barter with. Let the team know you can drop this item in place of something the user NEEDS.
  4. Is the item something someone else in the team wants, but the user hasn’t requested? Again, think “Will it hurt the user?” If not, and it will give you some good grace with the team to put it into your designs, do it, as long as it doesn’t interfere with the release of features that are required for the user to complete his task. 
    If you scratch my back, I'll scratch your's
    If you scratch my back, I’ll scratch your’s

Remember, everyone on the team wants the product to be a success.  If we all play nicely, we can build products that the entire team has been able to give input into and that fits the users needs.

Leave a Comment