LunarLincolnLunarLincolnLunarLincolnLunarLincoln
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
Sep
29

Working with Us

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : App Advice, Business, Coding, Design

How does this whole thing work? Head to Hand. Brain to Phone. Lightbulb to Lightning Cable?

If you already have an idea of how building “apps” works then you’re most likely coming into the office with all your information ready and questions answered. However if you’re not really sure about how the idea gets from your head to the phone – we would like to give a little rundown of our process.

First. We discuss the idea.
There are two questions that need to be answered before any work can begin. First, what problem does this app solve? Secondly, who is the app for? If you don’t have solid and concise answers to these questions, you’re in for a whole lot of frustration and financial pain down the road. When you’re a month into development, and much too close to the project to remember where you started, you’ll love being able to go back and see if your new questions fit your initial value proposition. Yes? Great. No? Leave it. Knowing what you’re building prevents scope-bloat and allows for marketing/pitch success.

200-5

Second. We refine the idea.
Once we know what we’re building and for who, we sit down with our UX expert to refine features. You need a calendar app – great. Does the calendar need to send meeting invites? Do you need to see detailed listings or just high level? Do you want the views to be changeable (daily, weekly, monthly). Will the calendar send push notifications? What about having multiple calendars? As you can see requesting “a calendar” can have a lot of options.

We are here to show you what is ideal for your app and its users, what is possible, and what is cost efficient. When you say you want a house – is it this? or this?

screen-shot-2016-09-29-at-3-48-06-pm

During the ideation process we build wireframes. Wireframes are individual screen plans for all of the app’s features. The final wireframes allow us to give you a really strong idea of scope and timeline for development and serve as the app’s architectural plans. Without building wireframes we could guess at a feature list like “calendar, menus, list of cats” but it could easily fluctuate depending on what your interpretation of that feature really means (see the “houses” above).

Third. We design and test with real live users.
We take the wireframes and lay design on top. We will get a feel for the design on the project not only from who the targeted users are but also the brand and goals of the product. We do this in several ways – looking at competitors, apps the client likes, and making pinboards (yes, they’re useful for more things than your mom’s craft projects). We also place the design in a prototyping tool, Invision, where testers can click and explore. Post-design/pre-development is the best time to make sure what you’ve built works well with your users. You’d be surprised what you learn.

giphy

After the design is approved and flows are optimized based on user testing, the assets are exported and ready for development.

Fourth. We get to coding.
Our developers take the wireframes, designs, and interaction instructions and build “user stories”. These stories compose the scope of the project. “A user can tap a login button to view a login screen” or “A user can tap “support” to bring up a completed email” or “A user can view a loading animation”. These user stories are the meat of the project. If a feature is not clearly specified in a user story the developer will not know what to build. Or really – we can make assumptions. But we all know what happens when you assume….

Many times while coding, there are additional choices to be made (how should this baby be built under the hood?). With code being broken into smaller user stories a client can come in at any time and re-prioritize tasks, leave notes on current tasks, or adjust the plan without affecting the past work or current schedule.

Fifth. We test and deliver the code.
During development, when a set of user stories are finished (similar user stories are grouped into Epics – ie. “onboarding”, or “settings”) they are tested and reviewed by other crew members. If everything looks great, it is sent to the client. We generally like to send “builds” of code to the client at least every two weeks.

200

Steps Four and Five on repeat.
Code. Review. Test. Code. Adjust. Review. Test. Adjust. Code. Code. Code. Review. Test.

Sixth. We publish the app.
When everything is ready for a current version – we push it to the app store. That doesn’t mean it magically appears in a user’s hands. Apple and Android once again review your code and make sure it is in working order for the user. After their approval, it is in the store ready to be downloaded, promoted, and used by your adoring fans.

200


Dec
26

Building an App in 2 Weeks

  • Posted By : Jonathan Wiley/
  • 0 comments /
  • Under : App Advice, CaseCollage, Coding

