The Sacramento Kings already had an app. But with a new arena being built, the Kings had an opportunity to be innovative. The Kings approached us with a grand vision of an app that would serve the fans of the Sacramento Kings as well as those who frequent Golden 1 Center (G1C) for their other entertainment events. This meant that, in addition to the robust set of features that users come to expect from a standard basketball team app like stats and news updates, there was to be an entirely different aspect for G1C fans, and a slew of advanced features that take advantage of the technically sophisticated arena for fans who are physically present in and around it.
Approach Before starting any work on the app, we needed to understand our client’s overall vision, and discern between what were actual requirements and what were nice-to-haves. My boss and I had several interviews with stakeholders whose roles ranged from marketing to technology, and we began tracking these requirements in a document. A pattern emerged from the list of requirements and we were able to discern what features and parts of the app could be tackled first, and what required more information from third-parties before proceeding. This made things complicated, but it helped immensely that we we learned this upfront so that we could adjust our process to account more for the unexpected.
We were able to account for the third-party integrations, though, and so that was enough for us to begin mapping out the structure of the app. We started with a set of features and did a card sort where we grouped like features together which laid the foundation for a sitemap. The sitemap doubled as a user flow to show which screens users would navigate through while performing key tasks. The sitemap would ultimately undergo several changes throughout the project, but it served as our roadmap ensuring that we were on track at all times.
Design Once we had our sitemap, we identified several key pages and began creating low-fidelity wireframes that were intended to establish a basic UI language for which the visual design could be based on. I continued to wireframe screens for the rest of the app including their several states. For example, we expanded on the requirement of showing updates and devised four different stages (pre-game, pre-tip-off, during-game, and post-game) in which the app would serve up different, timely information, so each of those states needed to be shown how they work as a user interface.
Our creative director who had been following our progress thus far, used the wireframes my boss and I produced and created fully designed comps of them. The visual design of the app would undergo a revision process of its own, separate from the information architecture and overall user experience strategy because we were able to work on each aspect independently and integrate our work as necessary. This proved to be critical in allowing us to be flexible in how we design because of the third-party integrations. The client gradually made agreements with third-party vendors throughout the course of the project, up until the very end, so we couldn’t start work on the design for certain components until we got the approval to do so.
User Accounts A separate aspect of the the app that was noteworthy in terms of problem solving was the user accounts and on-boarding. The Kings had an existing partnership with Ticketmaster whose existing ticket buyers had an account with. We wanted to merge those users with the new vendor’s user account management system so that there would be only one consolidated database. This required communication between the separate vendors and technical team to work out the logic and functionality, and coordinated effort to ensure hooks and connections were made. This effort culminated in an account signup flow that ultimately got merged with the on-boarding/tutorial flow. We planned for the tutorial to be designed towards the tail-end of the project when we had most of the critical features designed.
Mapping Mapping was intended to be another feature-rich aspect of the app experience. At one point, my team and I were coordinating the integration of three separate mapping technology vendors for indoor mapping, line-queueing, and parking, but the latter of which ultimately got dropped. The remaining two vendors only offered their technologies but had no applicable user interfaces for which we could leverage. Ultimately, I ended up designing the user experience of mapping feature and had to work out the logic for how attractions should be categorized and listed, and how the friend-finder feature and all its privacy considerations should be handled.
Prototyping The down-time between when the third-party negotiations were still underway was used to our advantage to refine existing designs as well as to test out new ones through the prototypes that I created using Marvel App and Principle. We tested the user flows with the Marvel App prototype that made use of the high-fidelity comps that our visual designer created. Marvel App is similar to InVision, but was ultimately used over that because it has the ability to create a “sticky footer” in the prototype-- a minor feature that proved to be beneficial to convey realism to the client. For more granular interaction design, I used Principle. Those granular prototypes allowed us to validate some of the design decisions made by being able to physically interact with it, as well as to really refine the user experience of the app by giving the developers precise animation queues to reference.