UCD Assignment 2 – Final Report – Training Everywhere

1

UCD Assignment 2: Design Report

Sam, Timothy, Dan & Ayo Part 1 -‐ Design Rationale ......................................................................................................... 2 Part 2 – Low Fidelity Designs ................................................................................................... 5 Part 3 – High Fidelity Designs ................................................................................................ 10 Part 4 – Reflection & Evaluation ........................................................................................... 14

UCD Assignment 2 – Design Report for Training Everywhere Sam, Timothy, Ayo and Dan

2

UCD Assignment 2 – Final Report – Training Everywhere Introduction

Training Everywhere are a specialist training company that deliver their material and assessments online, using their training portal. The portal (application) already captures a range of data and enables the users to carry out a series of tasks in relation to delivering/receiving training. While this system currently enables Training Everywhere to deliver their courses online, there are several aspects of the current system which have been highlighted by key users/stakeholders, which can be improved to enhance the overall user experience. Our task is to define these new requirements, make appropriate design decisions and considerations and produce an effective and functional design. Within this report will deliver the following:

1. Design Rationale: Justifications and Design Considerations 2. Low Fidelity Design of system and new features 3. High Fidelity Design of system and new features 4. Reflection and closing comments

Part 1 -‐ Design Rationale Design Considerations As part of ensuring a coherent, clear and effective design, we have defined the following items as key considerations to make throughout each design phase.

• We agreed to clearly identify a logical flow to all processes o This has been achieved be clearly feeding back to the user when they are moving from one

activity to another, by way of pop-‐ups. o We do not want to have too many activities being executed on one page as this can become

confusing for the user. o Simplicity has been a key consideration throughout as the technical ability of the users may

vary, therefore the design is ability agnostic. • We agreed on a standard interface layout:

o The layout needs to be kept as a standard to ensure consistency throughout the design. This is especially important when the design is being delivered by multiple people within the design process. This is also important to clarify, so that when we hand the design over to the build team they are following clear guidelines throughout the build.

o We agreed on the following layout principals to be followed. These are supported by figure 1 § Each page within the application remains clear of any unrequired content to ensure

that the page is easy to read § We have kept a white background with black font to ensure the page is easier to

read § We have kept an options accordion available on the top left hand side of every page

with the same options always available. These options have been chosen as they are the main processes that a user will initiate as per the scenario and the requirements analysis.

§ Search bar always remains top right to ensure consistency and gives the user the option to search on every page.

§ Use of thumbnail tiles to initiate activities/process within the application. This reduces clutter and draws the user to an interactive option.

§ We agreed throughout to provide supporting comments with all options available on the page. This is to allow the user to make an inform decision when executing a task.


3

Figure 1 – Typical design layout

Stakeholders, Users and their Requirements To enable the design, firstly we had to analyse the scenario and understand the stakeholders and users of the system and their requirements. The scenario explicitly listed several key stakeholders and users (Please see ‘Stakeholder identification and Requirements analysis’ below for further details), from which we were able to identify additional stakeholders that needed to be considered within our design. Users, Stakeholders and their requirements are listed here: Stakeholder: Tutor Interaction with System: User of live System Assumptions: Familiar with current system, but not a highly technical user. Therefore, will require appropriate considerations when designing the User interface (UI). Problem/Requirement/interest:

1. Currently unable to administrate tutor components. Would like self-‐sufficiency in relation to uploading and editing modules on the site

Approach to meet user’s needs: As part of the design, we would incorporate an enablement of this feature for the “Tutor User” type, as this level of functionality as stated already exists for the System Admin, therefore does not require redesigning at this stage. Stakeholder: Student Interaction with System: User of live System Assumptions: It is assumed that the Student users are using the training portal as a paid service and therefore need to be regarded as the primary audience for this design. Problem/Requirement/interest:

2. Currently unable to communicate directly with teachers whilst working through the modules. Would like to see a Video-‐conferencing (VC) facility.

3. Quizzes and material currently available online only. Would like the ability to download and print content from the portal.

4. Would like a notification service added to help remind them as a user to revisit the portal after a period of inactivity.


