LunarLincoln, Author at LunarLincoln

Aug

Celebrating 10 Years

Half a score and 1 month ago our forefathers (well, Wiley-father and then later Jennifer-father) brought forth, upon this continent, a new company, conceived in liberty, and dedicated to the proposition that all work is not created equal. (Some apps are just better than others, ideally the ones we make.)

Guys…guys…did you know…you can just start your own business? Really. It seems like you should have to take a class, or go to business school, or maybe have wealthy parents. But no, 10 years ago we decided on a business name, bought a URL, and filled out some paperwork downtown and BAM – we were a business.

Next came the slightly harder part. Convincing others that we were a business as well. Give us money to do work for you. We promise it’ll be great. We DO know what we’re doing, but we do not have any examples of this work. Trust us.

We needed to be legit. 2 LEGIT 2 QUIT. Luckily, Wiley had engendered some good will at his former agency and made some good community connections at the local chapter of Cocoaheads. And with a new website and a lot of un-earned confidence (and some definite anxiety-driven what am I doing nervousness) – the sales started to trickle in.

Early clients of the newly formed LunarLincoln were the lovely folks at Emma Email Marketing (now Campaign Monitor/Mailchimp)and were a catalyst for future clients. So many wonderfully, brilliant people in the Nashville tech space got their start at Emma and then went on to start or lead or steer other local companies which allowed our work to also grow and spread. (It didn’t hurt that we got to work with all of these great people repeatedly over the years). To show our appreciation, we sent them a rocket piñata filled with hot chicken gift cards…and they smashed it in the parking lot on film. See…great people.

We added Jennifer full time, instead of week nights. We added our first employee Travis, who had to work in a 100 sq. ft. closet (I’m not joking, it was 100 sq.ft) with Wiley over at Center615, which he handled surprisingly well.

We got a new office ten time bigger (1000 sq ft baby!), we got more clients, we added more people (Todd, Jack, Patrick, Tyler, Armando, Cory, Ben, Nate, Joe). We had interns (Logan & Dheeraj). We had parties and hosted meetups and met tons of new people.

But LunarLincoln isn’t just the people we met along the way (who am I kidding, it totally is). It was also the work. So. much. work. Over the past decade we’re built dozens of apps for the following things:

*takes deep breath as I scroll the depths of our Confluence spaces to remember them all*

Apps to…

To meetup at music festivals
To share your medical records between doctors
To review how your email campaigns did
To share photos across groups at weddings
To track data about your life
To rideshare on golfcarts
To track visitors with bluetooth beacons
To run your choir music setup
To share sales PDFs
To practice shooting
To keep track of Magic the Gathering decks
To adjust music speaker backpacks
To get gas station rewards
To poll for elections
To research addictive habits
To organize music catalogs
To call HVAC field techs
To sell mobile homes
To track time
To get kids dancing and moving
To share contact info inside an organization
To measure Wagyu beef quality
To fill out medical paperwork
To share local coupons
To offer tickets to events
To learn about local restaurants and shopping
To run a radio station
To share gifs
To save for college
To help veterans in need
To track medical sales
To entertain toddlers
To record adventure sports
To adjust studio photography lights
To get therapy when you need it
To control smart locks
To control smart screens
To call real estate leads
To keep track of pesticide applications
To collect apartment trash
To share physician credentials

So many different industries and tasks and features. And we love it. It’s never boring, never repetitive, and we hope to continue to do it for a full “score” upon this continent. (or maybe other continents). LunarLincoln global domination.

In the meantime, we’d like to step away from our desks, take our hands off the keyboard and have a moment to celebrate a decade of apps with all of you. The clients, the team, the community organizers, the fellow devs, and also just our friends who have had to hear us moan and brag and speculate about various projects at LunarLincoln.

Please join us on Wednesday, August 23th after 4pm at East Nashville Beer Works. There will be free beer, free pizza, and free playgrounds for the children you have all acquired over the past decade as well.

May

Copious Communication

I take a lot of notes. You’ll never find me in a meeting or a call just sitting there nodding – nope. Also, you’ll never have a meeting with me without getting a giant email afterwards detailing pretty much everything we covered.

Why? Jennifer, why are you such a crazy chronicler? Do we really care about what we talked about at lunch? Why are you listing out what goes into the Settings screen – isn’t that obvious?

The reasons I do these things, and why I’m so militant about taking notes and asking others to refer to/read the notes is because communication is key to a successful product.

Notes are a great reference point for what we’re thinking, problems we’ve worked through, and decisions we’ve settled on. While some people might have amazing eidetic memories, most of us don’t and that’s where the notes come in. BAM! Here’s a note on what features we want in the Settings screen, or here is a note from a user interview we did last June where they asked for 3 new features, or here is a note where we decided to delay push notifications until V2 so let’s stop arguing about it for the 1 millionth time.

