...
Heuristic | Severity Rating | Screenshot | Problem | Solution |
|---|---|---|---|---|
Learnability & Efficiency | Minor | | In our Messages tab, users are required to select a conversation before writing a new message. Although a grey banner with "Select a conversation to the left" is displayed to inform users of this requirement, during testing, two of our users tried to click inside the message text area box to begin writing their message before they realized they first had to choose a conversation. One user commented that this threw her off a bit, and she felt like |
|
Safety & Learnability | Major |
| Pressing enter in the text area for messages causes the message to be sent rather than creates a new line |
|
Learnability | Major |
| She tried to click on the message icon itself within the wrong context to see the message, said it was confusing that the message icon went away and the conversation wasnt selected (she said she never saw the message) |
|
Learnability | Minor |
| Thinks the several conversations as being confusing: where names are no longer listed because of too many names, said shes not sure even with icons who is selected because they are so small (less helpful to identification, subject heading would be better) |
|
Efficiency | Minor |
| Having a way to automatically bring up a group of students under a title would be helpful |
|
Efficiency | Minor |
| Tried to send grade report without selecting SMS or Email (not internally consistent with messages, need to fix) Teachers time is very pressed, its good to have a simple layout and not have too much customization (SMS or Email, for example should already be checked), needs to be quick and simple |
|
Learnability | Major |
| the way conversations are displayed, labeled, scale them to how many messages have been sent, and sort them in a more intuitive way (would have expected to see most recent message listed first, not by people) Confusing to have the most recent conversations that person was involved in displaying , useful but not intuitive, make it more clear with a title or something |
|
Reflection
Reflection
As our group completed our development of CheckMark, we had to make significant choices that changed the outcome of our project. Over the course of the iterative process, we learned getting through each iteration cycle as quickly as possible allowed us to move quickly and incorporate the maximum number of important changes into our design. By continually and constantly challenging our design, we improved it in look and functionality as well as developed a thorough understanding of why every piece of our design existed and was placed where it is. Although we are extremely happy with our finished product, in hindsight, we may have done a few things that made our lives a little bit tougher when it came to the implementation. Below are a few sections on how we made decisions with regard to aspects of this project, and what we would've done differently.
Paper Prototyping: When it came time to paper prototype CheckMark, our philosophy was to make our prototype as realistic as possible to ensure that the testing provided maximum insight into the usability problems and features of the future CheckMark. During testing, we received a lot of good feedback (and some contradictory feedback) and incorporated the most common criticisms into our big design changes. Making design changes on smaller, less significant issues did pose a problem because as a test, it was hard to understand how some specific features would translate to the computer medium. Things we would've done differently: - Although we did this with small features, we could have tested more effectively if we had included several different versions of the prototype. This was difficult to do partly because of the time constraints, but testing may have given us more insights if we tested a few different designs at once. - We created our paper prototype to be as realistic as possible but this made it difficult to change our prototype during the actual testing. Our paper prototyping may have benefited from modifications after each individual test, but we would have had to lower the authenticity of our prototype.
Computer Implementation and Testing: When we implemented CheckMark and began testing it with users, our goal was to ensure testing of realistic use cases and to design for the most difficult aspects of the parent-teacher communication problem. For example, we explicitly decided not to include functionalities like creating users with preferences and settings because such design aspects are well researched and nonunique to the problems addressed by CheckMark. We also did very well planning our implementation so that we didn't have to change too many of our data structures when we added that back end. Things we would've done differently: - We met often and communicated frequently, but it was difficult assigning different big parts of the interface to different people and just letting them lose on it. It might have been more efficient and things might have fitted together better if we had instead wrote out all the tasks needed to implement the interface on a lower level and assigned tasks to each person. -Although user testing was still extremely useful, it might have been more useful if all our group members were present at every user testing instead of splitting the testing up among pairs. It may have helped us have more efficient discussions about incorporating changes as well as fairly addressing the widely varying (and sometimes contradictory) usability concerns.
Despite a few small changes to the way our group approached this project, we are extremely happy working with each other. We all put it a large amount of time to ensure the success of the CheckMark and are happy with the outcome.
As our group completed our development of CheckMark, we had to make significant choices that changed the outcome of our project. Over the course of the iterative process, we learned getting through each iteration cycle as quickly as possible allowed us to move quickly and incorporate the maximum number of important changes into our design. By continually and constantly challenging our design, we improved it in look and functionality as well as developed a thorough understanding of why every piece of our design existed and was placed where it is. Although we are extremely happy with our finished product, in hindsight, we may have done a few things that made our lives a little bit tougher when it came to the implementation. Below are a few sections on how we made decisions with regard to aspects of this project, and what we would've done differently.
...