Posts Tagged ‘CGT 512’

I used to teach public relations. In public relations, your livelihood depends on details. If you send out a promotional brochure with spelling errors, it ruins credibility. In public relations classes, one spelling error in a final project would bring down a course grade by one entire letter. I assume that in professions such as engineering details matter even more. One misplaced number may result in a collapsed bridge and casualties.

Details matter for you, too. When you send out your resume, or even a relatively important email, lack of attention to detail, manifested, for example, in spelling errors, can cost you a job or opportunity.

You’ve done hard work this semester. Don’t let its value and your credibility be ruined by lack of attention to detail: Spelling, consistency in formatting and alignment, use of punctuation – these details matter.

I’m trying to proofread your presentations and reports and point out as many details that I can find that need correcting. But don’t let me do this alone. Pay obsessive attention to detail – as if your life depended on it. As if your grade would go down one letter grade for each small error. Without attention to detail, there’s no such thing as excellence.

This might be the most painful and the most important lesson you learn from me this semester.

Advertisements

Let’s assume you have a scale that measures a variable “hotness” on a scale of 1 to 5. According to most people’s intuition, 1 is less hot, and 5 is very hot. A shorter column in a graph means less hotness, a longer one means more hotness. It makes sense, doesn’t it?

Now, look at all your scales and all the graphs you created. Do they ALL make sense?

Sometimes, because of the way you laid out your answers in Qualtrics and because of the way Qualtrics assigns values to answers, you may end up with a reverse scale that is very confusing.

In the examples below, the scales are very confusing. In a culture that reads left to right, were things increase from left to right and from bottom to the top, the image below means that the actual difficulty was higher than the expected difficulty – but that’s not what the authors mean!

Similarly, when you look at the column graph below, you’d think the blue one indicates more difficulty, and the red, less. Alas, that’s not true…

Solution: Flip the scale!

For this measure, go into Excel, replace 5 with 1, 4 with 2, draw the graphs again, and voila! – they make sense.

In usability principles, this falls under consistency and standards – use accepted standards in your interface.

Please make sure to check your scales and graphs, make sure they make sense – in the generally accepted way in American culture.

I have noticed several times in the past that, although students write perfectly clear sentences in emails and blog posts, when they get into “paper writing” mode the quality of writing decreases dramatically: Sentences become long, wordy, and impossible to follow. Passive voice is used more often than it should be (as opposed to” They use passive voice a lot”).

Good writing is simple, clear, direct. Your writing will be easier to understand if:

  1. You use short sentences.
  2. You use simple sentence structures: Start with the Subject (Who is doing the action), follow with the Verb (the action) and then qualify as needed. In each sentence, Someone is Doing Something (Subject, Verb, Object). Try to stick to this structure as much as you can. Avoid passive voice: Something is being Done to Someone (Object, Verb, Subject).
  3. Use fewer words. Examine your sentences and see how many words you can take away without compromising  meaning. I tell students to imagine each word costs 10 cents. Try to save your money when you write.

As you write, the main goal you keep in mind should be: How can I communicate this clearly? – NOT: How can I sound more elegant/academic? Focus on the reader (user), not on yourself.

Here is an example of rephrasing a sentence to make it shorter and clearer:

First of all, the open-ended questions after the post-task questionnaire as qualitative research were asked to the participants to analyze the nanoHUB website usability.

Start by asking yourself: What do I REALLY want to say? Then, just say it:

After each task, we asked participants two open-ended questions.

Some more tips/reminders for writing the final report:

  • It’s OK to use “We” – as in “We conducted usability research.”
  • It’s OK to use numbers inside sentences, but spell them out if them out if they are at the beginning of a sentence: “Three out of 5 participants completed the task.”
  • Be consistent across sections. Use the same style. If you refer to participants as P1, P2, do so in all sections. If you capitalize Task 1, Task 2, then do so in all sections.

I know that one of the most difficult challenges of your final report and presentation is figuring out the most effective ways to communicate data. It takes scientific precision, artistic creativity, and great communication skills. It should be a fun challenge for graduate students – but, at this time of the semester, it gets quite painful, I know…

Take a break, watch the video below. It will remind you that there’s power and joy in data visualization:

 

Oh, and… never mind Power Point. Here’ the new requirement for your final presentation! /badjoke.

This post came out of a conversation my husband and I had with a group of students. How can we deliver successful projects? There’s no easy recipe, but here are two pitfalls to avoid and one tip to follow:

Overconfidence