At LunarLincoln, we use a little tool called Confluence to keep track of notes, plans, etc. This isn’t necessarily the best tool or the most elegant tool (but it works with our ticketing system JIRA and user system so it’s fine). Some teams use Google Docs. Some teams use Notion, or Basecamp, or Asana. Sometimes I even use regular pen and paper *gasp*. (And then later I type it into Confluence so it’s searchable). These all work.

Notes may seem not important when you’re first starting out – I know everything, I’ve got it! But when it comes time to add new team members, or when you’ve put a side project down and then you want to resurrect it 6 months later – you’ll come to appreciate the time savings of having notes about where you were, what came next, and why in the world you decided that the menu needed to be at the bottom instead of the top.

So “notes” is kind of a vague term. I mean, I get the concept but what exactly DO we consider useful notes at LunarLincoln?

Things I find myself referencing, creating, or wishing I had later:

Feature Lists
Goals, Audience, Problems
Names, Marketing Phrases, Short descriptions of the Product
Meeting Notes / Decisions Made
Credentials, Key Roles, Terminology
User Stories / Development discussions
Business Plans / Monetization
Drawings / Doodles / Whiteboard Photos / Designs

Typically if you have detailed content for these areas – you are on your way to having STRONG plans for building a product. These are the kinds of notes that allow you AND your teammates/contractors/helpers/investors to have CLEAR VISION and to be on the same page. (It also majorly cuts down on the number of questions you get and having to repeat yourself over and over)

So yeah – NOTES. A super basic thing, that you should do and make a habit of. We love it and hope you’ll learn to love it too.

Sep

Initial Questions for a New Mobile App Project

It can be daunting to know the first place to start after you know you want to build a mobile app. We are here to help. We can help you focus in your project goals on what makes sense.

Ultimately only you will be able to provide the core vision for what you need. As you ask the questions below, think through the lens of what needs to be in front of users first.

Let’s Build a Minimum Viable Product

Source: Kunal Naik

Since building technology costs money, having priorities will save you money. So what are the priorities? As we explore this question, keep in mind that it’s always smart to build a minimum viable product (MVP) first. Rather than having a little of everything that works ok, focus on building one aspect of your vision well so that it’s a great foundation. That may mean focusing on one platform before doing both iOS and Android. It may mean we should focus on core functionality before adding extra features.

Have an idea of what’s a must-have versus things that aren’t crucial. This will help you know what you should invest in first. It’s always better to get a smaller, great product in front of users, rather than an app that has more, but doesn’t work great. Having an MVP also helps you get to market faster, which has huge advantages. If you keep launching major updates to your app every 6 months, you’ll be learning what works and what doesn’t. This saves you money since you know which ways you need to pivot your thinking. It often doesn’t make sense to work on a large app for years, without getting feedback from users along the way.

That’s the critical piece of advice I’d give any of my friends who are involved in getting an app built. Keep in mind you’re building a MVP, and not the kitchen sink when considering the questions below. Here are some common questions we get when people reach out for a quote. This should help prepare you for a conversation with us.

Let’s Play Common Questions Bingo

If we wanted to build a Bingo board with the common questions that come up during a conversation about building an app, we’d be winning lots of Bingo. If you don’t know how to answer the questions below, spend some time thinking it over and reach out if you’re stuck. We can point you in the right direction.

You want to know: “How much will it cost?”

We need to know the answer to some of the questions below before we’re able to answer this one for you. In general apps are expensive to build, and zeros are involved. Thankfully a round number can get more focused as we learn more.

So what will we ask to get to the answer for that question?

What’s the big idea?

What makes this app unique and different? What will compel people to use it? What is that one thing that absolutely needs to come across when someone uses this thing?

What kind of features are you envisioning?

What are the core thing someone can do with your app? It can be helpful to see if you can distill your app in 2-3 user stories. A user story is a high-level description of one of the things a user can do with your app. Here are few examples:

As a car driver I can swipe my app while paying for gas to earn rewards.
At the gas station, I can show my app to redeem rewards at the counter and get a free Coke.
As a beer enthusiast I can scan a beer’s barcode to see details about a beer.
As a movie buff, I can search for a movie and mark it as watched.

Does this need to be an app?

Hang with me. Sometimes people will have an app idea that may not lend itself to the app format. If you want to build an app for writers that helps them build up their typing speed, it may work better as a website or desktop app, where people are more likely to have a keyboard when using it. What’s the advantage to people having this product on the go?

Who is this app for?

What’s your target demographic? Who will be using this app? This can help decide how the user interface works.

How do you plan to make money with this app?

This may sound a big harsh, but what’s the business plan? If you haven’t considered the longterm plan for how the app makes you money or meets your goal, you may be missing a core feature that needs to be in the app.

What’s the play? Should users be able to subscribe monthly to the app? Are there in-app purchases? Are there ads or messages from you or partners? How does a user give you valuable information such as their email address so you can reach out and tell them about your next rally for saving the rainforest? Does your app help you reach your goals?

Do you have a specific timeline in mind?

