PROJECT THREE • IxDA Conference App

The first part of the project required a lot of planning, given it wasn’t simply myself working on a project at my own pace. I needed to clearly outline the scope of work throughout the entire two week period for someone else as well as myself— while simultaneously worrying about if I was capable of such things. Thankfully, we agreed on our scheduling and personal capabilities, plus our processes were identical — which set up a great framework for working as a pair.

Initially, we went through the current app together and took note of some of the things we found needed improvement. Thankfully, due to strength of the current brand look-and-feel — a minimalist approach with a strong colour palette and solid, legible font — we didn’t deem it necessary to redesign everything entirely, just rearrange, re-categorise and make slight alterations to existing functions. A few things we noted were;

1. The menu on the homepage. We found this to be particularly confusing. Separating out ‘Speakers’ and ‘Workshops’ from the ‘Program’ on the homepage seemed redundant and unnatural in terms of navigation. We saw the opportunity here to group these together and consolidate the navigation into fewer categories, making the homepage clearer and easier for users to find what they’re looking for. Along with this, having separate ‘My Schedule’ and ‘Schedule’ pages was quite confusing — “What do these mean?”, “What is the difference?”, “Why do these need to be separate?”, “How does this help the user?”. We ultimately decided to consolidate these into one section as well.
2. No filters or search functions. This one seemed particularly odd to me. The purpose of the app (to me) was the ability to search for information about the speakers, workshops and social events held at the conference and add them into a personal schedule. However, no search function existed — a huge oversight, in my opinion. Not even the ability to navigate through the extremely daunting 50+ list of speakers with an advanced scrollbar.
3. Schedule pages cut off room/venue names. This was another huge issue for me in terms of usability. The fact I cannot see the venue name in my schedule at all — and I mean, at all, there is no way to select the venue name in this screen to expand it— deems the feature completely superfluous. Furthermore, the app does not support the ability to rotate the orientation into a landscape view — which might have helped in this circumstance, to lengthen the boxes to a point of visibility — that also may have helped…
4. Maps. Maps in the current app need to be scrolled side to side to view them fully, with a static key/legend which sits to the left — meaning the user has to constantly scroll back and forth. Why? This seemed silly, but paved the way for easy improvement.

After establishing a connection with the brand, understanding their product and experimenting with their app I embarked upon a competitive analysis — pitting the IxDA app against four similar design conference apps, and noting the differentiating features between them.

Through this we were able to establish the gaps in the market and potential features which might set our product apart from the competition — and also align the current app with industry standards. It was interesting to note that a bulk of the features we originally thought were necessary or might be common were absent from most apps. Based on this, it was clear where we needed to focus our attention for further developing the app and integrating new, pioneering features.

Next, we needed to find out who our users were and validate some of our early assumptions. We did this through an online user survey. Part of the brief we were given for project three was to create two user personas, so essentially, to pinpoint two different personalities connected to IxDA — those that attend conferences and those who speak at conferences.

This was a complete failure.

Well, maybe not complete… however, we were unable to get more than three responses from those who had spoken at conferences, and thus, were unable to complete a portion of the assignment. Even after days of trying different social media channels, reassessing, rewording and adding/subtracting questions in our survey. We simply were unable to extract enough data from the answers we received to successfully make a persona. This was a big pitfall for a number of reasons:

1. Not being able to complete the assignment to meet the requirements.
2. A big time waster, which meant we were behind our project plan schedule.
3. Generally feeling helpless.

Despite all this, we trudged along with our single persona (the conference goers/attendees/audience members), which thankfully we managed to cultivate a great pool of data for. Some of our key findings were extremely interesting, notably:

• The biggest pain point for most people (just shy of 50%), which they stated would prevent them from attending an event, was the time spent waiting in line. However, the data showed that people were not interested in having the ability to check how long wait times would be prior to their arrival.
• Less than a quarter of people had attended a conference which utilised an app to help their audience members plan and have easy access to event information.

From here, we conducted some user interviews with those from our survey who were open to being contacted. These too revealed a rather detailed explanation as to the behaviours, interests and backgrounds of our users. We covered a few pivotal points such as:

• Their occupations
• Areas of personal interests
• Their past experiences at conferences and which ones they have attended
• Any issues they’ve had whilst attending

