1

The redesign of the user interface of a scope meter

UNIVERSITY OF TWENTE

Thijs Baltes s1127144, Mieke van den Belt s1098497, Dion Hofsté s1078488, Reinout Holtrup s1106678

ABSTRACT This is a report, presenting the design process and a design proposal of a new user interface for the

FLUKE Scope Meter. It is made as part of the Bachelor course ‘Ontwerpen Van Interactieve Producten1’ at the University of Twente. Designing user interfaces is an iterative process, meaning generated design changes are constantly alternated with evaluation sessions. In this report design choices will be motivat-ed and the evaluation sessions will be presented. It is useful to take a look at the interactive prototype that comes as an attachment with this report. The main goal of the project is to make a better user interface than the one of the reference product, the FLUKE® 123 Industrial Scope Meter. The proposed design is a touchscreen interface, with mainly a menu-based interaction style. A usability test is done to investigate at what extent users cope with the altered design, in comparison with the design proposed by another group. Our design was very intuitive, although some changes had to be made. In the end some of the properties were changed and some functionalities were added to make a final design proposal.

1. Introduction This paper is written as a documentation of the

redesign-process of a digital scope meter, which is the subject of the course ‘Ontwerpen Van Interactieve Producten1’, as part of the Bachelor Industrial Design at the University of Twente. A big part of the course is prototyping and evaluating prototypes of user inter-faces. The feedback from these tests, together with heuristics for good user interface design should result in a working final prototype. In this paper you can read about how these evaluations are done and how the knowledge derived from the tests is used to create a final prototype.

The goal of this project is to bring up a ‘significant-ly better user interface design, with higher usability than the FLUKE® 123 Industrial Scope Meter. Usabil-ity is defined as: “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” (Part 11 of the ISO 9241 standard (BSI, 1998))1

2. Exploration A digital scope meter is a device used for trouble-

shooting electrical equipment by measuring electric signals. Scope meters can display electrical voltage over time, which can be used to discover bad connec-tions and bad grounding, and can, for example, de-termine where terminators should be placed.

1 EN: “ Designing interactive Products

The new product will be based on an existing product, which was marketed for the first time in 1995. This product, further described as ‘the current prod-uct’, is pretty old, but it’s still very important for techni-cians.

Now, in 2013, a whole new interpretation of user-friendly design has come up and a lot of new technol-ogies are available to ease the use of complex tools and make products more user-friendly. Nowadays, almost everybody is used to controlling their phone with a touchscreen and a very limited number of phys-ical buttons, which is very user-friendly. This is the reason why we focus with our redesign on a touchscreen interface.

The first step in a redesign process is to explore the current product. According to a list of heuristics, derived from the book ‘User Interface Design and Evaluation’ a heuristic evaluation was done. Besides the exploration of the current product, a quick investi-gation on the target group and the area of usage were also done. At the end of this chapter, a program of demands will be formulated, which will function as the guideline for our redesign.

2.1 Heuristic evaluation of the current product.

2.1.1 Overview The scope meter has a big, low resolution display

and a set of buttons. It has 4 keys (f1, f2, f3, f4) that can have different functions. It also has 4 arrow keys for basic navigation and a set of buttons with fixed functions. The entire device weighs about 2,5 kg.

2

2.1.2 Method - List heuristics. - Try different buttons and explore navigation. - Rank the product (0-4) on 14 heuristics. - Write down a small argumentation. - Collect findings. - Determine severity.

2.1.2 Heuristics General heuristics: - Visibility of system status. - Match between system and the real world. - User control and freedom. - Consistency and standard. - Error prevention. - Recognition rather than recall. - Flexibility and efficiency of use. - Aesthetic and minimalist design. - Help users recognize, diagnose, and recover from errors. - Help and documentation. Domain heuristics: - Usability with working clothes. - Feedback from user input. - Two handed usability (when no additional sur-face is available). - Legibility of display under expected circum-stances.

2.1.3 Findings: On the bottom of the page you can find a table

which shows the scores of the heuristic evaluation. The exact results of the evaluation, with some com-ments, can be found in the attachments.

A lot of design flaws where found in the FLUKE®, merely because the device is out-dated. So just up-dating some features to be a bit more modern would help a lot. The actual interface problems found, can be arranged under the following types:

Buttons: There are no buttons on the FLUKE® for confirming or returning in the menu. If confirmation is necessary the FLUKE® will give an ENTER-option under one of the top buttons (F1 to F4). This is not good for the legibility and the overall use of the but-tons is unclear, because the meaning of every button can change depending on the menu the user is in. Furthermore the way certain buttons are found/need to be used is devious.

Some of the physical buttons on the device could just as well be made into a menu option. Say for ex-ample that the user wants to change the brightness of the screen than there is a physical button on the de-vice for it. This might not be very necessary. Language and icons: The FLUKE® device that was used had two possible languages to choose from, respectively Dutch and English, yet in certain situa-tions both languages were displayed in the same pop-

