Etapa 3 Análisis de la situación proyectada

Based on the evaluation of the first iteration described above, some adjustments to the requirements are made. Within this section, only the changes in the requirements are mentioned. Since the wireframes are still on a design level and not on a developing level, the accessibility guidelines are not changed and the usability heuristics do not change.

6.5.1. User Requirements, Second Iteration

The complete list of user requirements for the second iteration can be found in Appendix Q. Below, only the alterations are described. Again, their MoSCoW categorisation is based on the interviews. Must:

14. ‘The website must mention that Reducept is an addition to treatment, not a replacement of the practitioner’, becomes ‘The homepage must mention that Reducept is an addition to treatment, not a replacement of the practitioner’

Should:

26. ‘The user should be able to request a demonstration through the website', becomes ‘The user

must be able to request a demonstration through the website’ Could:

37. ‘The website could include a blog’, becomes ‘The website won’t contain a blog’

38. ‘The website could include an FAQ page’, becomes ‘The website must contain an FAQ page’

Accessibility Guidelines _{Not Met}Met/ Explanation

Video: text alternative available (A) Met The video does not include audio

Audio: if audio automatically plays, users have to be

able to stop or pause (A) Met The video is not played automatically Images of text: images of text do not convey

important information (AA) Met Illustrations are for decoration purposes Timing adjustable: if there is a time limit, it can be

adjusted (A) Met No time limit included on this website

Pause, stop, hide: for blinking or moving media (A) Met Video can be paused Three flashes: nothing flashes more than three times

per second or is below flashing threshold (A) Met

No flashes included in the design of the website

Multiple ways: more than one way to locate a

webpage within a set of webpages (AA) Met

The menu is included in both the header and the footer

Consistent navigation: consistent order of menus (AA) _Met The menu in the header and footer have the same order

Consistent identification: same functionality has same

name (AA) Met

Buttons with same functionality are named consistently

Also, some requirements are added: Must:

‘The homepage must mention that Reducept is evidence-based’

‘The homepage must mention that Reducept is a virtual reality E-health application’ ‘The footer must contain important keywords related to Reducept’

‘The pricing page must contain information on patient’s costs after referral' Should:

‘The infographic should contain descriptive titles containing an USP’ ‘The website should contain practical examples’

‘Titles should reflect the purpose of the related text’ ‘Titles should be in the language of the page’

‘Media articles should not be mentioned on the science page’

‘Lorimer Moseley should not be prominent on the science page if he is not on the board of advisors’ Could:

‘FAQ could include a question about patient’s costs in case of a referral’ ‘Referral section could be added to the contact page’

'Referral section could be a separate page’

‘Pricing packages could contain information on type healthcare institution or amount of patients it is suitable for’

Won’t:

‘Different pages for background and team won’t be created’ ‘Referrals won’t be added to the header’

‘Calculations of prices with reimbursements won’t be added to the website’ ‘The website won’t contain a blog’

In order to create a clear website, it is decided to keep the amount of pages to a minimum. Therefore, together with the developers, solutions for the structure of the webpages and the modules are designed.

Moreover, since the goal of the website is to have practitioners purchase Reducept, the referral option is not added to the header. However, it is important to have the referral option included on the website. The decision is made to include referrals on multiple pages instead of having it be prominently present in the header.

It is decided to not include practical calculations for the actual prices of Reducept including reimbursement options, because the reimbursement options are different per sector and country. Also, it is difficult to provide general examples suitable for different practices and practitioners. Therefore, it is decided to explain practitioners can come in contact with the company and calculations can be made together. If, in the future, it is easier to create general calculations, these can be added to the pricing page.

6.5.1. Usability Requirements , Second Iteration

Based on the evaluation of both the interviewees and the company, it is decided to remove a requirement from the usability requirements described in Section 6.2.2..

Requirement 12 (User actions named consistently across screens) is removed. In the wireframes, the call-to-action buttons all lead to the contact page, but including different names on the buttons could help visitors understand different actions can be pursued by filling in the contact form. Therefore, while buttons lead to the same contact page, they have different names.