Do you have time pressures tied to your app? For instance, are you building an app that helps you create custom emojis that you’d like to release on the same week that the next Emoji Movie releases? Or do you have investors or stakeholders with expectations on when the app will be rolled out?

Based on the timeline, we may recommend what would be doable within your desired time window.

What other apps are your competition?

This question helps in a couple ways. Are you building an app that already exists? If so, what is your competitive advantage? If you’re building something different or better than someone else, how will that inform the features you’re wanting?

If you do have competition, what do they do that you also want to do? One advantage to not being the first on the scene, is that you don’t have to re-invent the wheel. You can likely glean from others what is already working in your space.

How fleshed out is the design?

Do you need a designer? Or is everything already mocked up? If you need some help with the ideation phase, we can help figure out a plan. Knowing how far along you are in this step will inform how long the process may take.

What devices will be able to run your app?

On what devices will your app be able to run? Can it only run on iPhones? Or just on Android phones? Both? What about tablets? Should the app look different for users using larger screen sizes? The answers to these questions greatly impact what needs to be built.

What other technology will accompany the app?

Do you also need a website?
Does an API need be built so that the app can access the data it needs?
Do you need an interface that allows you to edit or see user details?
Do you need analytics about the app so you can see reports of how people are using it?

Bingo!

If you have the answer to 5 of these you’re off to a great start. Keep going. If you don’t have all the answers, that’s totally fine. We can help you think through all of the questions above. These are just some introductory questions we often cover so we can start to figure out the size of your project.

Reach out when you’re ready to figure out your app’s next steps!

Sep

Gif TV: A LunarLincoln Product

If you’ve ever perused our blog or Twitter you might have noticed that we like GIFs. We think they’re a great medium for injecting humor or emotion into what could otherwise be a dry industry-specific topic. If you’ve ever been in our company Slack or on a text thread – you’ll notice we sling just as many GIFs there too. We just can’t get enough of those little moving-nuggets of fun.

What feels like 1 million years ago but was actually 2014, I found an article on Lifehacker (remember Lifehacker?) about building a little screen that showed GIFs. I was fascinated, immediately ordered the parts and put one together (although not without copious cursing due to the inaccurate instructions). This lil’GIF machine resided on the wall in our office for a few years but was more frequently out of commission than active. It was the definition of a buggy hack.

I loved it. I loved the serendipity of a random GIF being served up as well as the mindless entertainment of seeing what comes next. If you’re a fan of the TikTok For You page, you know exactly what I mean.

So, when we first started clearing time in our schedule to work on passion-projects at LunarLincoln, we each made lists of potential ideas we’d like to work on. Wiley made a huge list of tools that could help him at work/life (to do apps, API validators, proximity photo services). Me? I made a huge list of fun, useless things (80s photo filters, mean mail and….the Gif TV).

I wanted to see our office Gif TV as a real product, for real (non-technical) people. It could show your favorite GIFs, GIFs from friends, GIFs for topics, reaction GIFs, etc. Whatever hit of 5 second dopamine-laced entertainment you needed.

Wiley begrudgingly agreed (since I promised to do most of the work). And so we dug into building Gif TV.

Below is a very quick summary of the journey but we’ll be breaking these into longer posts in the coming days. Keep checking back for more product and GIF content!

Initial Plans & the Reboot

Initially our plan was to package up the original raspberry pi/screen concept with a companion app to select and serve the GIFs since the initial version you had to upload GIF files by hand to a random database. But, as I started to source components, and look at 3-D printing cases, and see how long it took to assemble them by hand – it was seeming a more and more complicated (and not profitable) venture. Hardware is hard y’all.

But what if the app WAS the tv?

This would be a simple solution. We build apps. Why muddy it up with hardware?

BUT, I did still want some sort of physical component for two reasons.

People are so fickle about paying for apps – a physical product still holds more “value” for consumers. We could recoup costs better upfront than trying to build out all the infrastructure for some sort of subscription service.
I wanted a physical engagement with the gifs. We already have a million ways of digitally access gifs, but what about a “present” version. I pictured the app languishing with the 1200 other random things you downloaded into your phone. That physical stand will be sitting there, asking – don’t you want to stream some gifs today?

So the GIF TV was reborn – an App + a Stand.

Coming soon – Learn more about the app planning process and the stand production process.

Gif TV as a way to learn new tools/technologies

The Gif TV project wasn’t just a way to share our office Gif TV with friends though. We wanted some low-risk projects to test new tools on.

Personally, I wanted to take Figma for a test run without using a client as a guinea pig (and on something more complex than twiddling with the pre-built templates).

Wiley had wanted to check out Flutter. After years of nay-saying cross platform solutions, a few close friends had managed to convince him that Flutter was worth a gander. Cross-platform still is only best used for content-driven apps versus sensor driven apps and Gif TV fit this niche perfectly.

Gif TV seemed like the great solution for both goals. Fun product + acquiring new skills. Double win.