Fig. 1: Results of the heuristic evaluation

3

up screen. This may cause difficulties, especially when having an error screen containing two lan-guages. Units: When a measurement is being done, a choice must be made which unit to measure. Say if one wants to measure voltage, one has to choose be-tween Volts (V) or Millivolts (mV) instead of just pick-ing voltage and choose the size of the measured quantity later on. The display: Overall the display contains a lot of in-formation, which makes it difficult for the users to im-mediately see the information they are looking for. The amount of information brings out that the fonts are small and the different types of information are hard to read. Also when wearing (safety) glasses or when there is little or dimmed light in a room the dis-play is hard to read. Displayed options: Sometimes the pop-up screens are quite full of unnecessary options. For example the measurements-menu; when one would like to change the units the device will measure, a whole list of pos-sibilities is giving for both the inputs, even if only one of the inputs is in use. General findings:

-The device shows system status, although not in a consistent way. -It misses two very basic navigation buttons: the [Enter]- and [Return] button. -Bigger units should be placed higher. -The device is pretty error proof. -The device displays too many options. -The current device doesn’t have hotkeys. -Errors contain a lot of dialogue. -The documentation is too long. -The feedback on the screen is not very visible. -Since the device is heavy, the user needs to hold it with two hands. The problem is that the user lacks a hand to hold the probes. -The text on the screen is too small.

2.1.4 Conclusion According to the table there are a few things that

really need to be optimized. The product scores very bad at some very important heuristics. When optimiz-ing the product, we really should think about: ‘user control and freedom’, ‘recognition rather than recall’, and ‘aesthetics and minimalist design’.

2.2 Target group Stakeholders: -Main users: 20-50, low educated technicians. -Company managers and directors. -Producers

-Logistics and transportation companies -Retailers Since for this course the main goal is to learn

about user-centered design, we will focus on the main users. This doesn’t mean we can completely forget the others, but that we just target the product to be developed for the main users in this project.

2.2.1 Main users: The main users are the users that have to use the

product as a tool for troubleshooting electronic devic-es. They are often low schooled and sometimes they’ve only had a two-week course to understand basic electronics. For these users, it should be made clear how and in which order measurements should be done and how they can determine oddities.

Important information should be given in the us-er’s mother language, although for some functionality it might be clearer to use English.

The main users have to do the measurements, but it is not necessarily true that they also have to con-clude if there is a problem or not. A boss, who just wants to see the measurements, might have sent them just to measure. Even a remote service compa-ny might be able to draw the conclusions.

Most of the users are men. (90%)4) so when it comes to design choices where sex could be a factor, there should be chosen for the manlier option. Be-sides taste or preferences of men, a significant part of men have the problem of colour-blindness. (1/12 men, against 1/250 woman)5

Since a touch screen device is going to be de-signed, it should be necessary that the target group has experience with touch-controlled devices. Be-cause most people use a smartphone or tablet nowa-days, they have experience with touchscreens, so it would be obvious to use similarities between a smartphone interface and the scope meter interface.

2.3 Target environment The product is going to be used in narrow spaces.

Most often the machines that have to be troubleshot are industrial control systems and they are built to require minimal space. Very often the probes have to be hold in difficult positions with two hands. The dis-play can be difficult to read in these positions.

2.4 Applications of the scope meter The most common application of a scope meter is

to troubleshoot electric equipment. For example: In a factory a process board, like a UL 508, controls all machines. The process board regulates the power

4

given to a motor, but since motors generate a self-induction current, the motor changes the properties of the input signal. The accuracy of other machines powered by the same current could be influenced by this power and this could cause troubles. A scope meter could be used to get insight in this current, so parameters for the controller could be changed in way to solve the problem.6

2.5 Design brief Using the information extracted from the briefing,

the heuristic evaluation and the revision of the target group and target environment, a new design brief was formulated: Requirements derived from the briefing:

-Maximum dimensions: 175*100*35 mm -Very sturdy -Portrait orientation -Able to hold with one hand -Useable with gloves -Four channels for measuring -Cordless network connection to monitor signals by professionals, remotely. -Contain touch screen with a maximum size of 7” or 15x9 cm -Access to frequently used functions by buttons. -The redesign should significantly be easier to use.

Requirements derived from the heuristics: - System status must be shown. - There should be a match between system and the real world. - The user has to have freedom for control. - There should be consistency and standard. - Errors should be prevented. - The interface should be recognizable and the user shouldn’t have to recall too much. - There should be flexibility and efficiency of use - The design should be aesthetic and minimalist. - The interface should help users recognize, diag-nose, and recover from errors. - The help and documentation must be clear and easy to access. - The device should be useable with working clothes, including gloves. - Good feedback from user input. - Two handed usability (when no additional sur-face is available) - Legibility of display under expected circum-stances. (low light, from an angle)

Demands from the target group: -Make it clear how measurements should be done. -Determine oddities easily.

