We are in the process of redesigning a legacy type system with broad range of feature sets. For practical reasons, we'll be implementing changes incrementally. In the past, our users are used to feature releases, where there's something "shiny" with each release. Now they'll be getting a series of releases that don't seem to be providing anything new, because these are interim designs needed to set the product up for the new design.

What is a good way of releasing interim designs and communicating the end goal to the users?

Some thoughts:

We can hold off user release until there's a big enough change to the design to make it obvious. That'll make it more work for the dev team to maintain and potentially slow down the redesign. This is also a frequently used system, users may not adjust well to sudden large changes.

Or we can release incrementally as things are completed, and pair it user communication. We have a lot of communication tools at our disposal: in-app messages, email newsletters, webinars etc. If I put myself in the shoe of most users though, I tend not to pay attention to messages too much. Without understanding that these are interim changes, users may feel we are making arbitrary changes that slows down their workflow.

Or we release mini "shiny" features with the incremental changes as a way of appeasing the users of these interim changes?

  • Is this a Web app, or client installed software?
    – tohster
    Feb 26, 2015 at 5:06
  • @tohster This is a web app operation on a software as a service model.
    – nightning
    Feb 26, 2015 at 17:02

2 Answers 2


I think your instinct is right, and you may incur user fatigue if you pepper users with info-emails. That's not good: once users are fatigued with emails from you, it's very hard to get their attention in the future.

Obviously you are aware of this because you're asking the question, but UX means more than just the user interface on an app....it also involves managing the entirity of user experience including communications, training, and community around an application.

I would ask the following threshold question:

Do the small updates require any user training, or are they really just minor cosmetic updates ahead of a bigger release?

  1. If no training is required

    • It would be better to do a "big bang" release, but if your dev team can't deal with that, then I would just roll out the minor changes with no announcement, and save communications "ammunition" for the major release.

    • If you start getting questions / queries on the minors, then you know that users care and you can put out a site announcement to let folks know that you are rolling out some minor changes over the next few [weeks] and they should not worry. This will "cover" you for the next few minor releases so you don't have to communicate anymore.

  2. If training is required

    • Then you have no choice: you need to communicate with users even on the minors. In this case I would really try to push the development team to minimize the number of releases by batching features.
    • Then, you can roll out fewer updates and correspondingly fewer communications.
  • Good point with the comment about user fatigue, I didn't really consider that. Yes, it's best to save the more involved contact methods like emails for significant changes.
    – nightning
    Feb 26, 2015 at 17:27

I am facing very similar challenges and it's still work in progress, but here are few suggestions:

When, what and how to release:

In principal you should release incrementally either “smaller user stories” or “Epics” but more focus should be given to smaller stories that have bigger impact. In my opinion big bang releases misses a lot of opportunities where you could engage with your users and inform them of where things are heading.

How to best communicate releases

In-app messages VS Emails:

Establish a clear distinction between release messages and other in-app messages in way that attracts attention to enhancements and features. Compared to emails this has a clear advantage as the information is delivered in context along with any visual emphasis you wish to include.

Emails could be delivered in conjunction with above along with other communication material to enhance improve corporate image. So using email here has a much larger scope and should be treated accordingly. For example email would be better at communicating end goals with the caveat of course of not over promising and under delivering:)

When to communicate:

Consider current pain points in your user journey as a guide; when you have developed a feature or a functionality that solves a problem or enhances a frequently used but broken process there is enough reasons to celebrate it using both in app and email channels.

In line with the above, user stories in conjunction with kano model should give you an indication of the level of frustration encountered and the problem solved so you can decide weather it deserves to be communicated if at all, below is my take:

1-Stealth mode:

No communication required as these features are typically cosmetic and minor changes that will generaly go unnoticed. According to the Kano model these enhancements are an generally an:

Attractive Quality

These attributes provide satisfaction when achieved fully, but do not cause dissatisfaction when not fulfilled. These are attributes that are not normally expected, For example, a thermometer on a package of milk showing the temperature of the milk. Since these types of attributes of quality unexpectedly delight customers, they are often unspoken.


Indifferent Quality

These attributes refer to aspects that are neither good nor bad, and they do not result in either customer satisfaction or customer dissatisfaction.

2-In-app only:

Communication limited to in-app messages as the feature or functionality developed results in removing user pain point.Below is how the Kano model describes these types of features.

One-dimensional Quality

These attributes result in satisfaction when fulfilled and dissatisfaction when not fulfilled. These are attributes that are spoken and the ones in which companies compete. An example of this would be a milk package that is said to have ten percent more milk for the same price will result in customer satisfaction, but if it only contains six percent then the customer will feel misled and it will lead to dissatisfaction.

Both email and In-App:

When the feature or functionality developed is a must have and will have a negative impact on the user if it wasn't implemented. here is what the Kano model has to say:

Must-be Quality

One of the main points of assessment in the Kano model is the threshold attributes. These are basically the features that the product must have in order to meet customer demands. If this attribute is overlooked, the product is simply incomplete. If a new product is not examined using the threshold aspects, it may not be possible to enter the market. This is the first and most important characteristic of the Kano model.

  • 1
    Thanks for bring up the Kano model. It's a pretty good way of determining what constitutes a shipping item when your team follows agile (SCRUM) development practices.
    – nightning
    Feb 26, 2015 at 17:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.