When creating a new function within an existing system, the users I test my new concepts with are familiar to everything around it. So my wireframes also contain many old (but non functional) components.

If my new function requires selecting a specific existing(!) link or dropdown-element to start the action, how can I "tell" the user to use it?

Arrows and speech bubbles distract or guide to much. Only displaying those elements that are required for the action destroy the "feeling" of using the program and make abstraction difficult. And for documentational reasons I don't want having to brief every user.

I need some sort of solution which is in between, self explaining. Something subliminally indicating: "click me!".

  • 7
    It depends on the situation, but I'd assume part of the point of prototyping new features is to find out if existing users can find these new features in the first place. Just tell them "can you now go complete {task that can only be accomplished by new feature}" or something like that?
    – JonW
    Feb 20, 2014 at 15:46
  • @JonW absolutely. But what if there are many micro-tasks that lead to the "correct" usage of the new feature? For example: A user should use one specific item in a dropdown list that suits my scribbles/frames in the following scribbles/frames. Whats the best way to tell the user "please use the second item in the dropdown list" for example?
    – uxfelix
    Feb 21, 2014 at 7:21
  • I'm can't see any way this is possible without either a) changing the design just for the test (yielding incorrect test results) or b) briefing the user before hand. For A. you could, as people say below, highlight the necessary elements on the page — but any discoverability data you would otherwise have got from the test is then worthless. Also you'd still likely need to brief them to explain that you're guiding them with the highlights! Giving a user a script or list of tasks to complete is a pretty common method and I don't see much way around it — can you explain your aversion to it?
    – Drew Beck
    Feb 24, 2014 at 4:50
  • I think @JonW is correct. If users use any of the other functions to complete the task you want to ask yourself if the new feature is necessary and maybe you want to improve on the functions the users use instead of offering them a different feature. Feb 27, 2014 at 10:44
  • I agree with Jon and Drew here. The whole point of a usability test is to gauge the intuitiveness of the UI. The thumb rule is you give no answers to the users but rather ask question for a question. If the users still use the old functionality and completes, you mark it as a failed task and go back with this data to your drawing boards. Ideally the test should only allow two to three prompts/hints if the user is stuck with a task and after which mark the task as failed. Many failed tasks means the designs are not what the users expected so you have to work again. Feb 28, 2014 at 4:51

6 Answers 6


Some suggestions:

  • Place an indicator over new UI elements. This could be a little star or a label saying "new" which sits over a corner of the relevant interface element, or a gentle glow around the element. (If you must click three UI elements to reach the new feature, then each of them could display the indicator. But that is not needed if the target users will visit that part of the interface often anyway, so it really depends on your app.)

button highlight

  • While it might be easiest to add this indicator to the site for a few weeks after adding the feature, a better experience would be to show it for users who have not yet noticed the feature. The indicators could disappear once the use knows the feature exists.

  • Track which features a user has seen and/or used. If a user logs in to your app, and there are new features since his last visit, you can display a "New Features" notification. Clicking this notification could give a short pointer to the new features, (which could be expandable if a detailed explanation is given). Once the notification has been seen, or skipped, or the feature has been used, the notification would not be shown to the user again (until you have another new feature to offer them).

To further optimize the experience, you could try to determine which user groups could benefit from a new feature, and which users would never use it, and advertise or downplay the feature to those groups respectively.

  • 1
    This is probably good advice for in production systems, but bullet points 2 and 3 clearly are not applicable to wireframing.
    – Hazzit
    Mar 1, 2014 at 12:01

The best solution to the problem is try 2 or 3 design solutions, show them to different users (counter-balance the design use for each user) and you get data to know which design worked best.

  • 1
    Hmmm. Interesting! A/B Testing of wireframes :) Feb 27, 2014 at 8:17

To be as close to real UI as possible, I think you should have one more level of detail in the wireframe: The old components should be "functional" in the sense that they can be selected, and only upon selection indicate "you don't need to go here". Only that way you can see how lost the test user is, when trying to find the new functionality.

On the other hand, if you really just want to test the new functionality itself, and not how users activate it or find it, just have those clear hints showing "you are supposed to click here to get to the part which is being tested".


If your medium is on-paper or monochrome wireframes, then you can choose a color-designate to highlight new functionality/feature as shown below:

enter image description here


I am assuming that you are building these wireframes for testing with existing users. I will have a different take on this topic from the one mentioned in previous answers. I say this from my personal experiences doing usability testing with paper prototypes and slide-decks. I realized that the user do not focus on individual components but are more concerned with task-flows and end-to-end scenarios.

It is human nature that we want to pass at any given test as it is a socially accepted norm. Usability testing is quite different as we designers are looking for people to fail. Irrespective of how you tell the users this point they will still feel to do everything correctly (at least on a face value). This applies greatly to the level of details that you give in the test. You do not want the test to be too complicated or overly easy. Also you should be careful to not keep it open ended as the data points you collect would be ambiguous.

Coming to your question. I believe it is perfectly normal to not distinguish the old features to the new ones. Just include enough details in the wire frames or mock-ups that will allow the users to finish the task. This will help you with two scenarios:

  • If the users are completely new, they would not know the difference and you can validate if the new features blend in the existing experience. This is important for the tool.
  • If the users are existing users of the tool, let them ask if the feature is new. Many of them will point out "i have not seen this feature in the earlier version" and you just plainly ask " what version are you on.. this one is the new feature we are coming up with!!"

Hope this answer helps you in your wire-framing!

Cheers, Nishant


At the beginning of the usability test, give the user a specific do do TASK that requires the use of that new function you added. Is't that why you added the function in the first place? You might want to follow a A3/PDCA to keep sanity.

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.