Coming soon – Learn more about why we’re fully on the Figma train now and about Flutter and when it’s best to use.

Gif TV as a foray into new activities (crowdfunding, marketing, startup sites)

We weren’t just learning new skills for our careers though, we did a little stretching into adjacent areas too.

I learned more than I ever wanted to know about laser cutting and CNC machines. I built stand prototypes with my Cricut, had early versions cut with Ponoko, and now I have a cardboard box with more random Gif TV stand pieces than you’d even need.

We tried out new kind of promotional websites – falling in love with Carrd for it’s simplicity and inexpensive entry point for landing pages and Big Cartel for our shop.

We stretched our marketing skills again for the first time since CaseCollage. We gained a newfound respect for how lucky we’d been with that first launch and just how many new things there were to learn in this go-round. Product Hunt, social campaigns, cold emails – they were all areas where we felt we were just dipping out toes and learning there was a lot more to learn.

Coming soon – Learn more about our experience with Product Marketing.

Gif TV as an enjoyable product for friends

At the end of the day, we haven’t seen as much traction as we’d hope for our little Gif TV. But that doesn’t mean it can’t still happen or that I’m not still enjoying my personal Gif TV streaming on my desk right now. We’ve learned a ton about Figma, Flutter, Kickstarter, Product Hunt, lasercutting, ecommerce and social media. I think we’re better positioned for future product launches and we have a great little product here as a case study.

We’ll likely push Gif TV some more during the holiday season and I’ll work on some alternative marketing for it in the meantime.

Want to check out Gif TV for yourself?

Visit the site where you can download the apps, purchase a stand, or learn more about all the ways you can enjoy your own Gif TV.

Nov

Onboarding other peoples code

Greenfield vs Brownfield

There’s nothing better than cracking open your laptop, selecting “New -> Project”, and starting to build an app. At this point your codebase is flawless, your app builds and runs in seconds, and there’s no tech debt. Every thing is in the right place, and you feel like you can conquer the world.

But there will come a time when you have to work with other people’s code. You inherit an existing codebase when starting a new job. Or you get a new client who has a working app that needs features added or production bugs squashed. Or you get the opportunity to rescue a project that’s over budget and timeline and needs to be shipped ASAP. Whatever the case might be, there’s an existing codebase that has perceived value and its up to you to add to it. So where do you even start?

Documentation

At LunarLincoln, we like to start by carving out some time to review the project. If there’s existing documentation, start there. Now that you’re working on the project, documentation is your responsibility. Make sure to update existing documentation if you find errors. If there’s no documentation, document things as you go. Then use the app like a real user would. Start making a list of questions as you go and work with stakeholders or previous developers to get answers to those questions. Having a good spec is the first step in contributing to an existing codebase.

Code Review + Red Flags

After you know what the app’s supposed to accomplish, dive into the code. Start by building the app from the latest commit that was deployed. Be on the lookout for red flags (and yes, document these as you go).

Red flags come in many forms, and you’ll get better at spotting them the longer you work with apps. Here are a few we typically look for when onboarding a codebase:

An egregious number of build warnings
A disorganized project structure
A few classes with a lot of code in them or a lot of classes with almost no code in them
Poor or inconsistent naming
Breaking the defined architecture of the app (i.e. if MVC seems to be the convention, having the view accessing the model layer directly)
Code that solves widely solved problems
Dependencies that have little to no community around them

Fix Something Small

From there, take a quick, deeper dive into the project to get a feel for working in it. A great place to start is trying to fix an existing bug. This’ll give you an idea of what working in the codebase is actually like. It’s impossible to fully understand a codebase that took months to build in a review lasting hours, but at least you’ll have an idea of how to set expectations moving forward.

Document + Present Your Findings

Once you’ve had a chance to review the project, make a list of things that need to happen to move the needle on the project (you were doing this as you went…right?). Then categorize that list by urgency. You’ll probably want to fix everything before getting started with new features or bug fixes, but some things will absolutely be more urgent that others. The important part is that you communicate what you find to your stakeholders, agree on a plan to fix things, and start producing value. For existing apps, try to remember that the app people are using in the wild was made from the code you already have.

Become the New Code Master

Switching developers on a project is an expensive undertaking. Save yourself a headache later by reviewing the documentation, app, and code up front. Then leverage the findings in your review to lay out expectations and a roadmap for continuing development on the app.

Oct

What’s in a name?

You have the idea. You’ve asked others about the idea. You have plans to build the idea. But…in order to start writing code, buying URLs, designing branding, doing your social media thang….you need a name.

Easy. I’ll just come up with a name. No. Big. Deal.

A few hours later, you have a name, you love it. You think it’s pretty clever. You’ve decided to name your idea baby: Xymr (You know, like simmer but with zest”). The product is a recipe app for dogs (obviously).

