Should UX designers be designing for the short term or long term?

I'm fairly new to UX design. I'm working with other UX designers who are trying to create a UX design for a demo coming up in a few month. I am suggesting that we should first have a design that accommodates the heavier duty version of the software that will come later down the road ... build the base functionality (decide on a menu, base functionality like allowing the user to have their layout). Then, for the upcoming demo, just implement those features management set as requirements for this upcoming demo.

Their solution was to divide the UX team into two sections. The section that things about the design due in a few month a separate section will design for the long term.

My concern is that the short term design will become the official design. It will end up not being scalable. The design for long term will be thrown out and that teams time will be wasted.

Would like some advice on whether a design should be for the sort term or long term and how to go about developing a design for the short term (throw something together to get feedback on) while still having something to display for the short term.

If there is any documentation on this topic that you could point me to that would be awesome. I'm not googling the correct phrases to get back any documentation related to this topic.

EDIT: The Story of the Ribbon has some great advice for redesign of already existing software. Excellent advice which is not counter-intuitive.

EDIT #2: Andrea comment helped me figure out a better google query. searching for "redesign of old software" gives a lot of good articles on how to tackle such a challenge. ex: How To Tackle The Ultimate UX Challenge: Legacy Systems

1 Answer 1


I think you have two issues here with two different answers.

  1. You are concerned about a design solution that is not scalable because you haven't designed for the "end" solution.

  2. You are worried that a lite version of your design will become the design.

Big upfront design is not very common these days as software changes all the time, and this change can be business requirements, it can be technical dependencies or it can be a new OS design standard for example. By designing something for its end state before handing it over to developers could take a really long time only for it to not work down the road.

I think instead of doing a long-term design solution, rather have a user journey or product roadmap (these will probably change too) which gives you the bigger picture. Then start designing incrementally. If it doesn't work once it's in dev, or feedback of a feature is poor, be open to changing it. Software doesn't end, it lives and needs to be updated all the time.

The second part to your question, what if the short-term design becomes the design.... Well if it solves the user's problem, then that's a good thing right?

Maybe this article will help clarify some of my points: http://sjmog.github.io/posts/503_software-design-up-front-how-much/

  • Thanks Andrea for the feedback. I forgot to mention this is not new software. This is existing software that already exists which is being ported over to the cloud. It needs to have all the functionality of the older software, but a 'cleaner' UX design. We are being directed to not look at the old design in fear that we will mimic the old design. However, this is dangerous because functionality could be left out or you spend hours created something that, low-and-behold was already in the old software.
    – Fractal
    Commented Jun 14, 2018 at 17:06
  • 1
    I see. You could create an inventory of all the functionality and use that as a starting point. You could also look at what are the Jobs To Be Done (jtbd.info/2-what-is-jobs-to-be-done-jtbd-796b82081cca) by the end user. This will allow you to think of goals versus pieces of functionality. I would also push back on not using the current software as a reference based on your comment above. It doesn't seem productive and you as a designer should know why this change is needed. Why do they want to update the UX? Are users finding it difficult to complete certain tasks? Commented Jun 15, 2018 at 15:45
  • Thanks Andrea. I completely agree with the need to inventory all functionality and use that as a starting point (this is something we are not doing, and seems dangerous). My critical question is, how do you get an inventory of all functionality without looking at the current design? I know looking at the current design can be a death trap; it can heavily influence your UX decision. But this is the contamination zone i must go into in order to get the jewels (functionality) which need to be in the new software (and implemented in a much better way).
    – Fractal
    Commented Jun 16, 2018 at 19:33
  • There is no good logical, rational, step by step documentation which describes how to go into this contamination zone and come out unscathed. Hopefully it will help if i keep this understanding in the forefront of my mind. Then get the jewels out of the contamination zone. After that, let my brain rest a while, and then go back to the jobs to be done and story-line (detailed step by step process user takes to do a task), main tenants and goals and go from there.
    – Fractal
    Commented Jun 16, 2018 at 19:39

Your Answer

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

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