Recent comments

  • Reply to: Using Google Analytics To Make Decisions   5 years 9 months ago
  • Reply to: Mapping UX to Design   5 years 9 months ago

  • Reply to: How do we know what the user wants   5 years 9 months ago

    If we understand the problem or opportunity we are solving for. If we scope the work appropriately, and if we have analysts that engage not just the stakeholders or committees but the actual system users we have a chance of creating a good user experience.

    The job of the analyst is to understand the problem, the business domain, the business requirements and the needs of all stakeholders and users. There are a number of proven techniques an analyst can use to capture the user requirements and this process along with the associated artifacts enable the team (development, testing, stakeholders, users, etc...) to create a solution that enable all system users to accomplish their goals.

    For example, an analyst can identify user classes (groups of users that may use a system differently to accomplish their specific goals) and find champions within each user class. These champions collect information and feedback from the users and the champions provide the analyst with the user requirements. This analysis includes prioritization (the most widely used/important features vs. the nice to have/ infrequently used features) and defining quality attributes to the business/user needs.

    It is not magic; there are a number of proven techniques one can use to ensure a great user experience. The key is in the analysis, the engagement of users and stakeholders and the requirements. The essential requirements are typically fall under the requirement category of usability requirements.

  • Reply to: How do we know what the user wants   5 years 9 months ago

    I agree that this would be an interesting topic to explore further. The end goal of a practical and successful user experience too often gets overruled by design by committee. Navigating institutional politics is a realistic challenge that can often be overlooked.

  • Reply to: Common Sense and a Simple Approach   5 years 9 months ago

    It might be interesting to try using the Echo360 personal capture tool.  If it can deliver a live stream and recording this would easily allow remote observers, which is really useful.  It is cross platform.  And with Yale decision to make that the lecture capture standard it will be available to the community.  I haven’t had a chance to try it out yet, but from the descriptions I’ve heard it seems like it should work.

  • Reply to: How do we know what the user wants   5 years 9 months ago

    I like the idea of coming up with good patterns for user needs discovery. This could even be broken out into multiple focused sessions: requirements gathering, usability testing, focus group-ing, in-production end user feedback strategies, maybe more.

  • Reply to: Common Sense and a Simple Approach   5 years 9 months ago

    Morae is a great platform for capturing usability testing sessions, but (1) it runs only on Windows, and (2) it’s very expensive (~$1500), and may not be affordable for the comparatively casual usability studies many of us need to perform.

    CMI2 is historically a Mac shop (from the days of Paul Lawrence), so when we began doing usability testing in 2009 we went with what was then a $50 application (now $69) called Silverback, which did the core things we needed.

    What are the key things we want to capture when we record usability test sessions, and are there other applications that folks have used and would recommend?

  • Reply to: The Tale of the New Site   5 years 9 months ago

    How far in advance of the site going public did you invite comments? Why do you think there was general acceptance: did you already have a clear sense of what the department wanted, or did you luck out?  :)  What if there had not been general acceptance of the redesign at that point?

  • Reply to: Don’t Just Ask. Engage!   5 years 9 months ago

    Ricardo’s post suggests that we should solicit feedback from users not just once during a development project but “at various points.” I agree, but we’ve struggled sometimes to determine the best points in a project to bring in the target audience for input, and also the best type of input to solicit at different points.  Any thoughts on when, during a typical development cycle, to get which types of information from users? 

  • Reply to: Do-It-Yourself Usability   5 years 9 months ago

    This looks great! hehe

    Here's an awesome short course about designing good, usable interfaces. Specifically, how to determine what the audience wants and needs, and how to test designs rapidly and effectively.

    Weeks 1-3 of this course are particularly good:
    https://class.coursera.org/hci-004/lecture/preview

  • Reply to: Get your POINT across - 5 Steps to elegant data visualization   5 years 9 months ago

    That’s absolutely true! Data labels act to frame your analysis, and must be informative in creative ways.  Also, as in Hipmunk’s case, our labels can act as marketing tools; aknowledge the problem and provide the solution all in one label.  It’s also best if you can use labels in the users’ own “language”.  It communicates better with them, and translates complex data more easily.

  • Reply to: Get your POINT across - 5 Steps to elegant data visualization   5 years 9 months ago

    This is an excellent set of things to keep in mind with data visualizations. I'd also like to add that we need to make sure that we're using labels that our users will understand. Particularly with data, we often use words that are not familiar to our end users, or don't mean the same thing to outside audiences as internal ones. There's also an opportunity to use labels which do some of the work for us, by carrying a deeper meaning than just one word typically does. Hipmunk, a travel search engine, does this really well with their "Agony" sort order. It's just one word but it stands in for a lot of content.

  • Reply to: Don’t Just Ask. Engage!   5 years 9 months ago

    So true, and so important!!  Understanding “why” a user needs functionality is invaluable to the development of a feature.  The developer or BA gains insight into the business use of the product, and can then make informed decisions about the way something is displayed, calculated or tested.  So often the user is included for requirements-gathering, but never asked for the purpose or application of the product.  Learning “why” from the users goes a long way to making a feature effective and avoiding defects.

  • Reply to: The Tale of the New Site   5 years 9 months ago

    We did a major overhaul in the Physics department. I kept much of the structure of the old page but used my best judgement on other things. Before the page went public I held a departmental meeting to introduce the new site to the department and invite comments. There was general acceptance of the redesign and a few items which I "fixed" and/or added to the new page. All-in-all it worked very well.

  • Reply to: Common Sense and a Simple Approach   5 years 9 months ago

    Perhaps the idea of a usability community of practice (COP) with an action-based agenda – monthly open testing sessions, with applications rotating among members – would be of interest.  Let’s keep this in mind as a possible session for the conference.