Appia - Mobile Acquisition Platform

Client:Appia Inc.

Appia was a mobile user acquisition network I had the pleasure of working for. At the end of my journey Appia was bought by Digital Turbine, a mobile app advertising platform. With my overall responsibility being UX lead over Appia’s platform it brought many challenges and projects across my plate. The main product I was involved with day-to-day was Appia’s ad network portal (Via) which was used by advertisers, publishers and internal stakeholders. This meant from an experience perspective I was constantly switching context.

Via was a platform that pre-existed my hiring at Appia. It represented the true essence of what I would call startup hacking. There wasn’t much thought put into design, the taxonomy was confusing and the content wasn’t architected in a way that made clear to the user what steps should be first. It was obvious the goal was simply to get something up and running, which they did.

As I worked on many different initiatives I’m going to highlight one initiative, Ad Template Manager, from a 10,000ft view, describing the design process at Appia I helped to craft. As Appia was really a startup, it didn’t have one in place.


The Template Ad Manager was a piece of functionality that allowed internal admin users to create and manage ad templates for inline ads. These templates would be associated with specific ads which were tied to ad campaigns.

My design process started with doing quite a bit of contextual research and interviewing with our internal ad teams. I needed to get a good understanding of their goals and current challenges. I also conducted quite a bit of competitor research to gauge how other ad template systems were designed. My goal for this was to seek out areas of similarities whether in language, process or overall design. Once I was done collecting the data I needed I started white-boarding some personas. I actually conducted this persona study from a horizontal lens knowing the results were needed to feed into other projects.


So at this point I knew who our users were. The persona work informed the next phase of the process which was to determine how each user would flow through the application to accomplish their goals. My objective was to avoid digging into the details and determine a high-level userflow that could serve as a conversation starter with the product and engineering teams. Keeping it simple helped everyone stay focused on delivering the best way to move a user through an application without getting hung up on things that don’t matter just yet, or overcomplicating the flow. It’s all about compartmentalization.


One of the challenges that came to light while being tasked with a few different design initiatives was that the current platform architecture didn’t support the new features the business wanted to implement. Nor was it conducive to a great user experience for the different users. So I was actually juggling a few different initiatives at the same time. One, was the implementation of the Ad Template Manager, the other was overhauling the Via’s information architecture. I created different site maps as my design process continued to unfold. Each one with a specific focus on the appropriate persona. Think of it like puzzle pieces. Some site maps presented less than others depending on the user while others presented more. Together, they formed a site map that represented all users who would be using the Via platform. If you haven’t guessed it by now, this platform was a tool everyone used from publishers, advertisers, internal ad teams and on. This proved to be much more challenging in design and development than a tool for each user type.


Wireframes to a UX professional is kind of like what water is to fish. This is where the fun really starts to kick in because you can start seeing what’s been in your head come to life. Sketch is simply my tool of choice for wire-framing (and high fidelity comps) so I cracked it open and got to work. However, this was a new approach for engineering and the existing product teams. They weren’t used to this. Engineering worked under agile and were used to tossing things together on their own. There was an initial fear that this process could slow things down. I’ve learned this is pretty much a ubiquitous fear. This gave me a chance to educate everyone on the value of going through this process which would actually mitigate opportunities for development swirl down the road. I was able to start communicating early with the engineers to determine feasibility of ideas and once they realized they could start hacking this early it settled a lot of fears.

The Paint

As lead UX designer and pretty much the entire design team I was tasked with leading the visual design efforts for all of Via. This meant defining the design language and establishing design consistency across the entire platform. As I mentioned earlier I mainly use Sketch as my tool of choice. This allowed me to essentially lay a coat of paint on top of the blueprints that have been pretty much finalized. It is an awesome tool.  It speeds up the design process tremendously. As I iterated on the high-fidelity design I exported out the necessary pieces to engineering for baking into the platform.

Building Faster

To help the engineering team develop faster I created HTML versions of the components the platform would use and placed them into an online library. The library sat on top of a Twitter Bootstrap framework. This way, when the engineers needed to produce a rapid prototype in code, or just develop in general, they had a library of a components that they could grab to ensure consistency across the product. The components ranged from buttons to custom editable table grids. A living, HTML component library cuts down on a lot of confusion concerning styles, interactions, placement of components and other implementation concerns.

Design Elements

Incrementally redesigning an existing advertising acquisition platform was a huge challenge and opportunity for me. It is always easier to design a product starting completely from scratch because there are so few constraints. When a product exists you must think about existing user mental models, technical restraints, business impacts, user impacts and the list goes on. But I think that can really be a blessing in disguise because those challenges will certainly create a better product designer.

As you can imagine there was so much more that went into this one project. Collecting user feedback, prototyping with Invision, etc… Hopefully this sheds a little bit of light into what I was able to deliver as the only UX practitioner in an engineering heavy, startup environment.