4

Approach to meet user’s needs: In relation to requirement 2, we are integrating an out-‐of-‐the-‐box VC facility into standard UI and this will be activity agnostic, meaning that wherever the user is within the portal they can access the VC the facility and do not need to be doing a specific task such as; completing a quiz to enable this feature. A consideration has to be made for the Tutor user as they are directly linked to this feature and they will have to be included in the design process.

For requirement 3, we will incorporate a simple icon that will appear when the student enters each activity. This icon will enable them to download the activity as a file and either Save or Print the file. For requirement 4, this is a feature that will be added to the core of the application and requires no change to the application’s UI. The output, which will be a simple text and email message detailing the period of inactivity will put forward to the student user for review to ensure that the message has all relevant information to meet this requirement. Stakeholder: Manager Interaction with System: User of live System Assumptions: The Manager user is not technical and therefore would like all information to be presentable in a format suitable for their role. For example, data presented graphically rather than in raw .csv formats. It also assumed that minimal budget is available and the reports will have to be system generated and read-‐only, as further reporting functionality will require additional investment and development. Problem/Requirement/interest:

5. The system does not present the data collected by the system in a coherent way which lends itself easy to further analysis and key decisions. The Manager user would like the system to generate reports detailing the following: -‐ Student Achievement -‐ Module Stats: Start Date, Test-‐Taken Date and how many attempts per student -‐ Achievement records for each course

6. Required as an extension of the above, the manager would like to be share the reports with senior management/directors. Therefore, the ability to collaborate is required.

7. Upon completing the course, a transcript of all activity and achievements needs to be emailed to the students

Approach to meet user’s needs: For requirement 5, we need to consider as part of the design the current data structure within the application, as this is vital for effective reporting. These datasets will be delivered as options within a table whereby the user can select which dataset they wish to perform analysis on. These datasets will be configured by the system administrator. They can then perform the analysis using the new report builder feature. For requirement 6, once the report has been generated, will provide the manager user an icon which will enable the report to be exported. This will enable them to share the report or archive the report if required. This feature has been added and is known as the ‘Collaborate’ feature. Further details are provided later in this report. For requirement 7, this will be delivered as a simple export from the datasets created as part of the design exercise used to fulfil requirement 5. The Transcript is a simple tile icon on the homepage for this user and will export to a selected recipient. Stakeholder: Director Interaction with System: User of live System Assumptions: Similar to the manager user, the director user is not technical and therefore would like all information to be presentable in a format suitable for their role


5

Problem/Requirement/interest: 8. Requires a broad range of reports for strategic decisions

Approach to meet user’s needs: The user will have full access to the report builder and my reports. If they require a custom dataset to be configured for analysis, they can launch this request to the System Administrator and they can build a dataset which is then accessible. Additional stakeholders and considerations within the design process Stakeholder: System Administrator Interaction with System: User of live System Assumptions: Will have in-‐depth system knowledge. Problem/Requirement/interest: No explicit requirement listed in the scenario. System Admin will need to be consulted on additional limitations within the system that have not been listed as they will have a high level of system knowledge, as well as being incorporated in the design. Will also need training on new system features once live. Stakeholder: Programme Sponsor Interaction with System: Minimal/Indirect Assumptions: The programme sponsor will have a minimal budget to complete the new enhancements. Problem/Requirement/interest: The programme sponsor will set the budgets and the build team will have to align the new features with the finances made available by the programme sponsor. They will also have interest into the potential increased use of the system after the release of the new features to see if the investment was deemed a success. Will ultimately have all authority in relation to signing off the design. Stakeholder: Technical Development Team Interaction with System: Pre-‐Production Assumptions: Will be running the development using an agile methodology. Problem/Requirement/interest: The Technical Development Team will be involved during the design, build and testing of the new features and will drive the interaction with the users of the system to ensure their needs are being met with each feature.

