In practice, a decision as important as redesigning an information system, whether it's a corporate portal, a self-service site (virtual branch), or a collaborative system, is a business decision that can have multiple justifications.
In user experience design, interface changes are recurrent, as are redesign processes.
However, a system can be redesigned not only because it has usability problems or lacks functionalities, but also for security, performance, to facilitate future maintenance, and to increase reliability [1].
Evaluating a collaborative system definitely has an additional layer of complexity compared to evaluating a system with which each user interacts independently. Some evaluation methods employ [2]:
- Heuristics,
- scenarios,
- specific models or frameworks,
- group task-based models, etc.
In the context of a collaborative system, the typical "task" we use for testing in a protocol with a user must be modified to consider the context of teamwork [2].
If you are part of a design or development team planning the redesign of a collaborative system, you have at least four complementary sources of evaluation solutions that you can use depending on the project context:
- Low-cost rapid testing, such as guerrilla testing,
- expert evaluation using heuristics and/or scenarios,
- methods based on ethnographic research,
- other specific methods.
According to Guy [2], unlike classic evaluation (where a single user interacts with the system), for collaborative systems, it is essential to have a holistic view, develop modeling, abstraction, and representativeness.
It is evident that none of the above can be based on a single evaluation format, and to have a holistic view, it is necessary to very well understand the relationships occurring between people and know the collaborative work context, in addition to evaluating a system for redesign.
Undoubtedly, Google Drive is one of Google's flagship products, so continuous improvement is both a priority and a sensitive area for its designers.
When making changes to a system with so many users, it is crucial to maintain control and avoid "change aversion", or the resistance of frequent users to interface modifications.
In "Minimizing change aversion for the Google Drive launch" [3], a paper presented at CHI 2013, the Google team discusses the importance of considering the learning curve in system usage.
In particular, being accustomed to a system means that even when faced with a change that should improve their experience, familiar users can show strong resistance to change.
In this regard, Google's design team draws on psychological theories, explores patterns of change aversion, and analyzes data from previous design launches to prepare for the new production release of an interface change.
As a result, they propose the following framework, which can definitely be very useful for any team working on a system redesign:
- Plan the launch stages.
- Evaluate user impact prior to launch.
- Prepare users for the planned change.
- Explain the benefits of the change.
- Offer transition support and assistance.
- Allow the user to switch from the new version to the old one. Note: This point is probably one of the most complex, as it is difficult to have two interfaces coexist, especially if there are underlying technology changes.
- Monitor and manage change over time.
- Allow users to submit feedback directly.
- Quickly address user issues.
- Tell the user what has been improved.
These tips seem essential to me for any team planning a major interface change. In my work at both Movistar and Sura, the constant question was: "How do we improve everyone's experience without creating frustration for some?"
Along with that, there was obviously the issue of satisfaction. In this regard, I also recall the problem raised by executives of an ERP system who told us that a simple button change, which was supposed to simplify access to information for customer service executives of a client company, could lead to a substantial increase in calls to the support service.
Why? The executives were used to making 5 clicks to reach a screen and did it almost robotically.
By changing the interface and making the same information available in 4 clicks, the executives got lost and could no longer find the information. Frustrated, they called the platform's support service.
Now, the question is: should you make a checklist, stick these 10 tips on your desk, and follow them to the letter? It depends.
Google tends to design exceptional services, and their team clearly has the expertise to do so. In the local reality, as a user and as a manager, one often encounters outdated digital services that definitely need to be improved or literally redesigned and rethought from scratch.
In very extreme cases, the gap between what exists and what the user expects or the average of what we are used to seeing in the market is so wide that applying each step to the letter would probably be unnecessary.
I just received an email from a financial company announcing a change in their digital interface. As a user, I would have liked to see the changes first.
For a system that has gone 5 to 7 years or more without concrete improvements, it is better to invest in testing and redesign than in communication campaigns to explain what will be changed, and should have been changed 5 years ago.
Conversely, when there is a constant concern for user experience and one perceives minor changes recurrently, it is appreciated to receive a communication announcing a new functionality or one that will be removed.
Have you participated in collaborative system redesign projects? Tell us about your experience.
[1] El-Khawaga, G. H., Galal Hassan Galal-Edeen, G.H., Riad, A.M. (2013). Quality Attributes and Software Architectures Emerging Through Agile Development: Pursuit or Overlooking? International Journal of Software Engineering (IJSE), Volume (4) : Issue (1).
[2] Guy, E. (2005). “…real, concrete facts about what works …”: Integrating Evaluation and Design Through Patterns. Proceedings of GROUP’05, November 6–9, 2005, Sanibel Island, Florida, USA. Copyright 2005 ACM.
[3] Sedley, A.Müller, H. (2013). Minimizing change aversion for the Google Drive launch. En Proceedings: CHI’13 Extended Abstracts on Human Factors in Computing Systems, ACM, New York, NY, USA(2013), pp. 2351-2354.
By 
