recently I've been designing an app for a call center. It is meant for experienced consultants. I've been wondering how to test it, since an important part of it is talking to a real client with real problems and also real controls like timers etc. Is there even a way or do I just ignore this part and test on a demo (which will probably be quite modest in terms of functionalities)?
2 Answers
I am not sure what tool you use (in my case it is Axure, so a lot of this answer will refer to its functionality) but I faced this challenge several times. In my eyes, the options are:
Simulating the action by triggering its effect manually
This is the approach I have most of the times. I simply place a button (giving it a style that would make it clear it is not a part of the system – very important, as some Clients may think it is an internal part of it). For example, once when wireframing a messaging system I put a simple HTML button next to the interface saying [Simulate new message].
Simulating the action by triggering its effect automatically
If your tool allows it, you can also trigger some actions with a delay. I once wireframed a mobile app where an SMS authorisation was necessary. It was important that the notification started from the confirmation number to avoid truncating it within the notification (iOS limitation) so that it looked like "4093 is your confirmation code." What I did was displaying a notification on top of the wireframed screen several seconds after the screen was loaded.
Embedding some elements in an iFrame
This is another thing you can consider. I believe it could be used in some quite rare situations, though, only when there are some bits of embeddable elements to be used. I took this approach once with such embeddable element, but several times used it to show e.g. an article or an external system within the wireframe (think: a browser embedded in Facebook app for example).
Using JS
This is something you could probably use if your tool allows it of course and if you have knowledge in using JS. Again, Axure allows it, so I can use some JS code in it. However, my JS skills are not big enough to tell you what the limitations here would be. In theory, you could use JS and set some variables based on it.
Hacking the output
Some other thing (again: Axure context here) would be exporting the wireframe and then editing the code itself to provide some extra functionality. I tried it once and unless there would be a really really strict requirement I would not recommend it. It is very annoying, because every time you change anything in the wireframe, you need to re-edit the exported file, and manually upload it to Axshare.
Keep it static!
Take this approach whenever possible. I have learned that the more things are hidden behind some dependencies or User interactions in your wireframe, the more probable is that the recipient/stakeholder will not see it at all and that they will come back to you when it is developed with a feedback that it should not be done like this. Of course it may vary from Client to Client, but in general, I believe this approach is good. Wireframe is a compromise between a specification and a working system anyway, so it is natural that some things cannot be properly reproduced there.
answered Apr 19, 2017 at 8:03
The answer of course depends on what exactly you want to test in the app. However, for most testing goals, I wouldn't assume that it is necessary to elaborately include these features in a prototype.
User test for testing usability
I am always impressed how easy test users can imagine the intended functionalities even though there are only static designs. For known elements like a timer, you don't need them to be dynamic. All users can imagine that it will count the time in the actual app even though it shows static numbers in the prototype. And you can always explain the intended behaviour to the test user. Instead of wasting much time with prototyping a dynamic timer, try to keep it simple and get user feedback as early as possible.
Present the prototype to your client
For presenting the prototype, you don't need dynamic elements either, as you can prepare your prototype according to your presentation. The prototype then will only fully work in your prepared order, but again, instead of wasting much time with the details, it probably meets its requirements to communicate an idea and serves as a proof of concept.
Define required functionalities
If you want to find out which functionalities are required in you app, you probably wouldn't start with a prototype at all. Instead, observe how your target group is working in real situations and conduct interviews. You can also present them your prototype and ask them about their opinion, but that doesn't require fully dynamic elements either.
Of course, you don't want to explain your test users or target group more than necessary and you want to present a convincing prototype to your client. There are a few easy ways how you can simulate dynamic behaviour in a prototype without much effort. I am working most with Pidoco, but similar functions are offered in many other prototyping tools.
1. Time-based interactions
Many tools include time-based interactions, where you can trigger actions with a predefined time delay. E.g. a pop-up could appear after several seconds on a specific page, where an incoming call is simulated. Time based interactions usually can be attached to previous interactions (certain time after a specific button is clicked) or to the page load (certain time after a specific pages is opened).
2. Action Areas
Action areas or also called link areas are invisible areas, that trigger a specified reaction on a click, hover or other user input. This is particularly useful, when you present your prototype so only you are interacting with it. But in some situations, it can just as well be used for test users.
3. Call to action elements
Of course you can also add visible buttons or other elements that tigger specific actions. E.g. a button called "incoming call" can trigger the simulation for incoming calls. These visible elements don't look so nice in your prototype, as they don't belong to the actual app's design. I usually place them in the top or bottom of the page, so I try to spatially distinguish them from the actual elements included in the app and offer a view in which they are not necesarrily visible (e.g. with scrolling).