-Insert files with routines and instructions. -Screen text in mother language. -Be able to communicate measurement data to others.

Demands related to the target environment: -Possibility to hang or set away the device onto a surface to make two hands available to connect the probes.

Other requirements: -When a touch screen is used, it should have large target areas.

Functionality: -Display waveforms -Scope record -Store ideal waveforms for all different machines. -Impulse measurements -Filter Ambient and Electrical noise. -Last for hours -Safe -Data storage -Calibration -In scope mode, auto/manual -Trigger/Slope

5

3. Ideas The assignment is to create a whole new user in-

terface of the product. We have split the properties that have to be changed in physical properties and non-physical properties of the user interface. Keeping in mind that the advice was to think about a touch screen device, ideas were generated. In the following paragraphs the best ideas are further mentioned. To use any features of the final prototype in our own port-folios it was recommended to change the name and colour of the FLUKE® Industrial Scope Meter. There-fore, there is chosen to name the new and improved model the “CURSE®”.

3.1 Hardware properties. Display: The original LCD screen will be replaced

with a 7” touch screen. The representative of Bench-mark told that they would recommend the use of a touch screen and that they had already researched the usability of touch screens while wearing protective gloves. According to the representative, in the future there will be a touch screen available that enables the user to operate the display, while wearing these gloves. The use of a touch screen enables the user of the Scope meter to intuitively interact with the prod-uct. This gives the designer the occasion to just pre-sent the relevant ‘touchscreen buttons’ to the user. This way, the abundance of buttons that have no function in the active window, can be reduced.

The standard display ratio that is recommended to use is 15 x 9. In the design brief was mentioned that a portrait orientation is advised. Therefore, the new and improved CURSE Scope Meter will have an integrat-ed touch screen of 90mm width and 150mm height. The screen size should be maximized to be legible from a distance of ¾ meters, and the touchscreen buttons are big enough to be used by gloves.

Buttons: On smartphones, physical buttons are limited. The buttons that do appear have a function in every screen menu. This makes usage very clear and fast. A [Back] button always brings the user back to a menu higher in the hierarchic-ordered function tree and a [Home] button brings the user back to the high-est menu. A [Settings] button always brings the user to the available settings for the active application. The last button is the [On/Off] toggle.

For frequently used functions like [TRIG-GER/SLOPE] and [AUTO/MANUAL] it would be bet-ter not to add physical buttons. This is because they don’t have a function in all menus, so it would be un-clear when they are useful. The touchscreen is big enough to make an option for these buttons, or they could be accessed from a quick options menu. Expe-

rienced users might be able to use a touch gesture for these functions.

3.2 Software properties Navigation: The CURSE® will have a lot of simi-

larities with a smart phone device people use on a daily basis. The three main buttons are physical but-tons and these will guide you through a series of menu-options.

When starting with the CURSE® one shall always begin with the HOME-screen. This menu contains several options to choose from. These are shown as icons, accompanied by some text for clarification. When one chooses an option, but wants to return for a certain reason, the [Back]-button at the bottom of the device will bring back the user one step into the menu structure.

When one wishes to go back to the main screen, because the acquired settings have been set, the physical [Home]-button will bring the user back to the HOME-menu.

3.3 Metaphors and interaction styles

3.3.1 Icons Initially a user would need to read texts to under-

stand menu items. Icons must be very common, if the user would understand them at first glance. However, for more experienced users they could speed up the interaction process a lot. Icons should be used if the icons are standardized, or when the icon represents an object with a strong physical analogy. For other things textual buttons would be better.

3.3.2 Interaction styles Nowadays most devices have some sort of menu-

based interaction style. A menu based interaction style for the main options has as big advantage that users can explore functionality easily, since function-ality is split into different menus. For this product a menu-based interactions style, could be an appropri-ate choice for the main part of the device. However, it would consume too many display space to show up all different options in the option menu at once, so a combination with a form-fill interaction style might be better.

The number of submenus should be under five. Using more would slow down workflow to much.

A final third interaction style could be added to speed up workflow. Direct manipulation with touch gestures could be a shortcut to switch through the main menus. It could also be used to manipulate files in a file manager for example.

6

4. Conceptual model of the new scope meter Keeping in mind the first heuristic evaluation, and

the demands, ideas were selected and a new interac-tive prototype had to be created.

Before creating an interactive prototype we did a test to validate the mental model, with a paper proto-type. After this test an interactive prototype was de-veloped.

This was done using Adobe Photoshop to create menus and Adobe InDesign to make an interactive PDF

4.1 Physical Properties: It was chosen to work out a touch screen applica-

tion with the two physical navigation buttons, a [Func-tion]-button and an [On/off]-toggle. The screen size of the CURSE® is 9x15cm. For the first prototype we’ve chosen to create an application with only two input channels. This would limit repetitive work and would give us the occasion to work out other options. Be-sides it was not clear at that moment how we would develop four channels. Testing two channels was easier to create and changes would be easier to ap-ply afterwards.

