AvidDeals: Mobile App
AvidSphere Inc. is a small company that provides direct mail, print, and digital marketing services in the region surrounding Lancaster County, PA. The AvidDeals App is an extension of AvidSphere’s current services that provides their business clients a way to digitally distribute deals to their customers.
A Design Intern
In the summer of 2016, I was hired by AvidSphere as a design intern. I helped with print design projects and also lead a rebrand project of the company. But while I was there, I learned about an app that the company had previously released.
The app allowed users to redeem in-store coupons at the stores of the AvidSphere’s clients. Cool, right?
Well, there were some issues.
Changing the app's data was quite difficult. To make a change, they needed to remove all the data and edit a few values. Then they would re-upload all of it. Also, the developer was a busy college student who eventually couldn’t continue to make changes to the app and stopped responding to the company.
Needless to say, they didn’t have a great experience.
Side note: Unfortunately, this was not the only bad experience AvidSphere had with developers. During the same summer (2016), an internal CRM was being built by a development agency. It was a train wreck. With a few developers having to be fired, the project went far past the originally stated timeline.
I was curious about the work flow between my bosses (co-founders and co-owners of the company) and the developer. They described it to me, and I've drawn it out below to make it easier to understand.
In case you didn't catch it... There's no problem framing. No user experience mapping. No wireframing. No prototyping.
There's no design.
So, given what I know about the issues and workflow of the previous app, I made a proposal. I told my bosses about the concept of designing an app before you develop it. That way, you can make changes, critique, and iterate on the design before you hand off the project to a developer. Otherwise, you’d likely be paying a developer for those revisions and iterations.
I told them that if they ever considered doing the app again, I’d recommend they take time to plan, design, and prototype the product. Then, approach a developer and have it built.
The following summer, AvidSphere hired me as a project manager to oversee the design and development for their mobile app.
In my role, I knew I wouldn't be developing the app, but I thought it would be helpful to research potential app development methods so I could seek out the right developers. After doing some research on React Native, I found that it seemed appropriate for the app. It was going to be more responsive and performant than a solution like PhoneGap, but code could still be reused across platforms.
I began to reach out to development agencies and freelancers that worked specifically using react native, and a common request was a project brief.
My bosses already had a list of 14 features for the app. I took the list and categorized all of the points into a few groups. The categories ranged from layout requirements to the infrastructure of customer deliverables to admin features. It was a great starting point, but my goal was not to go through their list of features and see how we could squeeze them all into one collective experience. My goal was to ask a lot of “Why?” questions.
- Why should users to see the closest deals to them as the first screen?
- Why can’t the businesses make changes to their own page?
Basically, I just wanted to know why they chose those 14 specific features. What business goals or assumptions were baked in? Asking these questions allowed us to take a step back and try and focus on the users and how each of these features might fit into a broader experience.
Then, taking the features from each category, we were able to create a brief that outlined some main goals of the user. From these goals, we could determine (in wireframing) what screens we would need to accomplish those goals.
When speaking with developers, we were encouraged to pursue building an MVP first, especially since we hadn’t done extensive research. From the MVP, we could pivot, iterate, and –over time– shape the product into something that is user-informed. However, with this, it was clear that everything we had outlined in the brief was not going to fit into the MVP timeframe. If we fit need the project to fit into the timeline, we would have needed more developers, and thus, more budget – which wasn’t an option. So, we were forced to prioritize our features.
Along with the brief, I thought that creating a simple prototype made out of wireframes could be a good starting point for the developers so they could get an idea of the scope of the project. So, as I continued to reach out to developers we passed along the brief and Invision prototype in hopes that we could get quote estimates.
While we waited for quote estimates, I took some time to think about the scope of the project. I realized that this app project was going to be much bigger than just something you download. I began to outline other aspects of the business that would surround the app. What was going to be our promotional strategy? How can we get clients to promote the app for us? What were going to be the touchpoints outside of the app?
Below are a few condensed notes from my thoughts on this
- Mobile App
- User email communication
- Share links from app that open in a browser and redirect to app
- Admin backend
- User Feedback/Research
- Gauge interest from businesses
- Survey users and test prototype
- Business research
- Maintaining client relationships
- User research
- Advertising avenues
- Marketing Message
Our developers came back with pricing and we had it narrowed down to 2 or 3 potential leads, when my bosses needed to have a conversation with me.
The app was going to be put on the back burner.
While we had a budget that we judging our developer quotes by, we needed to wait to build the app and raise capital to help with its funding. Until the business was financially ready to invest in building the app, my bosses were hoping to make a smaller-scale web app that could generate revenue and provide a similar service.
While I admit I was disappointed, this was another opportunity to put to test my designer and developer skills. We contacted our developer leads and notified them of our change in plans. However, since there were a few that seemed like good fits for us, we opened up the door to develop the web app.
The requirements for this web app were primarily that customers could buy deals (vouchers) to use at AvidSphere’s business clients. The deliverable would still have to be an emailed voucher that the customer could print or scan from their phone. Was this even possible?
I got to researching.
Node pain node gain
After a little bit of research, I came across a node package that could generate a pdf. I didn’t know Node.js, but I had had exposure to it through React and ReactNative, so I jumped into Atom and started trying some stuff.
I began research on a Thursday and by the end of the next day, with the help of a few node packages, I had a Node.js app that was generating a custom pdf file and emailing it to myself. Sweet.
So at this point, I knew it was possible to generate a pdf and deliver to an inbox. I revisited the main screens we'd need: landing page (duh), a listing of all deals, a deal product page, and a cart page fo…
Wait a second.
This is isn't just a custom web app, it's an ecommerce app.
I hopped on to Shopify’s developer website and saw that they had an API that looked fairly easy to use. After making a test Shopify site, I integrated the API into my Node.js app and used web hooks to trigger an email after an order was placed. I was thinking if we could have a server app that is listening to our Shopify store, it could generate a pdf based on a customer order and email the appropriate pdf for customers to redeem. My Node adventure started on a Thursday, and by the end of the following Tuesday I had a Shopify store and a local Node app that was recognizing placed orders and sending a pdf with order info.
Now, while I’d consider myself a front-end developer, I like to dabble in a little bit of everything. But, as the famous quote goes...
"A designer who dabbles in Node, does not a secure web platform make."
- Author Unknown
So, we reached out to one of our top developer leads and asked if he had experience in what I was doing. Turns out he did, and so with a little more correspondence and planning, we hired him to professionally execute what I had prototyped in Node.
Projects aren’t always guaranteed to follow through
- This was a tough pill to swallow initially. Putting the project on the back burner meant my job description was also on the back burner. However, the opportunity it gave me to focus on business constraints and pivot to a smaller-scale solution was priceless.
An app is more than just the application
- During my strategy development and research I learned very quickly that managing an app entails much more than deciding on a platform and communicating with developers. It requires a vision for the research, marketing, and advertising.
The opportunity during this summer to identify a problem, propose a solution, and get hired to fix that problem was very satisfying, and while the project didn't always go as expected, it was an extremely valuable experience.