But when you email about Xymr to others their eyes twitch, they ask…so what does “Ex-eye-m-ar” do? Or you recommend Xymr to a friend at the dogpark and they google “Zimmer” and find nothing. Or they do get it right, and oh hey, it looks like the first entry for Xymr goes to…a…porn site. Wait, you never googled your own company name? Oh man.

See where I’m going here? A good name for your product or company isn’t necessarily trendy or cool but one that works. Everytime. It needs to work visually, aurally, and on the internet. Unique but not tooooo unique.

Easy right?

There are some basic rules to try to follow when coming up with a product name and while you don’t have to follow all of them, it’s important to weight the importance to your audience of each.

Spelling. You can be creative but not too creative (leave the vowels please!). People will hear about your product and search for it. Make sure what they search will bring them to your product.
Being unique. Also known as Google juice. If someone googles your product, are you going to be front and center? Or 9 pages back. Don’t name your company “Googl”. Don’t name your cooking product “Kitchen” or “Recipe”. It’s a losing battle with the SEO giants. Your user isn’t going to hunt for you, and if they can’t get to your product with one or two obvious search terms your name needs to be better.
Competitors. Don’t be too similar to competitors. If you name your company Zimmer and your competitor is named Simmer, you might be losing half your interested audience through a mistaken search. Don’t make users hunt for you.

Now as an aside, you might ask – what about Spotify, what about rrreally unique names? Brand new words? You CAN do this, but again it needs to be easy to hear, easy to spell, easy to search, and easy to remember.

Okay, so I have what I shouldn’t do. Now, how do I go about finding a GOOD name? What if I can only come up with derivative garbage? Work Corp. Synergy Labs, Best Business.

First I like to start by setting the mood for brainstorming ideas. Relax. Be prepared to be silly. Have a beer or light some candles. Get hopped up on sugary donuts. Ready?

First, write down adjectives you’d like people to think about when they think of your product.
Then, write down words related to what your product does.
Do you have a giant list of words now?

Here’s an example. For our dog recipe app, I’ll write down some adjectives: Dog, Pet, Puppy, Pup, Food, Nourish, Meal, Healthy, Delicious, Fun, Homemade, Authentic, Cook, Prepare, Create, Craft, Kitchen, Stir

Now, let’s make that list bigger and more interesting. See if there are any words that are similar but we didn’t think of.
Go to thesaurus.com and turn those 20 words into 100 similar words.
Go to Google translate and turn those words into other languages. (latin, greek, sanskrit, portugese, anything sound cool here?)
Stretch your brainstorming even further. I personally love this site: https://onym.co/
Now you have a biiiiiiiig list of words.

You can remove ones you don’t super like or aren’t working for you. Be brutal, slash it down to just the words that make you excited for your business.

Here are some additional words we found: Pooch, Fido, Chow, Fare, Grub, Snack, Fresh, Fit, Hearty, Make, Plan, Mix, Victus, Canis, Hundo.

Next step. Go to Bustaname.com and put in your list to start making combos. Tinker with the word combos (first vs last), suffixes, prefixes.(Sidenote: I know this site is ugly, but it is powerful. There will be a lot of garbage in there, but also some gems. Sort for your gold!)
You can also think about prefixes and suffixes -ly, -fy -ist. Or group combos +studio +labs + craft +bits +team.

For this exercise – Bustaname suggested pupmeal but I like the idea of MealPup – a short, quick, fun meal for your puppy, puppers, pupperino.

Now even though Bustaname has done a rudimentary url search, go ahead and google search them, social media search them, and url search them. Few competitors? Available handles? Friends can successfully type it in or pronounce it? You have a name! Time to start plastering that baby everywhere.

Jun

Don’t build it all. Picking a Platform.

Often a client’s first knee jerk reaction is to want to build their product on as many platforms as possible. “Our customers and our admins need to be able to access their account online and on a mobile app and maybe on a desktop program.”

And then when we suggest maybe only doing only one of those…they get…kinda hostile.

They think that we don’t believe in this big idea. Or we don’t want to help all their users. But, this isn’t it at all! By telling you no, what we really mean is that we want you to be successful! And successful when you’re a fledgling startup means starting small and focused.

We totally get it. You don’t want to miss out on an opportunity to connect with a potential user and their potential money just because they can’t access your product easily, but trying to build out multiple code bases without any initial customers or validation is a very. costly. mistake.

The first thing you should code up when starting a new product is an MVP…or a MINIMUM. viable product. Does building your first product for multiple users to access online, on phones, on tablets and on desktops sound very minimal? Nope.

So what should you do? Which should you pick? How do you even do that?

Don’t worry! We can take a quick look at a couple of different aspects to decide which platform is best to start with.

First let’s look at what kinds of tasks your product will contain.

Will your users need to type in a lot of text?
- This will mean your product needs to run on something that has a real keyboard. (Web or Computer Program)
Will your users need access to a camera or video? What kind of photos or video are your users needing?
- Is it candids like Snapchat (App)
- Or is it more meetings like Zoom (Web)
Do we need the user’s location? How accurate does this need to be?
- If we’re offering some sort of running, fitness, or habits product we’ll need an app that can offer that hyper detailed data.
- If we just need to know nearby items (think Yelp) then maybe typing in our zipcode on a website works.
Does this product need a really high level of visual polish or performance?
- Depending on its speed and visual needs, maybe don’t consider a hybrid app or web app for starting off.