I noticed that I make most mistakes when I’m overconfident. Overconfidence makes you take shortcuts and not give your full attention to what you’re doing. It prevents you from thinking about each aspect of your work carefully, cautiously, and with curiosity. It makes it easy to overlook important requirements, and not notice errors. Whenever you find yourself thinking “this is easy!” – do a double take. Try to look at the project with fresh eyes, as if you’re seeing/doing it for the first time ever. Try to see what you could be missing. Avoid disengaging and making rushed decisions just because you think you know. If you need an additional challenge to keep you engaged, aim to exceed expectations. See the last tip in this post.

Social loafing

This happens a lot in group work, and I’ve fallen into this pitfall myself. When you do a group project, you do your fair share of the work, and then you “outsource” proofreading and the responsibility for the final check to the group. You think that someone else will catch that spelling error or realize that there’s an important section of the report that you forgot about entirely. The problem is, every other group member falls into the same pitfall. And then, no one proofreads carefully and no one carries the responsibility of the final quality check. The product gets delivered with spelling errors or stupid mistakes that could have easily been caught if you (yes, you, not someone else in the group) had assumed the responsibility of the final quality check. So, this applies to every member of the group: Before delivering the final product, imagine you are the single author. There is no one else to proofread the report, no one else to catch errors. Look at it with the most careful and critical eye and assume sole responsibility of ensuring there are no errors.

Aim to exceed expectations

And finally, after two DONT”S, here’s a DO: Aim to exceed expectations. Most of us aim to meet expectations. We satisfice. We try to deliver a good enough product. But how many of us aim to exceed expectations? How often do you work on a project thinking “I want this to be the best report this teacher has ever seen!” ? If you aim for 100% (or more realistically, somewhere around the 95% mark), errors will happen, and you’ll likely end up around 85%, if all goes well. But if you aim for 150%, with the inevitable imperfections, your project will still meet or exceed expectations. The additional thoughtfulness, creativity, and motivation are very easily noticeable in someone’s work. So, don’t aim for “Meets Expectations” – aim for “Mind-Blowing.”

Remember that, the end-goal of conducting usability testing doesn’t stop at timing how long it takes users to accomplish tasks. Ultimately, we need to identify usability issues: aspects of the site’s design, organization, functionality that presented problems to users. Here is where your observations and the interviews provide useful data.

Make sure that, in addition to detailed and clear presentation of usability metrics, as discussed in my previous posts, you identify and explain usability issues. Your report should make it clear to the reader what aspects of the website presented problems.

You can identify major issues for each task, and have a separate section where you list the usability issues, and make recommendations for fixing them. Remember to be very specific about what the issue is and what your recommendations are.

When presenting this information on slides, I recommend placing each issue and recommendation on a separate slide. The slide could look something like this:

Screen shots are helpful here. If a screen shot refers to a specific URL, make sure you write the URL at the bottom of the image, so it’s visible and maybe even clickable. If you use screen shots in the slides, then you will need 2 slides per issue (one with the screenshot), and another one like the one above.

How do you decide what is the best way to present information? When should you use a table, a bar graph, or a pie chart? It takes a bit of thinking about the nature of the information and the message you want to get across – then, Excel can do the rest.

Here is a quick resource for you that explains a bit about making these decisions (link opens pdf).

I believe tables and bar graphs will be most useful to you. So, how do you decide whether to use a table or a bar graph?

  • Tables are great for presenting individual values, but if you cram too much information into one table, it becomes overwhelming. Tables do not facilitate comparisons. In a table, the reader has to search for comparisons among data and compute them mentally, then remember them for later. This is a lot of hard work!
  • Bar graphs, on the other hand, are great for rankings and comparisons.

One thing to be careful about are the sides of bar graphs: What do the axes represent? Are they accurately titled? If you display scaled along the axes, are they correct? Check what types of units you are displaying (absolute numbers, percentages, etc.).  When you work with 5 participants, one participant represents 20%. While marking 20% on an axis is technically accurate, it is a bit misleading. When working with such small numbers, I suggest being very cautious about using percentages, if using them at all.

Let’s look below at three ways of presenting the same information: Level of agreement on a 5-point SA-SD scale, where 5 is SA, and 1 is SD. Imagine the agreement is that the task was easy to complete.

The table presents all the individual values. Look at it for 3 seconds or less and answer: Which task was easiest to accomplish?

Here is a different view of the values each participant gave. It doesn’t show the averages, but, can a quick look at the colors give you an overall idea about which task was the easiest?

(Stacked bar graphs can be very effective. We saw a great example in one presentation yesterday of a stacked bar chart showing task completion rates).

Below is a simple column graph representing only the means for each task. You lose the detailed information about each participant’s responses, but you gain even more clarity about what task was easiest to complete:

The examples in this post are all useful for the first part of the results section, where you present combined results. Things should be much easier in the second part, where you present the data for each task. See my previous post for an overview of the three parts of the results section.