UX Project Retrospective #2: Lee Kuan Yew School of Public Policy
This is a retrospective article on the development of an UX exercise over the course of two weeks, focusing on an imaginary redesign of the site belonging to Lee Kuan Yew School of Public Policy in NUS. It will cover my process from competition analysis to an Axure prototype.
TL:DR Lessons Learnt
#1 Have a design process and schedule and stick to it as much as possible#2 Effective card sorting isn’t that easy. It requires multiple rounds, iterations from yourself, context and sorting out odd data#3 Do not allow preconceived notions to affect solution design. Evidently this is a problem that I need to work on consistently
Axure Prototype: http://evo0z7.axshare.com/#g=1Presentation:https://docs.google.com/presentation/d/15N0joILwzqKYAiI8W3b7csfGo3sv01RYHZ_gyVbRVSY/edit?usp=sharing
We started the project as a team and I worked with two other members to analyse user flows for three personas and to breakdown the content of the existing site. I chose to take on the task of redesigning the site for a user persona that was looking for executive education, and had the monetary and time constraints of being a working father. His presumed objectives were to find:
Executive course information
Course schedules/Daily schedules
Faculty information
Financial aid
Childcare services
Application information
I suspected that we would soon run into confusion with the various processes that we had to take care of, and therefore decided that our team would have a shared schedule on Google Drive that we could reference and edit so that we wouldn’t get lost along the way. This turned out to be pretty useful and we made a point to make updates to the schedule whenever we met.
We also built our design process around iteration at every point. Any user exercise we conducted could be learnt from and improved upon, and every stage of change had to be user tested and improved. Hence lesson #1 Have a design process and schedule and stick to it as much as possible.
The above consists of a list of contents of the site, as well as a site map of all the pages. From there we can derive a user/system flow for my user persona as shown below.
Things weren’t actually all that bad for my persona, if one were to view it from a flow chart. But by taking a look at the site and by observing users attempting to navigate it, it becomes rather obvious that the current site navigation isn’t very intuitive, and is especially bad for the other two personas that my group was working on.
There was also a lot of content and media that were hidden in deep layers, and much of it was very wordy and difficult to get through. And so we came to a couple of conclusions:
Some pages aren’t placed under menus and sub menus that users expect them to be at
Some menu items are not understandable by users and they either avoid them all together or take a while to decide to check what’s in them
Navigation to some useful pages is too deep
Navigating long pages are a problem ( even though users are willing to sift through them slowly )
Step 2: Information Architecture Redesign
With our findings, it was obvious that something had to be done about the way the site was laid out. So we picked out some items from the site and ran a card sorting exercises with users who fit our target personas. Then I redesigned a new site map, and ran card sorting exercises again and made even more changes as the sorting results changed.
It was during these card sorting exercises that I realised that it wasn’t as easy as I thought to conduct the sessions so that I could have the most meaningful data I wanted. On one hand you needed users to arbitrarily place things into groups, but on the other, without any context they may not arrange things in a manner that suit your purposes. In the end I used a hybridised system that included different kinds of restrictions and amounts of information given to the participants to get what I needed. Hence lesson #2: Card sorting isn’t that easy.
The image above is of my new redesigned site map. Everything that has been highlighted in green has been either renamed or moved. Testing on this showed that users could navigate it easily and that it worked well. It was then time to bring that into an actual design.
Step 3: Wireframing/Prototyping
Taking reference from some ivy league schools and art schools, I started off with some overly complicated designs. But it didn’t feel quite right to me as the point of my project was to reduce clutter and make it easy for a potential student to navigate.
I based my design largely on side bar navigation and discovery. The idea is that different options and related links would be displayed depending on where you were on the site. And navigating to those related links would expose the user to even more relevant information and services from the school.
Also anchor links were added to long pages for easy navigation, and buttons to relevant pages were added to sections of long pages. This is apparent on the programme details page in my prototype.
The prototype can be found here: http://evo0z7.axshare.com/#g=1
Conclusion
I am still unsatisfied with how long the drop down menus are on the header, and given more time and actual exposure to the clients, I would work with them to reduce unnecessary information and media.
Also I realised that because I started the project thinking that this is a school website, and it merely needed to conform to the norm of how school sites are navigated, I had unconsciously put restrictions on what kind of solutions could be implemented. Some of my classmates had filter systems and question-and-answer systems that I thought were pretty clever and I realised that I had let my pre conceived notions get to me. So the last lesson I learnt is #3 Do not allow preconceived notions to affect solution design. This I will definitely keep in mind for the rest of my projects these few weeks.
image url:
https://cdn-images-1.medium.com/max/800/1*8plPk_4cO5RIDOAIQ523cA.png