4.2 Interface Since the time for this project is limited, it is im-

possible to work out a complete interface. Required are only ten menus and a suggestion on how the oth-er menus should be made.

4.2.1 Navigation Fig. 2 Tree diagram of navigation

4.2.2 Functions The CURSE® scope meter contains a lot of func-

tions. Each of these functions is included in the HOME-menu. When pressing one of the buttons, the underlying functions can be used or opened. The following four functions can be found under the HOME-menu: Measure, Settings, File manager and Help.

7

Measure: In this menu one can determine which quantity needs to be measured. There are two differ-ent channels to measure two different quantities. Each channel is marked by its own colour, respective-ly red and blue. When the probes are attached to the ports the MEASURE-menu will show that the port is active and usable for measurements. When clicking the [Input]-button a top-down screen will show all the possible quantities to measure (from Volts to Deci-bels).

When the desired inputs have been chosen, the [Start measure] button is pushed to start measuring. In the graph shown next, the two input channels cor-respond in colour with the lines shown. The red chan-nel (input A) is displayed by a red line and blue with a blue line. Settings: The SETTINGS-menu will give you two options to choose from, namely the MEASURE-settings and the CURSE-settings. The first mentioned will lead to a menu solely for the purpose of changing all the different options regarding the current meas-urement, like the grid type or the settings for the probes.

The CURSE-settings will lead to a menu the user only has to visit once. The options in this menu are fixed and do not need to change during the usage of the device. (Brightness & contrast, power options, language and time & date) File manager: When working with the CURSE® you can imagine that you want to review some of the re-sults on a later moment, so to make sure the user can keep his results the possibility to make screenshots is added as well as the save measurement and save settings option.

The results of these actions can be found under the file manager. The employer can also put simple text files in this menu to instruct his employee when a certain task needs to be performed or to have a guide for the tasks that are performed more often. Help: The help options only needs to be consulted when the user is not able to understand the device. Apart from a list of specs, this menu will contain a digital version of the manual for situations in which the printed version is unavailable and furthermore it will contain some FAQ’s. When the user is in need of oth-er information that is not provided by the device a shortcut to the Internet website of the CURSE® has been added.

4.2.3 Icons In the previous paragraph 3.3.1 you could read

that the CURSE could have an icon based structure rather than plain text in the menus. In an age where smart products are used on a daily basis, most prod-

ucts work by clicking icons to start applications. To respond to the current devices that are for sale and keeping in mind that the device must be easy to work with, even for the less intelligent employee, chosen is to make use of icons in the improved product.

In graphic design a trend called flat design is be-ing spot. Flat design is a way of portraying elements in a 2D manner, using simple and organic shapes. It is an answer to the realistic design that icons were having the last decade. Flat design uses no depths by gradients or shadows. As a result the icons have a minimalistic and clean look.

For the CURSE® all the menus have been given an icon. To make sure people would be able to rec-ognize the feature by the icon alone a research has been done on existing icons, used for the same fea-ture or a feature similar to the feature that needs an icon.

For example; clicking the ‘half gear’ icon enters the SETTINGS-menu. A gear is an element that rep-resents the settings in a lot of devices. This will help trigger the user’s foreknowledge to make a link be-tween settings and the icon, when first using the de-vice.

Most of the icons already have an archetype that is widely respected as the real icon. In order to make sure that people will not mistake our icons for different features, as little as possible alterations were made. The icons that did not have an archetype already, for example the CURSE SETTINGS-menu or the GRID TYPE-menu, the given icons show similarities to the feature or hardware it represents. The aforemen-tioned option is for example an icon that looks like the CURSE®-device, combined with the [Settings]-button and a visualization of a grid.

To make sure people that are using the device are able to easily learn to use the device, there is chosen to add text to the icons. This way an employee can simply read which menu the icon leads to when being pressed. When an employee is using the device more often, icons will be remembered easier, causing the employee to recognize them quicker, making the task quicker to perform. In the next paragraph will be an explanation in how the evaluation of the icons was performed.

4.3 Evaluation of redesign To test whether the menu structure as designed

was clear enough, a low-fi prototype was made. This prototype consisted of screenshots of several menus, drawn by hand (see image). Two versions of these menus were made: one with only icons and one with icons and text. This way, it was testable if using only icons would be clear enough or if people would also

8

need a textual description. With this prototype, a test was performed among four people. These people were asked to point out on which button they would press to perform a certain action. The actions were: going to the ‘language settings’ and ‘saved measure-ments’. They also had to measure resistance at input A and direct current at input B.

The results of this test were quite positive. The

first two actions were performed without any prob-lems, but the third one caused some difficulties: All four people were able to find the MEASUREMENTS-menu, but not everybody understood the used abbre-viations. People also struggled with the meaning of AC and DC current. Giving the instructions in Dutch probably caused this problem, since DC is an English abbreviation.

