We work in a high-production educational environment. Having formal documentation helps make sure we don't forget steps. Because we have a fixed audience (44 physicians) and reuse interactive elements that have, individually, been thoroughly tested, we have a streamlined but extremely important usability testing process.
Much, much less chaotic development cycle. Using formal, documented procedures allow for enhanced communication. We also use tools such as Wiki pages and a Moo client for internal collaboration. All of these standards and documents tend to be rather fluid during the development lifecycle, which is why communication is so important.
Presenting identified usability issues in the context of recommended follow-up activities provides developers with concrete means of rectifying usability concerns. A usability practitioner is never going to win an opinion war with a developer, thus speaking from actual user experiences during user testing rather than based on expert opinion has proven instrumental in obtaining developers' buy-in to necessary changes.
Developers have been getting accustomed to reserving time on the usability lab calendar, using the scenario writing template, and recruiting users. The web-based reporting format we used has been very well accepted. The bug-tracking is relatively new so we'll have to see how that goes. It might seem like we are policing.
Our own documentation doesn't impact developers as much as our ability to provide a repeatable service for each project, and so we may quickly train new usability specialists. The GUI standards are managed by another group. We simply point developers to that reference.
We also developed a database for HEs and logging customer engagement activities. We found that the tools we use assist in the completion and tracking of our activities.
Developers were part of the initial buy-in on the project. Has helped move them away from ""designer-centered"" work to more ""user-centered"" work.
I instigated and run most of the usability training the company which has dramatically increased awareness of hoe every discipline within the team is affect by and affects usability. Knowledge of usability and its goals within the team has also made my job easier
Usability defects tracked as product bugs was critical to having usability recognized as a valuable contribution. Developers and marketing now expect certain things of a usability report. I use the CIF with some modifications. regular usability testing has established the value of the tests independent of product release cycles. Usability activities have been part of this company since 5/2000
Since we are ISO certified and FDA approved, having a process means usability is more likely to be included. At the present time, feature development includes usability testing.
They clarify the role of usability and when to become involved
Documented roles allowed us to educate developers in what we do. Documented d eliverables helped create awareness of our abilities and developers could tweek their portfolio of deliverables to match our offerings.
It's helped them better understand the usability program's role, what we do, how we do it, and our overall goals. Also let's them physically ""see"" what needs to be improved.
Clear timeframes and deliverables help manage client expectations of what goes into each deliverable and what results.
Our formal processes let our development teams know what to expect from us when it comes to preparing, conducting, and following-up on usability tests. Our reference materials let us give feedback without appearing to be arbitrary, i.e., it's in the guidelines, you could have done it this way from the beginning. Training helps us bring our developers up to a consistent level of design sophistication.
The roles and deliverables serve us well in setting expectations for project teams. We could probably benefit further from having timeframes and follow-up activities in place, but we have found that there is a good deal of variation with these depending on the nature of the project...some projects enlist our services early, many do not...this affects the timeframes we establish.
Support the credibility and value of the team.
The roll out of our interface standards has created more dialogue with the senior leadership team than the developers. Over time, more developers are using the standard and providing feedback on how it could better help them.
Documented deliverables are important so developers see the cause and effect relationship of usability problems, and so they and the project managers can see concrete results for time & money spent on usability testing.
If we file a bug, they have to respond to it. The bugs are the results of our testing, so those issues are addressed.
Increased communication; better design decisions;
The formal standards provide a basis for discussion. They also make the discussion objective so that it is easier to avoid the feeling of personal criticism.
Guidelines make easy reference points and assist with QA analysts.
Tremendously, they give you data to back up design decisions
The design standards have been seen as a big plus in communicating with project teams. They really appreciate having the information up-front rather than through a review later on in the development cycle.
Although my company purchased an off the shelf standard, they did not follow through and roll it out to the development teams. I do refer to the standard whenever I want to make a decision, or occasionally to show a developer why they should make a certain decision, but it lacks the power of ""we do it this way"", which is what I would like to get to eventually.
Design standards remove my recommendations from the realm of personal opinion (which is easily disregarded or argued about). GUI bug tracking is seen by CTO, who is more receptive to usability issues than is the project manager.
Some of the above, such as deliverables and timeframes, we do have, just not documented. We work very collaboratively with our developers. The results of our usability/user research activities contribute to the design and interaction of the product. Having data to back up our recommendations helps ease the interaction with developers.
We are small enough that we can do much of this informally and have things come out OK. But we do need to become more formal, esp. as we grow.
This organization is in the early stages of accepting and adopting user-centered design principles. We run pretty lean. We utilize books, materials and/or courses that have been developed by the ""experts"" in the field. I have a good relationship with the developers and work very close with them. The developers have been involved with contextual inquiry sessions, building prototypes, and testing those prototypes with users.
Our developers have been extremely receptive. They understand that usability studies allow them to remove constraints from their ideas and go for any design they have in mind. Testing will take care of the rest, whether it is to pull back or go forward.
None of the above at the moment - this is my aim with this study - to get these in place, part of the product development cycle.
The most useful thing WRT developers is that usability has been a priority from the founding of the company; it's just been assumed that all developers will draw on our skills. Then we did a good job and provided value that could be proven ""went right to the bottom line"" in terms of improving the effectiveness and profitability of the products. Developers have been ""coming to us"" for a long time and right now with our diminished staff we actually have developers clamoring for more usability involvement than we can provide - have to prioritize. I think for a small company like ours ""having processes in place"" is less important than having COMMANDS come down from on high that's usability is important - and I guess the second most important thing is that the usability people (three different staff in all) have been high powered and enthusiastic and selling constantly.
Our developer are not really engaged by the formal process that exists within the organization. We engage them by building relationships with them that lead to mutual respect for what each of us is bringing to the product dev cycle. They respond to tangible contact and feedback from real customers/users and not to usability platitudes. When they feel the users pain, they act on the problem.
These tools constrain more than help! We work in a more user-centered development cycle.
We're working on standards in our ""spare time"" ;-) Our developers don't design GUI's, we do (but we'll teach them if they ask). Usability is central to our development culture - so developers don't fell like they need to ""engage"" with us, we're just there from the beginning of every project. I think the biggest factor in engaging with developers is that we are not a separate part of the organization, and they respect our specialty as we respect theirs.
No repeatable tools exist between projects. Each set of developers requires a different approach so all usability techniques are re-evaluated on each project.
Our best tool is daily free access.
User scenarios are great for pre-release products.
By giving us the correct parameters to develop.
This survey is not addressing the environment of a consultant at all, since every client varies. These things are worked out with clients one at a time. I can only control what I put in my proposal, and even then it can be changed.
These are actually things which I develop and deliver to clients based on standards, rather than a static set of documents.
Helped to some extent - the html prototype is the only thing they really interact with. They have benefited to some extent. Requirements are more tangible.
The developers do respond to the written results of usability studies. These results are prioritized in order of impact on the user and suggestions for fixes are offered.
in previous project, we were to follow a standard design which was inadequate to address many of the design issues we encountered. in the current project, I designed and wrote the standard. I am also the enforcer of the standard.
Yes greatly.
Accountability
Developers prefer to be informed in their (formal) language rather than to learn usability from the human factors basis.
These tools have mainly been of aid to the designers who work directly with developers. Tracking tools for UI bugs have been in place before Utesting was even part of the mix.
Having them sit in on usability sessions or user visits (sort-of CIs) has opened their eyes -- wide!
Hard to say. Documented doesn't mean implemented..:)
Prototyping helps get developers into the process early, as we try out many different functionality scenarios
From the initial onset to finished processes.
Absolutely.
Some of these are not formally documented, others are. When we don't have a formal document, we follow the same procedures and use the same templates for final reports, tracking results of usability tests, etc. If developing a Windows-like application, we follow Windows standards. For Web applications, we have developed a common look and feel for our systems, which we have developed over the years, based on our usability tests. In terms of ""engaging with the developers,""some are more than happy to let us take these burdens off their shoulders. On a project-by-project basis, formal time frames and bug-tracking do occur.
Works OK. Developers need to be pushed to implement HF recommendations.
This is an odd question. It gives the impression that you consider that documents of these types are important or necessary, and that these are the full list. I use documents describing how to do usability activities all the time, but none of them fall within your list.
The product of the usability test is a usability report; however, I feel there are few guidelines for making the reports effective--i.e., the reports are great usability reports, but do they necessarily appeal or are they useful to developers? I would almost guess that streamlining the usability process through standard reporting has made it considerably easier for developers to overlook usability.
These just set a standard but they are not set in stone. We are open to new methods, types of studies, deliverables etc.
Our timeframes and deliverables are done on a per project basis depending on the complexity of the issues and development timetables. We generally bid approximately 3-4 weeks per usability test performed in the lab, and 6-8 weeks per study performed in people's homes. Walk-thrus take approximately 3-5 days. All times include data analysis and final report preparation.
Plan to have a ""brown bag"" periodically covering GUI issues for developers.