Card sorting was the primary technique used to collect information about how our target group perceived the application architecture and giving use valuable data for improving it further.
This exercise was conducted for determining the finalized the architecture of the application that was initially designed. The results of this exercise served as input for rethinking the proposed hierarchical information architecture and make changes where necessary after discussion.
Card Sorting Test #1
Card Sorting Test #2
Final Ordered Cards
Card Sorting Results
In the card sorting we found out from users that one main menu wasn't clear as it barley represented the sub menu. So we decided to make that main menu to be sub menu and replaced it with a main menu that can represent all the sub menus. That is the only change we came to because users have easily sorted the cards.
Group One
|
Group two
|
Group three
|
Group four
|
Group five |
|
Card 1: Alcohol
|
1
|
0
|
0
|
0
|
1 |
Card 2: Soft drink
|
2
|
0
|
0
|
0
|
0
|
Card 3: Juice
|
2
|
0
|
0
|
0
|
0
|
Card 4: Warm Drink
|
2
|
0
|
0
|
0
|
0
|
Card 5: Chicken
|
0
|
2
|
0
|
0
|
0
|
Card 6: Sandwich
|
0
|
2
|
0
|
0
|
0
|
Card 7: Burger
|
0
|
2
|
0
|
0
|
0
|
Card 8: Specials
|
0
|
2
|
0
|
0
|
0
|
Card 9: 5 beer 4euros
|
0
|
0
|
2
|
0
|
0
|
Card 10: 2 burgers + drink
|
0
|
0
|
2
|
0
|
0
|
Card 11: Pay
|
0
|
0
|
0
|
2
|
0
|
Card 8: Cancel
|
0
|
0
|
0
|
2
|
0
|
Groups names: Drinks, Food, Specials, Add /Edit and an extra group
created by the users Alcohol
To the highest extent the potential users arranged the
information architecture as we designed. There was a slight difference. For
example one users selected alcohol as a different rather than a sub menu to
drinks. Another user have a bit difference in the add menu buying choosing pay
as the main menu rather than a sub menu to the Add/Edit menu.
No comments:
Post a Comment