Then look at where these kinds of tasks will be done.

Are they needing to do these tasks while out and about? (Phone or Tablet App)
How about offline/no service areas (Native Apps)
Is this daytime, office work? (Web Browser or Computer Program)
Is this an evening, couch activity? (Phone App / Responsive Web)

Who will be using this product?

Kids? – Most kids use inexpensive tablets
Office staff? Maybe custom software or web service or inexpensive android tablets
Gen Z? New Moms? Senior Men? – Each demographic migrates to a certain kind of device depending on finances, habits, and age.

Now of course, people have varying habits and not every single user you talk to will say that they want to access your product in the same place. (In fact most users will say that they want more choice – even if their actual habits show them using the same devices over and over.)

So what you’re doing with this exercise is deciding which platform has the most logical overlap for all of these questions/answers for your target user.

Sidenote: Pretty much ALL of our advice at LunarLincoln involves touching base with your users and their needs. Make sure you genuinely understand your “core” user and remain focused on them. If you’re not sure how to do that just yet, check out our article on “Knowing your Users”.

Okay. I know more about where my users are and what this product might need, now what?

Now, pick ONE PLATFORM for your MVP.

Only one? Really? But…but…I can’t! I need them all. This way I don’t miss out and ALL of my customers are always happy. Please can’t we just build for web and mobile and desktop and tablet?

Nope. For your MVP, building for one platform will help you in a myriad of ways.

It helps save development time and money
It reduces churn when you need to change or tweak features
It even allows you to focus your marketing for that initial launch only in places and with groups that will use the platform you’re on.

These sound like good things right? Not doing ALL the things IS a good thing. I promise.

Also, just because you launch with one platform doesn’t mean you’re barred from expanding for all time. If you have amazing demand, then this means you’ll also have more money and information from users to know where to go next (build that Android app! Add that desktop version!)

If you over build and were *gasp* maybe a teeny bit wrong about your users, then you have a big ol’ technical piece that is getting dusty, is underused, and is likely still costing your financial resources to maintain.

If you feel pretty confident about knowing what your user’s want and where they are but still need help determining the technical solutions, we’re happy to help.

Send us an email (from an app OR a website! 😉 )

Apr

Talk to your Users

There are many, many steps when it comes to building a product and many can be unique to the situation, but there is always one task that is the same for all of these. No matter what. No matter when.

And that is sharing your idea, prototype, or product with others – also known as user testing or user research.

But…here is what I often hear from clients when I talk about this step:

But Abe…I don’t want anyone to steal my idea when I talk about it to them.
But Abe…I don’t need to test with users – I know exactly what they want.
But Abe…I don’t have time to test with users, we have to be first to market. I need to start building now.
But Abe…I don’t have the budget for fancy user testing.
But Abe…I don’t know where to find people to be my testers.

This. is. bullshit. When you tell me the above, what you’re really are saying is: “I don’t want anyone to challenge my perfect idea-baby.” and/or “I don’t want to put in the time to do this – I just want to do the fun part – which is locking myself in a room and coding up a monument to my own genius”

Showing or talking about your app is scary. You’re making yourself vulnerable. You’re allowing others to poke holes in your idea, your design, your code. But guess what? It makes not only you, but also your product stronger and ultimately more succcessful. I’ve never ever had a client say “I wish we hadn’t spent time on that” or “The user feedback was useless”.

So first, we’re going to debunk these common excuses. Then we’re going to cover how to user test – now that you have no excuses.

But Abe…I don’t want anyone to steal my idea when I talk about it to them.

Having an idea isn’t special. I have dozens of app ideas each week (pretty much all of them are dumb). It’s the building of the idea and making sure that it’s problem is a common/compelling one. How do you know if others have this same problem? By asking them. How do you know if this idea is dumb? By asking people.

But Abe…I don’t need to test with users – I know exactly what they want.

Really? You and every one of your users is exactly the same? And there are enough of you to make a profit? Just humor me and talk to a few other people who would be interested. Learn a bit more. You might be surprised about how similar, yet different your audience can be.

But Abe…I don’t have time to test with users, we have to be first to market.

It doesn’t matter if you’re first if your product sucks. Many of the most popular products out there weren’t first, but they did take the time to get it right. Building then changing, then building, then changing after you’ve launched is going to be painful and expensive. User testing doesn’t have to take weeks, it can take as little as 3-5 coffee sessions and it will save you hours in churn. (It might even save you from building a failed product to begin with).

But Abe…I don’t have the budget for fancy user testing.