Part 2 – Low Fidelity Designs Once the requirements had been confirmed, the next stage was for us to demonstrate how we fulfil the requirements by creating a series of low-‐fidelity designs. These designs are in place to conceptualise how we interpret the requirements and how they align with the current system. They also enable us to put these concepts in front of users and gather early feedback prior to further building on these designs in the form of a high-‐fidelity design. For the designs, we have identified two privilege types. One which provides a view specifically for the Student user. This will be referred to as the ‘Student’ view hereafter. This view enables the student to access content which is applicable to their requirements, for example; the ability to view training material and complete a quiz. The student user does not have access to administrator type privileges such as the ability to add/remove course material and create/share reports. The second privilege type identified will be referred to as the ‘Management’ user. The users in scope of management are the Tutor, Manager, Director and System Administrator. This user has the ability to Add/Edit course material and the ability to add users (General administrator rights). They can also create reports from datasets and share these reports.


6

Low-‐Fidelity designs – Management View Figure 2 – LFD Landing Page for those with Management privileges

Figure 3 – Reports landing page


7

Figure 4 – Create New Analysis Page

Comments and Considerations: The purpose of the low-‐fidelity designs was for us to conceptualise several of our design considerations outlined in our rationale. What this design does is quickly show the user the options they will have available to them as primary activities and these are presented to them as large tile icons within the main body of the page. It also demonstrates how we have considered branding and labelling for Training Everywhere. It will be demonstrated in later designs how this was made standard. What we have delivered above are 3 primary designs that demonstrate our proposal to meet the following key requirements; “Currently unable to administrate tutor components. Would like self-‐sufficiency in relation to uploading and editing modules on the site” – What we have done as part of the design is provide an ‘Edit Assessment’ tab for the user to upload and remove existing content on the site. This can be found within figure 2 Figure’s 4 & 5 demonstrate how we are attempting to meet the several requirements for reporting and collaboration within the application. We have designed a new reporting feature which previously was not available within the old application. The feature will enable the users to create analyses from datasets and share their reports with other users within the application. The designs provided demonstrate these features at a high-‐level.


8

Low Fidelity Design – Student View Figure 5 – Student View Landing Page

Figure 6 – Live chat and Video Conferencing option


9

Figure 7 – Demonstration of Video Conferencing in action

Comments and Considerations The views for both student and management profiles have been designed using the same layout considerations as highlighted in the design rationale. We have kept a consistent accordion of options on the left hand side and all branding has remained consistently positioned. All of these measures enable the users to quickly become familiar and confident with the layout. One of the main differentials between this profile and the management profile is the inclusion of a video conferencing and live chat feature between the student and a tutor who is signed into the application. Another key difference is the removal of the reporting feature as this is not required or applicable to this user type. Feedback and response to designs Part way through the design process, we put our designs in front of several STAR students from year 1 in order to collect some feedback and make further improvements to ensure that all elements of the design had been covered. The following key points were raised:

1. The design document had limited ‘sign-‐posting’ – This made it difficult for the user to understand the concepts without having to ask the designer in attendance. This will be something that will need to be improved when building the high-‐fidelity designs.

2. The reporting module designs required further elaboration – As this was the primary new feature to the existing application, the users would like to see more information regarding this and the considerations made in regard to ease of use

3. The considerations in regard to layout were appreciated and received well 4. The designs were very ‘high-‐level’ and lacked real detail – This will be something that will have to

be added as part of the high fidelity design.


10

Part 3 – High Fidelity Designs With the feedback in mind, we developed a series of high-‐fidelity designs which would better demonstrate how the system would appear on the user’s interface, as well as demonstrate the logical flows through each activity within the application. Understanding the logical flow was one of the major considerations we made as part of our rationale, as we want the tasks within each process activity to be clearly identified to the user as they make their way through them. As we did with the LFD’s, we split the design interfaces into Student and Management. These are demonstrated in the following screen shots. For the creation of the High Fidelity designs, we used a wire framing tool called Balsamiq. This is an online application that allows us to create mock-‐ups of our new application features. The Design in full can be accessed using the following credentials: Site: https://trainingeveryhwere.mybalsamiq.com/ Username: [email protected] Password: Assignment2 Note: It is important to note, that following our round of feedback on the LFD’s, we have used ‘sticky notes’ to provide guidance on each page of the design. This to help the user understand the considerations made and why the feature exists. Please refer to these for comments and considerations. Figure 8 –Application Log-‐in page Log-‐in>


