04 – Critical Analysis and Evaluation of Final Prototype

by | Dec 23, 2018

In the last blog, I will justify choices made when selecting specific user experience methods and processes during the development of a solution to a user experience problem. I will analyse and evaluate the final prototype and describe the design process planning and management, (including the role played by each member of your group) coupled with the artefacts produced at each stage.

Design process planning and management

Planning… Planning… Planning

Half year ago I completed a bachelors degree in digital design and UX where all projects were online and required a team-work (both agile and waterfall), now I work in a global company, where an agile and scrum methodologys are incorporated and the good planning is even more important.

My initial citation of Einstein in post 1 is as adequate to this project as to my own learning paths and work overall. With good preparation, the work goes smooth and mistakes can be avoided.

I have planned where the team and where individual work will be applied.

Figure 1 - Project Graph
Figure 1 – Project Graph

I have planned the timeline in terms of time necessary to complete the tasks

Figure 2 - Project Timeline
Figure 2 – Project Timeline

I have created the taskboard to keep progress clear

Figure 3 - Project Board
Figure 3 – Project Board

I have created a real-time board to share materials and ideas

Figure 4 -Realtime Board
Figure 4 -Realtime Board

I prepared the GoogleDrive channel to share files and big assets (I used it by myself)

Figure 5 - Google Drive
Figure 5 – Google Drive

To keep control of the blog progress I created the Asana taskboard (I used it by myself)

Figure 6 - Asana
Figure 6 – Asana

We managed to meet in person six times.Pdf with team meetings detailsDOWNLOAD

I have used several different tools to compleate the project.Tools listDOWNLOAD

There were 4 phases of the project and at the beginning, we decided we will work separately on evaluation, then join for the research and design and split again for the critical evaluation.List of assets and rolesDOWNLOAD

All links to assets and artefacts are included in the pdf above!

Final prototype evaluation

We did not intend to re-design all the app and we have been focused on just 2 features, therefore 6 heuristics will apply to the final prototype.

  • Visibility of system status – the current position of the user was highlighted in the bottom menu; we missed ( or not? ) confirmation of the goal after selecting it
  • Match between system and the real world – users were comfortable with the logic of information
  • User control and freedom – exit point to me/home screen available all the time
  • Consistency and standards – we fixed the inconsistency problems with menus and icons
  • Recognition rather than recall – the users did next tasks quickly and efficiently
  • Aesthetic and minimalist design – the ‘me/home’ was re-designed and the blog idea was dropped, we cut the unnecessary information also.

The initially diagnosed problems within the app were connected to all its aspects, therefore more complex solution could be applied in the future.

Justification of methods and processes

We have followed the interaction design lifecycle model by Preece, Rogers and Sharp which incorporates the four activities of interaction design (establishing requirements, designing alternatives, prototyping, evaluating), and the three principles of user-centred design (early focus on user and tasks, empirical measurement, iterative design, -> after Gould and Lewis, 1985).

Figure 7  - Interaction Design Lifecycle Model by Preece, Rogers and Sharp
Figure 7 – Interaction Design Lifecycle Model by Preece, Rogers and Sharp

Our activities were focused around 2 main features and tasks from MyFitnessPal, and the interaction design model fit our needs perfectly.

For the evaluation of the prototype, we have used qualitative methods: usability testing with observation and interview were well prepared and performed.

The first survey results were partially used to create personas. The second one, in my opinion, could be dropped, as we have tested 3 users and the interview gave us enough insights.

Survey 1 justification

The survey gave us answers on demographic, the most used features and points to improve. The construction of some questions caused difficulties in analysing data (ie giving users freedom in putting names gave us 4 different spellings of MyFitnessPall and google survey did not merge them) The ‘5 whys’ was not liked (?) by users, and every next one was answered by a smaller amount of participants, which can indicate people were tired of them. The survey could be improved by tailoring questions with the knowledge we wanted to obtain.

Survey 2 justification

The survey conducted after usability test was based on questions around hi-fidelity topic and the formula of questions was exclusively directed to people deeply familiar with the product and technology. For user testing survey they should be rephrased to keep inclusivity of all possible users, not make them feel ‘dumb’ (question regarding the ‘information architecture’) or patronised (‘as a part of a target market, how …’).https://www.usertesting.com/blog/31-questions-every-designer-should-ask-when-testing-prototypes/

Reflection on the assignment and your team

Lessons learned

  1. The importance of the initial communication to establish the pace and expectations of team members
  2. The necessity of all team approval of the crucial points of the projects (plan, scope, timeframe)
  3. In the future, I need choosing more difficult topics to learn more
  4. More thinking less writing – the first post I have created was too long
  5. I’ve learned to summarise gathered documentation into the blog formula
  6. I did extra research on coding for WordPress blog purposes
  7. I expanded my knowledge on user testing process

“Writing is like designing a logo, we should simplify it until one figure will tell everything” – credit myself.

Teamwork

There was two of us in the team and two totally different worlds. My partner, Bronwyn, energetic, holding an independent position as a designer in a marketing company, living surrounded by close family, planning to build a house for herself and her husband. Me, with my 3 kids, working full time, living in Ireland for seven years, with family and roots far far away. Both of us with different life and work experience, sharing the passion for fitness (myself –  cycling, herself – running).

The online communication was challenging. I could not communicate effectively or complete tasks during my working hours, and Bronwyn could not communicate after her work due to the weak broadband in her home area and lack of equipment. My timeframe was much tighter than hers and sometimes it was hard for me to keep up with her pace, but I knew the challenges when I applied for the course and I was prepared to work till the late nights, sometimes throughout the night to complete the tasks, and – we did it!

Some work which was planned as teamwork was done separately and a couple of times we were close to scope creep. I prevented it by dropping out of scope few paper iterations from the prototype and excluding the 4th usability testing done by Bronwyn which did not follow the methodology of the previous ones. The overall teamwork did not work for us, and it became even clearer when I analysed the list of artefacts.  

The empathy and understanding tailored to planning and communication is a warranty of success, preventing scope creep and avoiding tension.

Communication >> Trust and Understanding >> Empathy >> Success

Following the path above is crucial to excelling with team projects. I am looking forward to the new project where I could share knowledge and experience and learn on a higher level of collaboration.


References

By Sebastian Hartleib