You don’t need expensive or fancy tools. Whip out some Google Surveys, take some old fashioned notes and hit the pavement. User testing is genuine sweat equity – no expensive developer required. Honestly, I encourage most of our clients to do the user testing themselves, with us as an advisor. If you’re not elbow-deep in feedback, how will you truly understand your own audience? This is not something you should outsource and doing it yourself = cheap.

But Abe…I don’t know where to find people to be my testers.

Um…if you don’t know of anyone who would be interested in this product, how are you going to find customers once it’s built? ? ? ?

But okay, maybe the problem goes more like this: “I know my user’s are construction workers – but how do I reach those people directly?”

The internet is a wonderful and magical place my friend. Check out industry forums for your kind of user. Check out Facebook groups, Twitter hashtags, LinkedIn groups, local meetups, post a question on Quora, etc. You can even go next-level vulnerable and go to a REAL LIVE place with these kinds of people and talk to them there – home depot, the park, a bar!

The worst thing that could happen is that you ask your question and you get crickets or someone saying no thanks. The best is that you have awesome, long, meaningful conversations with your potential users and come away with a bit more insight.

So I’m convinced. Now how do I do this thing?

There is no “perfect” path for user testing and there are a few different ways to arrive at the same result. Don’t feel overwhelmed. Even doing one of these types of testing will set you far ahead of your competitors.

Early Days – Idea Validation through User Discussion

What: Validate that your idea/problem area is even good/common. This is when you’ll decide if this idea has legs. Are people willing to pay for this product? Are there enough people to make that payment worthwhile? We prefer at this stage to start firming up the idea with a Lean Canvas exercise.

How: Talk in person to 10 – 20 potential users. This is a casual conversation, where you’re mostly listening and saying “tell me more…”

Ask them general questions like the ones below. The questions below came from this excellent resource.

What’s your relationship like with [topic … e.g. money, fitness, etc]
How do you currently go about [problem / task]?
How much time do you typically spend on [problem / task]?
Tell me about the last time you tried to [problem / task]?
What do you like about how you currently [problem / task]?
What is the biggest pain point related to [problem / task]?
Why do you keep doing [problem / task] … why is it important to you?
What type of work arounds have you cerated to help you with this?
What’s the hardest part about [problem / task]?
What are you currently doing to make this [problem / task] easier?
How does this [problem / task] impact other areas of your life / work?
What other products or tools have you tried out?
Have you paid for any of these other products or tools?
How did you hear about these other products or tools?
What do you like or dislike about these other products or tools?
Are you looking for a solution or alternative for [problem / task]?

Who: Find interview subjects through Facebook Groups, Meetups, Social Media (Instagram/Twitter), Family/Friends. Ask every single interviewee “Is there another person you think I could talk with who also potentially has this problem / could use a tool like this” Grow your pool. You’ll use this pool continually as you develop your product.

The Specifics – As Needed Polls

What: When you find yourself saying “I don’t know” or “I’m not sure” it’s time to ask your users a few targeted questions. Further refine fuzzy areas with this “one-weird-trick+.

How: Send short surveys to 50 – 300 people. Distill some recurring questions from in person interviews into 3-6 short questions. Set this up using Typeform or Google Surveys. Incentivize with gift cards / stickers / high fives.

Who: Email the link to your survey out to your interview list. Post the link on channels from above (social, family, network). Potentially look at services that offer curated audiences like Survey Monkey or Usertesting.com.

Prototype Time – Talking about the actual product

What: You’re ready to have users actually use your product – not just talk about it abstractly. While you’ve nailed down the big picture with previous user research – this is the “testing” part of the game. This can be done using a drawing of your product, or a design, or a rough coded prototype. User testing at this stage is making sure you have included the right features, organized in the right way.

How: Sit down with 5-10 people and watch then use a version of your product. This doesn’t need to be coded. In fact I strongly encourage you to slap together some design prototypes first before you’re attached to your beautiful, perfect, thorough code. Create design prototypes with a program of your choice: Balsamiq, Invision, Figma, Powerpoint/Keynote.

Allow for a user to generally explore your product, discuss their thoughts. Then ask a user to complete some common tasks for your product.

Big note: DO NOT SHOW THEM HOW TO USE IT. Use all of your willpower to remain impartial. Allow them to potentially flounder, get confused, or frustrated while clicking through. This is the point of user testing. It will be okay. Watching someone struggle in the prototype phase allows you to make changes to prevent all of your real customers from feeling this same pain. You will not be there in real life situations to jump in and hold their hand, so don’t do that here either.

Record these sessions with a tool: Zoom, Lookback, or Maze. This allows you to revisit areas later and see exactly what the user did while talking. Take notes of “moments of interest” to review and improve upon later.

Who: These should be your target users – your ideal customers. Focus on getting the UI/UX of the product right with the demographic that most closely resembles who this is for. One note about these users. Since they are looking at an actual object they will be tempted to suggest improvements, new features, etc. Use them to discover faults in the interface, but be wary of solutions they recommend – remain focused on what features set best fits your MVP size.