11

Figure 9 –Management (Tutor) user landing page – Log-‐in>Home

Figure 10 – My Results Page -‐ Log-‐in>Home>My Results

Note: The following designs will build on the reporting functionality highlighted as part of the LFD. After taking on-‐board the feedback, we have elaborated on how the reports can be built using the report builder feature, as well as adding a feature known as ‘My reports’. This is a collection of all the reports created by the user meaning that the they do not have to create a new analysis each time they want to publish a report.


12

Figure 10 – Create new analysis process

The ‘Create new analysis’ feature Figure 10 demonstrates the logical flow as to how the user will construct a new piece of analysis. This flow is broken down into 4 key components:

1. The user will select the data they wish to perform the analysis on a. This will be set-‐up by the system administrator

2. The data sets available to the user will be presented via pop up window. This removes the need for the user to search of find data sets. The standard data sets for each user are those listed in the requirements section of the design rationale.

3. Once selected the user will be returned to the page and asked to select a chart or graphic that they would like to use to present the data

4. As soon as graphic has been selected, the analysis will be presented and the user can either save to a report or edit.

Figure 11 – My reports -‐ Log-‐in>Home>My Results


13

Figure 12 – Collaborate and Share Reports

The ‘Collaborate’ Feature Figure 12 demonstrates how the flow for the collaborate feature operates. This feature was requested by the Manager user to enable them to share reports they have created with their director. We have extended this feature to cover all manager type users. It follows four simple steps:

1. The user will click the ‘Collaborate’ icon to launch the process 2. The user will receive a pop-‐up window which will list all of the reports they have saved in ‘My

Reports’. The user will then select the desired report for sharing 3. The user will then receive a new pop-‐up window with a list of sharable users. The user will select from

this list and the reports will be shared accordingly. 4. The user will receive feedback on the success of their process. This is an important design

consideration. Figure 13 – Video Conferencing and Live chat


14

Part 4 – Reflection & Evaluation Looking back at our design, there are many areas where we can be proud of what we have delivered and the considerations we have made. Naturally, with any piece of work, there are areas which if we were to go through this process again, we could do differently. Firstly, looking at our strengths, I feel that the considerations made in the design such as ensuring a clear and unambiguous layout, consistent colouring and object placement (Accordion, live chat and process launch icons), as well as, ensuring that all activities follow a logical process, have enabled the design to be as completely agnostic to all types of users and their technical ability.

Secondly, throughout the design, the stakeholders and users have been clearly identified, along with their requirements. This reduces the level of ambiguity when handing over the design to the development team as they are frequently reminded which feature is applicable to each user. A lot of work went into identifying the key users within the stakeholder community. This was to ensure that all requirements that were listed within the scenario were captured. This is something that as a group, we would be sure to do again as part of future designs. Another key strength of our design was the acceptance of feedback from users and individuals looking at the design from outside of the design team. This feedback was vital in ensuring that we considered additional design suggestions such as clearer sign posting and greater elaboration when it came to new features as part of HFD. This enabled our HFD to be of a good standard and provide the user with a clear concept of what we were trying to achieve as part of our design. With these strengths in mind, our design also has several areas which will need to be improved upon next time. Firstly, as noted in the first round of feedback, we need to provide greater detail to help the user understand the concepts in the LFD’s. We introduced this detail in the form of ‘sticky notes’ as part of our HFD, but with this missing as part of the LFD, we missed out on crucial feedback in relation to the logic behind the new features as the individuals providing feedback were more focused on pointing out basic items missing from the LFD’s. This leads on nicely to the next item which could improved going forward, which would be to open up a more regular forum for feedback. We saw the benefit of going through 1 feedback cycle and the design was greatly enhanced as a result. For future designs, we should look to open our design to more feedback cycles and monitor our progression. It would have been good for us to have had someone critique our feature functionality rather than just the look and feel aspects of the design. Finally, it would be beneficial to provide the same level of detail and design for all features. Several features such as the reporting feature and the collaboration feature got a more focused and detailed design in comparison to the course transcript and notification service. This is because the reporting & collaboration features were deemed as more critical and therefore got more focus, however going forward, all features require the same level of explanation as it will leave these features open to interpretation when handed over to the development team. Please refer to our appendices for:

1. Full HFD 2. Additional LFD’s 3. Storyboards 4. Timothy personal reflection 5. Dan personal reflection


15

Appendices & References

1. Dan Personal Reflection My personal reflection and experience on the User Centred Design Group Coursework2 this semester was a bit daunting, I must admit. However, it is must not be seen as an admission that I did not understand the entire concepts of what the module entails. Some of the challenges, which I personally experienced; have to do with the tutorial sessions which I did always miss some vital parts. I love listening to Dr. Safia when delivering lectures and sharing her vast words of knowledge and experiences, but time was not on my side to share this pervasive words of knowledge during her lecture. And this was not entirely my fault, but the timetable, which overlaps two module schedules. It is necessarily important to point out that this semester alone, I have three modules to deal with: User Centred Design, Business Database Management System and Accounting for Manager as a part-‐time student. Accounting for Manager timetable overlaps the User Centred Design of which I could not help the situation but coming into the lecture late, nearly towards the end. Obviously, you would certainly agree that I should have missed most part of the important tutorial sessions and ended up with little knowledge of what had been taught for the day or sometimes nothing at all. But do not forget, I have the lab session as a backup. It is an environment where I would regain some of the losses at the tutorial sessions. Should I accept this experience as part of the learning-‐curve or something? Something, which I am yet to find out. In addition, I chose to study Information Technology as my core discipline in this Institution, I am very determined to achieve this objective and henceforth, ensure to engage myself with the little time on my hands to work hard and understand every module some extent. On this occasion, this is exactly what I did. I have a little knowledge of User Centred Design or not all, at the beginning of the semester. However, the introduction of the module basically is an eye opener. I found it very engaging, which requires dedication and some level of disciplines and is most useful to the programme that I chose to do. Through the group work, I have acquired some knowledge and useful experience from my colleagues. The mock-‐up design and the high-‐fidelity design was completely something new to me. During the group meetings and my lecturer explaining the ideas of what User Centred Design is about, I began to gather the basic knowledge and now have fully understood the entire idea, which is something that I am very proud of. To summarize this reflection, I must not fail to mention one important colleague and his brilliant knowledge by simplifying the methodology of what User Centred Design is all about. My apology to Samuel Phillips. There is no way I could do to circumvent this reflection without having to highlight the name of Samuel Phillips. He has the skills of an expertise and was prepared to share this knowledge with the group. I observed him as someone who is cautious in approach, calculated and meticulous in what he does. He took control of the centre stage and reinvigorated the spirit of the team in entirety of the design. His work is exceptionally unique by any standard and I do think he deserves the individual respect from the group.

2. Full HFD Site: https://trainingeveryhwere.mybalsamiq.com/ Username: [email protected] Password: Assignment2

3. Additional LFD’s

• Storyboards


16

• Reporting • Mobile APP

Training Everywhere

Logged in as: Manager

Summary of achievement

Course

IT

All Courses

Networking

Engineering

30%

50%

10%

20%

All Courses

Share to Executive Director Email module marks to Students

Generates Summative Report


17


18


19


20


21


22


23

4. Timothy Reflection During coursework two I have learnt how to do user evaluations for a scenario which is called Training Everywhere. I have learnt this by creating a low fidelity design and getting feedback from the users about it. Also I have learnt that high fidelity design is a prototype of a working system to meet user criteria. During low fidelity design there were some changes to be made as there was some confusion. The confusion came from some team members making a mistake, as they thought that they were meant to create a low fidelity design app, when they were actually meant to build a website. The team then re-‐read the user criteria carefully, and had a better understanding of what the user wanted.

Date post:	09-Jan-2017
Category:	Documents
Upload:	timothy-adrian-lam
View:	184 times
Download:	0 times

UCD Assignment 2 – Final Report – Training Everywhere

Documents