A second test was performed to find out if people could understand the icons without text and context. A list of icons was made and was given to four peo-ple. They had to tell what they thought the icon would mean. These people had never worked with the scope meter before. Most of the icons did not cause any problems with anyone, but some did. The icons that were most confusing or unclear were ‘language’, ‘file manager’, ‘Amp’, ‘Pulse’, ‘VAC’ and ‘VDC’. These last four mistakes were not very surprising, because none of the subjects was familiar with the product or its functions. Nevertheless, the product also has to be understandable for non-professionals, so these icons should be changed to become clearer. Also, the icons for both ‘language’ and ‘file manager’ probably will have to be changed.

4.4 Ideas to improve interaction Since recognizing the icons without any context

caused more problems that recognizing them in a menu, it is recommended to create a navigation bar on top of the display. This bar shows in which menu the user is and therefore creates a context for the user.

With the results of these two tests, some changes to the icons had to be made and it was decided that it was indeed necessary to add a navigation bar and textual descriptions. These changes were incorpo-rated in the high-fi prototype.

4.5 Details

4.5.1 Colour schemes For the CURSE®-menus the following colours

have been used: Measurements: To keep the data as legible as pos-sible, primary colours have been chosen to show the

data in the measurement screen. Every colour corre-sponds with the same colour probe.

Menus: Grey tones have been used for the different menu structures to give them a tranquil feeling and to not distract the user. The different shades of grey make sure that every menu option looks like it stands alone, improving legibility and comprehensibility, in comparison to the current device, in which all the menu options are listed with the same background colour.

The device: The body of the CURSE® is a sparkling, fresh orange interspersed with a light grey. The choice for an orange body has been made, because orange is a colour that is easily spotted and often used in industrial products like multimeters.

Body (Orange): RGB 248,162,90

Body (Grey): RGB 174,174,174

Body (White): RGB 255,255,255

White 255,255,255

Fonts (White): RGB 255,255,255

Input D (final design proposal) (Green): RGB

Input C (final design proposal) (Grey): RGB

Input B (Blue): RGB 46,119,246

Input A (Red): RGB 222,87,68

Background (Grey): RGB 172,172,172

Menu 1 (Light Grey): RGB 100,100,100

Menu 2 (Dark Grey): RGB 85,85,85

Banner (Grey): RGB 70,70,70

9

The fonts: To enhance the readability of the CURSE® the following fonts were used in the menu structures. Interface: Helvetica NeueLT Com 37 Thcn. It is a very thin, well readable font. It is a basic font, without any fuss.

Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr Ss Tt Uu Vv Ww Xx Yy Zz

Numbers: Univers light. This is also a thin font, so it matches the shapes of ‘Helvetica NeueLT Com 37 Thcn’. The reason that font is not been used for the numbers, is because numbers in general often do not look so well when used in a device. The roundness of the characters causes a bad legibility, so to avoid this problem a different font was chosen.

1 2 3 4 5 6 7 8 9 0 5. The usability test:

Now we have designed a working prototype, it is time to check its quality.

To get insight in the quality of the proposed user interface, a usability test was done. The overall goal of this project is to bring up a user interface that is a significant better than the current one, regarding the effectiveness, efficiency and satisfaction of the user. Because more project groups have to design a new user interface for the same product, it is interesting to see what their solutions are in comparison to ours and to check which solutions are the best. Since some of the results will be absolute data, we could use the other group’s data as a reference to draw conclusions about the CURSE’s ‘usability score’.

5.1 Goal The main goal of the usability test is to investigate

in what extent users cope with the design made.

5.2.1 Method To test the usability of the design, a test was set

up. In this test, several people were asked to perform five actions. While the subjects performed these ac-tions, several things were measured. The group of test persons was divided into different groups and every group had to perform the test under different conditions. These conditions are also called inde-pendent variables. The independent variables in the test were: Expe-rience, allow to ask questions an different concepts.

Experience with a Scope Meter: Half of the subjects had experience with a Scope Meter, these were peo-ple from other project groups who also had to rede-sign the Scope Meter. The other half were people who had to redesign another product or did not follow the course. Asking questions: Half of the subjects was allowed to ask questions during the test, the other half was not. Different concepts: Our redesign was being com-pared to another redesign. Therefore, half of the sub-jects performed the test on our redesign and half of the subjects on the other redesign.

For each concept, there were four groups of test persons: with experience and allowed to ask ques-tions, without experience and allowed to ask ques-tions, with experience and not allowed to ask ques-tions, and without experience and not allowed to ask questions. All groups contained of two persons.

Besides the independent variables, there were al-so dependent variables, which were the values that were to be measured during the test. With the results of these measurements, it would be possible to tell whether one group understood the interface better than other groups. The dependent variables were: ‘Number of clicks to get to the right answer’, ‘Number of mistakes’, ‘Re-quired time’, ‘Number of asked questions’

In addition to these variables, each test person al-so had to fill in five questions after completing the test. This way, a qualitative measurement was per-formed. The questions of the survey were:

1. How clear were the icons, on a scale of 1 to 5? (1 = very unclear, 5 = very clear) 2. Which grade do you give the usability of the Scope Meter, on a scale of 1 to 5? (1 = very bad, 5 = very clear) 3a. In which extent did you miss a help function of being allowed to ask questions, on a scale of 1 to 5? (1 = not missed, 5 = missed a lot) 3b. How did you experience the help function (be-ing allowed to ask questions), on a scale of 1 to 5? (1 = did not need it, 5 = very useful) 4. What were the strongest aspects of the inter-face of the Scope Meter? 5. What were the weakest aspects of the interface of the Scope Meter?

10

The actions all the test persons had to per-form were the following:

1. Set the grid type to ‘grid’. 2. Measure the alternating voltage of input A 3. Go back and measure the current of input B 4. Show only the graph of input B 5. Delete screenshots IMG008 and IMG011 By letting the test persons perform these five ac-

tions, all aspects of the interface were tested. Each menu item from the main menu had to be used at least once, just like all types of buttons on the inter-face.

5.3.2 Tasks One person observes, one counts the clicks, one

answers questions and one measures the time.

5.3.3 Hypothesis Our goal is test the usability of our new interface

design proposal. In the introduction of this paper usa-bility was defined as: “The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”

The three aspects of the definition were split, and test criteria were chosen.

For efficiency we defined two criteria: Number of ‘clicks’ needed to perform a specific task and the time needed to accomplish that task. Effectiveness was ‘measured’ by observing whether the actions of the test person led to accomplish the goal: When a test person had trouble finding the right button or menu, or wanted to perform the action in another way than we thought about, effectiveness could be optimized. The overall findings of the test person were determined by a qualitative measurement method, a survey.

To determine whether the results were high, they were also related to the results of the usability test of another group.

Since a lot of effort was spent to develop a highly usable user interface, the usability of our product was considered to be high, prior to the test. Since we made the hypothesis that a touch screen device would have a higher usability then a button controlled device earlier, it was also thought that our product would have a higher usability then the other group.

Number of clicks: The user wouldn’t need 5 more clicks then the minimal number of clicks.

Time: To perform the 5 tasks, the user wouldn’t need more then 2,5 minute and to perform a single task the user wouldn’t need more then 45 seconds.

Qualitative: Smartphone users would need 30 seconds less then non-smartphone users, to perform

the five tasks. People that are allowed to ask ques-tions, would need 30 seconds less then people that aren’t allowed to ask questions, to perform the 5 tasks. They would also need 3 clicks/task less.

Relative to the other group: Our product would have a touchscreen, which would be more efficient, then a button-interface. Our product would need 3 times less the number of clicks then the other group. The average time needed to perform a task with our product, would be half the time then with the product of the other group.

5.3.4 Results of the Curse After the usability test, the measurements were

collected and compared. In this paragraph, the results of redesign A will be displayed.

At first, the number of clicks was compared to the number of clicks that was necessary to complete the task. The number of clicks more than necessary, per task, is shown in the graph below.

Besides the number of clicks more than neces-

sary, also the time was measured. The time per task is shown in the graph below. The peak at the time of task 5 for group 3 was caused by some trouble in the interface, which were not the fault of the test person.

Group 1: with experience and with help Group 2: with experience and without help Group 3: without experience and with help Group 4: without experience and without help

0102030

1 2 3 4

Num

ber

of c

licks

Group

Number of clicks more than necessary

Task 1

Task 2

Task 3

Task 4

Task 5

050

100150200

1 2 3 4

Tim

e (s

)

Group

Time per task

Task 1

Task 2

Task 3

Task 4

Task 5

11

5.3.5 Results compared to another prototype Our redesign was also compared to a different re-

design made by another group of students. The inter-active model of the other group did not make use of a touch screen. Therefore, they just added and deleted physical buttons and rearranged them to create a user interface with a much better usability. They also changed the appearance of the Fluke Scope Meter by changing the color of the outer product.

A usability test similar to ours was also performed

on redesign B. The results are shown in the two graphs below.

As can be seen in the upper graph, for task 1 and 3, the difference between redesign A and B is very small. The differences are slightly bigger at task 2, which was performed better at redesign A. Task 4, on the other hand, was performed much better at rede-sign B. Based on our own usability test, we already were aware of the fact that task 4 caused a lot of trou-ble, so this definitely will have to be changed for the final model.

When looking at the lower graph, it can be seen that task 1 and 2 needed a lot more time at redesign B than at redesign A. This seems logical for task 2, since task 2 also needed more clicks. However, the difference in number of clicks for task 1 was very small, so the test persons needed more time for the same amount of clicks. This is also the case for task 3, although for task 3, redesign A needed more time than redesign B. The difference in time for task 4 can be explained by the fact that the test persons also needed way more clicks for task 4 at redesign A than at redesign B.

5.4.6 Conclusion Based on these results, it cannot really be told

which redesign has a higher usability, because both scored higher at some aspects. In any case, it is clear that the options needed for task 4 at redesign A defi-nitely have to be improved.