Me: So you have an app idea you need built? Excellent. What’s your timeline?
Client: ASAP. 1 week if you can, 2 weeks max.
Me: Okay, that’s a tight deadline. Do you have a complete design?
Client: No. We’re still working on the wireframes and may need to make adjustments as we go along. That won’t be an issue will it?
Me: *facepalm*

Normally this would be a line of conversation that shoots up red flags all over the place. App development requires a fine balance of time, quality, and scope. When you restrict the timeline and expect high quality without knowing the full scope, things can quickly get out of control. If this had been a client, I would have politely told them how stark raving mad they were and figured out a way to either extend the timeline or define and pare down the scope (knowing that most, including me, are not willing to sacrifice quality). But this wasn’t a client who asked me to do this; I had come up with an app idea with my designer, partner, and trusted advisor Jennifer, and we wanted to make this happen. So, challenge accepted! Okay, so how do we build a quality app that does what we want in 2 weeks?

mad-hatter-2

Luckily we had a clear vision for what the app should do. The app was to become CaseCollage, and it would allow a user to arrange their photos into a printable collage that fit between an iPhone 5c and the new iPhone 5c case, personalizing the phone and covering up the misaligned regulation text in one fell swoop. I cannot stress enough how important it was to have a clear idea of what we wanted before we started. From firming up the wireframes and design to deciding which features to include and which to cut, we always came back and asked if it helped us reach our original goal for the app.

We were working on an extremely tight deadline, so the less development I had to do the better. I started by finding open source libraries to help us form a foundation for the app (remember, “don’t reinvent the wheel”). Grabkit fulfilled our goal of having photos in the app while giving us the added benefit of social integration with Facebook, Flickr, Instagram, and Picasa. OBDragDrop was instrumental in coding our collage editor. We even used libraries to customize progress indicators and sharing options. With the foundation in place, I set out coding the app. I worked long hours, spending every waking moment strapped to my MacBook typing like a madman. Jennifer worked just as hard rounding out the design, preparing assets, and offering constructive criticisms (some of which I was not in the mood to hear). With a prototype in hand we sent out the app to beta testers and took notes over their shoulders as they tried to use the app for the first time, biting our tongues as they fumbled their way through our hastily designed UI. With feedback in hand we quickly tweaked the app, washed, rinsed, repeated. After several iterations, a solid 2 weeks of nonstop coding and designing, and an all-nighter, we submitted our app for review. I demoed the app at Nashville CocoaHeads the next evening, got a great response, and left with an amazing elated feeling in my bones. The seemingly impossible had been accomplished! Now all we could do was wait and hope that Apple approved of our creation.


Recent Posts
  • Copious Communication
  • Initial Questions for a New Mobile App Project
  • Gif TV: A LunarLincoln Product
  • Onboarding other peoples code
  • What’s in a name?
  • Don’t build it all. Picking a Platform.
  • Talk to your Users
  • Design for Fat Fingers
  • A new look
  • Hourglass for Jira
Archives
  • May 2021
  • September 2020
  • November 2019
  • October 2019
  • June 2019
  • April 2019
  • February 2019
  • January 2019
  • October 2018
  • August 2018
  • June 2018
  • April 2018
  • January 2018
  • October 2017
  • August 2017
  • June 2017
  • February 2017
  • January 2017
  • September 2016
  • July 2016
  • April 2016
  • March 2016
  • February 2016
  • October 2015
  • September 2015
  • July 2015
  • May 2015
  • February 2015
  • December 2014
  • November 2014
  • September 2014
  • May 2014
  • April 2014
  • January 2014
  • December 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • December 2010
Categories
  • Agency
  • App Advice
  • Branding
  • Business
  • Business
  • CaseCollage
  • Coding
  • Design
  • Design
  • NSVille
  • Uncategorized
  • Web Design
Copyright LunarLincoln 2023. All Rights Reserved