That’s It! You can do it! Please do it!

At the end of the day, it takes time to test your product with users. It takes confidence to approach others and ask for their time too. It takes bravery to put something that isn’t quite formed in from of others and ask for their opinions and it takes patience to sift through the feedback and discern what nuggets could make your product and ideas stronger.

The results, however, are so, so, so worth it. You’d be surprised how supportive and helpful others can be when it comes to building something new and it might even set you on a path to a product that could be more successful than your wildest dreams.

If you ever need a potential user, a pep talk, or some guidance, feel free to reach out to LunarLincoln. We’re happy to help you build the next big thing (or next tiny thing).

Email us. (We’ll get right back to you. Promise.)

Feb

Design for Fat Fingers

Have you ever had this happen when using your phone?

You typed in a ton of things on a page and then go to tap the submit button and your finger accidentally hits another button or link nearby? Or you weren’t able to type in the fields to begin with because you couldn’t get the cursor to move to them?

Screens these days are getting large and we can technically show a ton of things on there…but the thing is…our fingers are the same size they’ve always been (and not all of us have tiny hands like Donny T.).

A rookie issue when getting started with mobile design is making your touch areas too small or crowding too many things in one spot. (You can infinitely scroll, which means you have infinite space so chiilllllll and space that stuff out PLZ!)

Making things hard to tap makes users frustrated, and when they’re frustrated, they don’t return. BYE YOU GIANT HAND PEOPLE! I DIDN’T WANT YOU SHOPPING ON MY APP ANYWAYS. (That’s probably not what you were going for, but that’s what they think.)

So what SHOULD you be doing when designing buttons for mobile apps?

Luckily for you, you don’t have to go around measuring the finger tips of all of your potential users. Apple and Android have determined the optimal tap targets for you.

Apple’s Human Interface Guidelines recommend a minimum 44 x 44 px area while Android recommends 48 x 48 dp* when designing buttons for mobile apps.
(Let’s not go into the px vs dp discussion today but here is some reading)

Now that’s a good starting point but those are MINIMUM requirements. Actually the average human finger pad is 10–14mm and the average fingertip is 8–10mm, which mean you should be shooting for more like a 57px touch target. This is also backed up by tons of research. Check out Fitt’s Law if you want a deep dive.

That’s pretty big. Is my screen just going to be giant buttons?

Don’t worry! While it is good to have a decent button size not only for tapping but also for legibility/accessibility, you don’t always have to give that much visual weight. You just need that much spacing around your tap area so that there is no overlap with another actionable item.

Image courtesy of Material Design Documentation

When starting your mobile design make sure to set up sufficient padding around all of your buttons using the specs above for the tap areas.

Happy tapping!

Jan

A new look

Oh hi! You miiiight have noticed that things are looking a bit different at the online mooncabin. We decided that we were long overdue for a facelift, since we’ve been rocking the same look since 2014. The outside was workable but the inside was a bit of a time warp. Plus in the past few years we’ve been itching to add some new content but couldn’t figure out how to cleanly implement it with the old template.

The old template

Our old website was a wordpress template implemented before the invention of “page builders”. The inside was a scary land of stacked shortcodes. We didn’t like touching it because each time it required diving back into learning the mystery pseudo-code that stitched everything together. The template ceased being supported a few years ago but at that time we were mid-mobile-dev-mania and didn’t have time to look into alternatives.

What next?

So here we are: 2019. Web development has totally evolved, search engines are now super fancy/picky, responsiveness is key. Even WordPress, itself, decided to undergo a bit of a renovation this year. We’ve built a few other websites in the meantime and it’s helped me have a better idea of what we want and don’t want. We still recognize that we are better mobile devs than web devs, so we weren’t looking to build anything too custom. I’ve test driven several different page builders in the past: Avada’s Fusion Builder, WP Bakery’s Visual Composer, and this newcomer Tatsu run by Brand Exponents. I really dig the interface for Tatsu – it marries flexibility with simplicity and since it’s relatively new, it isn’t saddled with a ton of baggage/backwards compatibility like the industry leaders so we went ahead and dug in. Several iterations later – I think we have our final result.

What’s new?

EVERYTHING! Just kidding. Some stuff is really familiar, because its true and it works, but we did want to revisit how we talk about our work. We added a huge section on our Process. Building mobile apps is still a new concept to many people and “how does all this work” is the #1 question we get from leads. Dumping an entire load of process on someone in an initial meeting can be somewhat overwhelming, so it’s nice to have a place that potential clients can check out at their own leisure. We have a new area that focuses on our internal projects, which will grow in the new year as we add new ideas and ship more.

In the meantime, keep checking in. We’ll keep adding and polishing in the upcoming months, but I wanted to go ahead and kick off 2019 with some fresh code. Hope you like what we’ve built thus far.

As a side note: There’s really only one ongoing debate to settle – ARE THERE ENOUGH SPACE PUNS ON THE SITE? (Wiley always thinks there should be more.)