To draw a conclusion from our usability test, at first it will be checked whether the expectations and hypotheses can be confirmed or rejected. The hy-potheses will be dealt with below. Number of clicks: The user does not need more than five more clicks than necessary per task.

This hypothesis turned out to be true for almost every group and every task. Only task 4 needed more clicks for two groups. This was the task with most difficulties, so it can be seen as an exception. (Hy-pothesis confirmed) Time: To perform the five tasks, the user would not need more than 2,5 minute.

Three groups needed less than 2,5 minute (150 seconds) to perform all five tasks, only the group without experience and with help needed 168,3 sec-onds. This high number was caused by the fact that this grouped needed a lot of time for task five, as ex-plained in the results, so it can be seen as an excep-tion. (Hypothesis confirmed)

To perform a single task, the user would not need more than 45 seconds.

0

5

10

1 2 3 4

Num

ber

of c

licks

Task

Average number of clicks more than necessary

Redesign A

Redesign B

0

20

40

60

1 2 3 4

Tim

e

Task

Time

Redesign A

Redesign B

12

This hypothesis is true for almost all tasks and groups. Only group 3 took more than 45 seconds to perform task 5 (as explained in the results) and group 4 took slightly more than 45 seconds to perform task 4. These can be seen as exceptions. (Hypothesis confirmed) Qualitative: People that were allowed to ask ques-tions would need less time to perform the five actions than people that were not allowed to ask questions.

This hypothesis cannot be confirmed based on the results of the usability test. There was no signifi-cant difference between the time people from both groups needed. (Hypothesis rejected)

People that were allowed to ask questions would need fewer clicks more than necessary per task to complete the task than people that were not allowed to ask questions.

This hypothesis is indeed confirmed based on the test results. The two groups with help needed signifi-cantly less clicks than the groups without help. (Hy-pothesis confirmed)

People with experience would need less time to perform the five actions than people without experi-ence.

Based on the results, this can be considered true. The groups without experience indeed needed more time. Even when knowing that the group without ex-perience and with help needed a lot of time caused by a mistake in the model when performing task 5, they probably still would have needed more time when this mistake had not occurred, since they needed more time for the other tasks too. (Hypothesis confirmed)

People with experience would need fewer clicks more than necessary per task to complete the task than people without experience.

When looking at the group without help, the group without experience indeed needed more time than the group with experience. However, when looking at the group with help, this turned out to be the opposite. Therefore, this hypothesis cannot be confirmed based on the results. (Hypothesis rejected) Relative to the other redesign: People who used our redesign would need less time than people who used the other redesign.

This is true for only two of all four tasks; the other tasks were performed in less time at the other rede-sign. (Hypothesis rejected)

People who used our redesign would need fewer clicks more than necessary than people who used the other redesign.

This is true for three tasks; however the difference was quite small. Task 4 definitely caused a lot of trou-ble at our redesign, so the number of clicks was very high. Even though this can be seen as an exception,

the difference between the two redesigns still is not very big. (Hypothesis rejected) Overall: Based on the hypotheses, five out of nine were confirmed and four out of nine were rejected. The first three hypotheses had to do with our re-quirements and all three were confirmed. Therefore, we can state that our user interface meets the re-quirements concerning its usability.

When looking at the hypotheses that had to do with the independent variables, it is a bit harder to tell whether the user interface satisfies our expectations. Although some groups indeed performed better on some aspects, as expected, other groups did not fulfil the expectations. The groups with help did need few-er clicks than the groups without help, because they did not have to try until they found out themselves. However, this did not result in faster performances. On the other hand, the groups with experience were indeed faster than the groups without experience, but it did not necessarily took them fewer clicks.

These seemingly confusing results might be seen as negative, because our hypotheses were not con-firmed. However, there is also a very positive aspect of these results. Based on the results, it can be stated that it does not really matter whether the user had experience or not, and that it does not really matter either whether the user was able to use help. Never-theless every group succeeded in performing the tasks, sufficiently enough to meet our requirements. Therefore, the conclusion can be drawn that our re-design is just as understandable for professionals as it is for inexperienced users, which is certainly a good thing. Our goal, making a design with high usability for every user, has definitely been accomplished.

When comparing the two redesigns to each other, it cannot be stated whether one redesign is better than the other, but anyway, both satisfied to the re-quirements.

6. Final design proposal After the usability test, it is important that all the

design faults and all the defects of the user interface are getting solved. During the usability test the test persons gave a lot of suggestions. That information was helpful for the final design proposal. In this chap-ter a description is given about how the design pro-posal is worked out with the feedback from the usabil-ity test.

13