The information we gathered from our interviews heavily complemented our assumptions as well as our survey data — which was a great feeling — knowing we were on the right track was very reassuring. Most of the data skewed toward a design-centric audience (those who were currently designers or were looking at a career transition to be one), difficulties in navigating between locations, scheduling conflicts between two (or more) speakers and a desire to communicate with the conference speakers.

Based on the user interviews and survey data, we were able to create a persona— a user profile which cumulates a group of individual responses and streamlines that data into a single identity (or stereotype, if you will) using a bell curve/majority synthesis. The purpose of doing this is to discover who our primary users are, so we can properly and appropriately design an experience or product for those individuals — this really helped with prioritising which features to add to the conference app. After discovering who our users were, their needs and their pain points, we proposed four tasks that this user might require to carry out when at the conference:

Find lunch nearby.

Get directions to the next conference venue based on your current location.

Vote for a topic you’d like a speaker to cover at the conference.

Live stream a speaker’s speech.

Based on these inquiries as well as our interview and survey data, we then prioritised features to add to the app to help the user carry out these tasks and help with their pain points. The four features we decided to add were:

1. Location services to find nearby facilities, e.g. cafes.
2. Venue transit time/distance calculator and reminder function.
3. A way for conference goers to dictate content covered based on their interests via a topic poll.
4. Live video streaming capability.

After deciding which features to integrate, we began sketching some ideas of how these features would be laid out visually, which we then turned into wireframes. Whilst designing the new features, we also decided to redo the hierarchy of the current app structure, combine sections together, and subsequently figure out how our new features would fit into the app structure. We came up with four categories for the main navigation — Program, My Schedule, Maps and FAQ — which we felt were the most easy to understand and most importantly, the most relevant to our key user/persona.

Our new structure streamlined the navigation process to avoid unnecessary repetition and previously confusing terminology and categorisation (for example, we eliminated ‘Schedule’ as this clashed with the next option, ‘My Schedule’). We also consolidated the previously separated ‘Workshops’, ‘Speakers’ and ‘Program’ simply into one category — ‘Program’, as this made the most sense from a user perspective— and added filter options to select the different event types within the Program screen itself. We also removed the secondary screen on the homepage which listed a set of related events and moved this into an FAQ screen (or at least, intended to — we didn’t create this screen in our prototype but certainly kept it front of mind when considering where to group information and features). During the navigation of the app itself, we added a sticky navigation bar to quickly access the homepage as well as your personal profile and schedule.

From here I created a low-mid fidelity prototype, using our wireframes and new categorisation/navigation structure, then conducted five usability tests. I asked each of the five users to complete the four tasks we had established, using our newly integrated features, to see if our designs were instinctive and intuitive to operate. The outcome was fairly positive, most people were able to navigate themselves without getting stuck or confused; we even had one screen where 100% of users were able to navigate themselves without any mistakes or fumbles — flawless victory! But, regardless of the positive response, there were still things to improve upon:

• Adding a screen for the ‘My Schedule’ page. We assumed that users would go to the program to search for speaker information, however, a large portion of users tried to access the ‘My Schedule’ page instead. We’d yet to create this screen, but now deemed it necessary for our second iteration.
• Streaming now/streaming soon status. It became clear that people were unsure as to how the video function worked and whether they had achieved the task successfully. We decided to add a clear differentiation between which speakers were live streaming currently and which were to occur in the future.
• Remove separate live stream page and integrate with speaker profile. Initially we created a page whereby if a user selected the live stream filter in the Program dropdown, it would lead to a page of all the videos currently streaming. Not one user utilised this function, so we decided to remove the page.
• Ability to navigate to a venue by selecting directly on the map. This one wasn’t something I’d originally considered, but made sense in hindsight — thanks, usability testing!

Due to the confusion regarding where to access some of the information in the tasks we’d assigned the users (namely, the usage and differentiation between My Schedule and Program), I decided to conduct a card sort to further validate and confirm we were correct in our initial categorisation assumptions. The test was a complete success and confirmed the program screen was the first place people would look for speaker information — which was very reassuring. However, due to the usability testing, we still thought it was necessary to create a My Schedule page for our second iteration prototype.

The second iteration was a high fidelity prototype. Here we were able to assess the UI, strip out some of the intense, overwhelming blocks of colour in the current app and make it easier on the eye — as well as less daunting to navigate. Implementing all our findings from our testing, the new high fidelity prototype felt like it was a big improvement from where we started.