Artwork: Refreshing the artwork for the product

What is the artwork for a software product ? The artwork for a software product is all the visual imagery that is used in the product. This could be the application icon that you see in the top left corner, this could be the image that you see when the product is being loaded, this could be the icons on the various dialogs and screens of the application. If you ask an engineer on the product development team, he could not care less about the artwork (some are concerned, but most would be concerned about the impact of delivery of the artwork on the overall schedule and the screens on which they are currently working).
Why is the artwork important ? Well, you could also buy some simple stock images and icons (or get them designed from innumerable free or low cost options available on the internet), but the problem is, the artwork is part of the overall branding of the product and has a significant role to play overall. For those who monitor the overall branding of products, when companies make a change in their branding or in the icons, it is a big effort.
From time to time, there is a need to refresh the artwork used in the product, it makes the application feel fresh. It is not so easy to perceive, but users get a bit jaded when they see the same artwork, the same icons in the product across different versions. When the artwork is refreshed, it gives regular users of the application the feeling that they are seeing something new, even though reviews may not give too much importance to the change in artwork. Further, when there are changes to the look and feel of the operating system on which the application works, there is a need to make changes to ensure that there is a sync between the operating system and the application. For example, it could be that the new operating system has icons that have a certain amount of transparency, and applications that do not have the same kind of look and feel stand out (and that too in a negative way, not positively).
However, refreshing all the artwork, or even part of the artwork is not an easy task. It cannot be done without an expert - you have visual designers who talk to the product management, who talk to the product team and senior management, who talk to the customers (we actually had meetings with a group of customers to get their feedback on different sets of proposals for new artwork to see which seems to work, and which does not).
The artwork design and creation process has a separate schedule and is normally done outside the base product team and their schedule, so there are some complications that need to be overcome. The project / program manager needs to ensure that the schedule for this delivery has to be done before the dialogs overall delivery is complete, including some time for evaluation and review, and rework. And then the dialogs / screen would need to be shown to outside reviewers to get their overall feedback and impression, and corresponding changes would need to be done.
There is further impact. Since the artwork is changing, all the screenshots of the application in the Help documentation (in the base language and in the other languages in which the application is available) need to be changed, and this can be an intense effort that takes time and a lot of work (including testing that the change has happened in all the languages).

Supporting previous versions of the software (Part 6)

The previous post (Supporting previous versions of the software (Part 5)) talked about a team trying to make a decision about whether to drop support for a previous version of the software or not. If you are a user who is impacted by dropping support for the version of the software you are using, you would think that the team has taken such a decision without thinking about users. However, such decisions are not taken without a detailed discussion, and maybe after thinking about this decision at multiple levels before the final decision on dropping support is taken. However, it can be the exact reverse decision that could happen. With some serious defects having risen, the team has proposed that these cannot be fixed easily and also because these problems are for an older version; however, when a decision is finally taken, the decision is the exact opposite. The support for the previous version is not removed, and infact, the team is told that with these severe defects, there needs to be a fix provided to users.
With this decision, it can provide quite a challenge for the team to provide the dot release / patch for the release, but not impossible and hence they have to plan for it. There are a number of parameters that need to be considered, evaluated and a solution found for all of these. Some of these are (this is not an exhaustive list, if you see more parameters, please let me know through comments):
- Whether to release a dot or patch: What is the difference ? The terminology could vary, but typically consider 2 different kinds of releases ? One is where you have a simple small executable that just updates the few files required for the fix, while the other is a complete release that essentially replaces the application that they have on their machine. The reasons for deciding which method to use is also complex; it depends on the number of files to be updated, as well as the actual mechanics of issues such as upgrades, dependencies, etc. This decision is typically an engineering decision.
- Number of resources to be used for the release: In most cases, teams do not get additional resources for handling such updates unless they are doing this on a regular basis. So, some amount of work estimation needs to be done to determine the number of resources needed, as well as the schedule on which they will be needed.
- Support from external teams: For any product release, there is support needed from additional teams such as testing, installer and release, documentation, etc. Even if there is a small update to be provided, there is a need to ensure that these external teams are in place and committed to the effort, This can be a challenge sometimes.
- The timeframe for this effort needs to be decided: This can be a challenge sometimes. Typically a dot or a patch needs to be released pretty quickly, and there is a need to optimize to ensure that the existing engineering work for the current version is not impacted. This schedule can be a challenge, since the priority will remain the work for the existing release, and yet there needs to be an update.
- Update problems / engineering issues: Whenever an update / patch / dot release for a previous release needs to be released, it needs to be checked with the application installed on the user's machine. This includes ensuring that the application continues to work fine with the update, including the standard checks. This means that the team needs to install previous versions of the application and even replicate the operating system version that some of the customers might be having.
- Informing the users through support teams, forums and so on. There needs to be a campaign to inform users about the impending update release and ensure that feedback needs to be taken quickly when the update is released.