6.1 Final changes: Function button vs. physical settings button: The usability test had one main item that failed time after time. The instruction to display just graph B was for every test person a big struggle. The main reason for that struggle is the fact that the function button [≡] had almost the same kind of function as the physical [Settings] button. After the evaluation of the test the conclusion was drawn that the physical [settings] but-ton had almost no added value, because there was already a touch screen [settings] button that had the same purpose. The user will not frequently change the settings that were listed under this touch screen button. Chosen is to replace the physical [Settings] button with a physical function button [≡] and leave just one option to go to the SETTINGS-menu. Size of function button: Another point of improve-ment was the size of the function button [≡]. The placement of this button was understandable, but because of the size of it, a lot of people thought it to be inferior to the other buttons. Due to the elimination of the physical [Settings] button, there is a physical button free at the bottom of the CURSE Scope Meter. This empty button will be used to position the function button [≡]. The size of the physical button is bigger and has a more notable place than the original func-tion button [≡]. Size of touch screen buttons: The third point of improvement is the size of some of the touch screen buttons. A few test persons thought that for example the radio buttons and the checkboxes were too small for a user wearing gloves. A possible solution for this issue is to make the surface, in which the button is placed, bigger. With this additional feature the user can tap the entire field to check or uncheck a box. Understanding of electro technical terms: For the usability test there is chosen to make use of test per-sons who have no knowledge about the Scope Meter whatsoever. Especially these test persons had diffi-culty understanding the electro technical terms. This was a major issue in the usability test, but there is chosen not to do anything about this, because one can assume that the people who use this product will have any knowledge of electro technical terms. Auto/manual and trigger/slope: During the usability test the representative of Benchmark asked where he could find the auto/manual and trigger/slope function. According to the conversation with the representative, the functions need to have an important place in the user interface, because these are functions that get used very often. With this information, chosen is to locate these functions under the physical function button [≡].

14

6.2 Function tree: To display all functionalities of the prototype, a fi-

nal function tree was made. It shows the hierarchy of the menus and where the different settings can be found. In the appendices A and B, you can find the basic and expert touch screen gestures. These func-tions have not been implemented into the function tree.

Fig. 3: Function Tree

15

7. Recommendations and conclusion

7.1 Project The iterative design method used for the redesign

of the FLUKE® Industrial Scope Meter was very help-ful during the design process of the new user inter-face. The evaluation steps were in particular useful to test the new designed interfaces. Every usability error from either the original Scope Meter or the new de-sign proposal can be found using this method. The iterative design method is therefore very useful for this kind of project. Especially when an interactive prototype has to be made, it is really time consuming to use the Pahl and Beitz design method.

It wasn’t part of the project, but to evaluate the fi-nal design proposal it is useful to fulfil another heuris-tic evaluation with the same parameters as the first one. When this final heuristic evaluation has been done, one can certainly say whether the final design proposal is better or worse than the original Scope Meter.

7.2 Product: The final interactive design prototype consists of a

couple developed menu’s in which a potential user or developer can see how the user interface looks like. Almost every different screen is represented in this

interactive prototype. When the producer of the FLUKE Scope Meter wants to implement additional functions or menus, the company can just follow the design of the screens that are already made. When the company for example wants to add different set-ting options, they can just implement an extra button or option under the SETTINGS-menu. The company can implement entirely new functions in the space that intentionally has been left blank.

To make the final user interface ready for imple-mentation into the new FLUKE Scope meter, a few changes need to be made. The function button [≡] for example has got a few very important features. Therefore this menu needs to be clear straight away. One of the things that need to be changed in this menu is the font type and size. In the final user inter-face proposal is was chosen to use the same font as in the rest of the interface, but afterwards the problem surfaced that this leads to a messy and unclear ap-pearance. In this pop-up menu it is also difficult to see which term is superior or inferior to one another. For the definitive implementation of the user interface in the Scope Meter, is it therefore necessary to change those appearances of the function menu [≡].

8. References 1. British Standards Institution (BSI) (1998). BS EN 1S0 9241-11:1998. Ergonomic Requirements

for Office Work with Visual Display Terminals (VDTs). Part 11: Guidance on Usability. London: BSI.

2. Anglin, M.R. (2013). What Is a ScopeMeter®?., 2013 (1), 1. Viewed on 25-09-2013, at

<<http://www.wisegeek.com/what-is-a-scopemeter.htm>>. 3. Stone, D. , Jarett, C. , Woodroffe, M. ,& Minocha, S. (2005). User Interface Design And Evalua-

tion. Amsterdam: Elsevier. 4. US Department of Labor (2002) WOMEN IN HIGH-TECH JOBS. 2002 (2), 1. Viewed on 1-10-

2013, at << http://www.dol.gov/wb/factsheets/hitech02.htm>>. 5. Unknown Authors, WIKI (2013) Kleurenblindheid. 2013, (2) 1, Viewed on 12-10-2013, at

<<http://nl.wikipedia.org/wiki/Kleurenblindheid>> 6. TestersAndTools (2011) Fluke ScopeMeter in use at Keithly Electric. 2011, VIDEO, Viewed on

13-10-2013, at <<http://www.youtube.com/watch?v=siG6Wet76Ac>>

16

17