This project, developed on top of WordPress, had so much custom coding that it can barely be thought of as a WordPress site. Because I did not want fans of the team to deal with a back-end admin type view to input data, I designed front-end forms and interactions so that user fans and users on staff never had the sort of jarring experience of two different interfaces, making this function like a web app and not the typical WordPress site. The staff put in blog content and player info and that worked more like a Tumblr does, in terms of the experience, so that we eliminated any need for WP training.
This was part of an omni-channel experience for becoming a “Sporting Member” with custom rewards card impact (like a credit card) that fans swipe when paying for something to earn a discount or rewards. Their season tickets are also on that card, which is how they get into a game at the gate. So single sign-on had to be developed for a mobile app, tablet apps which stadium staff used to sign people up on the spot at the gate, and in this application for both tickets AND points earned. All data being driven into the database serving all of these apps was key because of the (desired) real-time updating of the site about rewards, or free tickets, etc.
Here are a few planning documents so you can see my communication style and organization. This was a large project done quickly, involving a software team at SKC, our development friends at Wirevibe and Moblico, all of our Fresh ID team plus design contractor help prior to their new stadium opening. We drew a lot of stuff on whiteboards, took pics with phones, and then designers went straight to visual designs and developers to back-end coding (the overall look had been approved) so I have a ton of uxp artifacts from this project and these are just a few of them.
A. I began by drawing sitemaps and sketches
B. Detailed feature wireframes and dev notes were created along the way.
C. Because we had the hard deadline of stadium opening soon, we kept a visual sitemap up to date with screens that were completed so managers could see at a glance what design had been handed off to developers at least. This was a very handy tool and we kept it printed and posted on the wall at the SKC office we used for a war room.
D. We had a lot of moving parts, and at some point the project manager needed to know what design we had done so far given we had changed the features around a ton to deal with priorities/realities of four sets of developers working on different things that were done or not done, so I put these status documents together.
See the portfolio piece at Fresh ID for the marketing site we designed for this app and a bit more info.