Get Weekly Updates

Keep your skills sharp, inspiration high, and motivation strong. Pop in your email below to get the latest from Clever Beagle in your inbox every Friday.


February 12th, 2018

  • added #119

    Add examples of indexing MongoDB collections and module for simplifying process of defining indexes.

  • improved #117

    Simplify form handling. h/t @merlinpatt for this one.

  • improved #114

    Migrate profile updates to Accounts API. h/t @ninjaPixel for this one.

  • improved #113

    Simplify static pages implementation. h/t @sw-yx for this one.

  • added #111

    Basic data export functionality.

  • added #110

    Ability for users to delete their accounts (and data).

  • added #109

    Add redirect back to initial request after login.

  • fixed #106

    Fix missing medium link on <Index /> component.

  • added #105

    Add staging and production commands to package.json.

  • fixed #104

    Fix onCreateUser not applying default roles to new users.

  • fixed #49

    Add better handling for schema errors inside of Methods. h/t to @Bandit for the solution.

Ryan Glover
Software is Like a Car

Software is Like a Car

A helpful analogy: software is like a car.

Cars have a lifespan. When a car company rolls a new model off the line, they don't shout "Hooray! We're done! This car will always look and work just like it does today." No. They say "keep building more of these because that one will eventually need a replacement." Depending on the make, model, and maintenance most cars last somewhere between 10-20 years. During that time, things change. The roads the car drives on may be brand new and smooth or an obstacle course of potholes. Its driver may use it a lot and the engine might eventually fail. Even worse: the car could get into an accident and be totaled—permanently disabled from the road.

Software is just like this. Though we're not dealing with anything mechanical or physical, under the hood of every piece of software is a complex system of parts. Regardless of how each part is designed, too, every single one can fail for a number of reasons and need to be replaced. Just like a car, software needs to be maintained. It needs to be cleaned and polished on the exterior as well as receiving the occasional tune-up under the hood.

Why are we talking about cars and software again? Because unfortunately, when it comes to setting expectations this comes up quite often—especially with beginners. Usually through inference, it's easy to see when someone new to the software business comes in with optimistic eyes. "Okay, we're going to build this in X months and it's going to work indefinitely." Not quite. While it's not the most fun to learn, it's important to understand that software can and will break for an infinite number of reasons. Sometimes due to an earlier mistake, other times due to a third-party component not being compatible with your stack's latest version. There's a reason why the development teams backing your favorite software can number into the hundreds: it takes a lot of work to keep any piece of software running.

As you set out to build your own software product, keep this in mind. If your idea is a success, your first version will not be your last. The stack you start with may not be the stack you finish with. It's important to consider that every single piece of what you build has the potential to require changes later. You may have spent time, money, and energy crafting the perfect solution, but eventually—just like a well-designed car—it will become a museum piece. If your goal is to build a real software business in the long-term, it is absolutely imperative to get your mindset right up front.

Understand that if you want your software to succeed, you need to take care of it. This means polishing up half-working features, ripping out and replacing bad ideas, or cleaning up some messy code that works but not terribly well. When you adopt this mindset, it makes it far easier to come to terms with the level of investment required and keeps you focused less on where you've been and more on where you're headed.

Ryan Glover
How to Build a Great Product by Using Design to Talk to Your Customers

How to Build a Great Product by Using Design to Talk to Your Customers

When I work with mentees, it's not uncommon to hear the phrase "we'll save the design for last" when we're planning out our work. The reasons this comes up vary, but more often than not it's a result of equating design with aesthetics. In other words, the term "design" is defined as "how it looks" instead of "how it works."

The thing is, "design," when viewed through the lens of aesthetics or "how it looks" is easily commodified. When we treat it like something we can just buy off-the-shelf and ready to go—a common metaphor is adding a coat of paint—we end up ignoring the details that tend to keep customers and users around. To wit, they're easy to ignore; most of the time, if something is well-designed, the "design" is invisible to us.

In order to get to that point, though, we have to be thinking about design as we're developing—from day one. We need to ask "how is this going to work for a user?" for everything we implement. A good way to prime yourself for this sort of thinking is to take note of how other software feels. Everything from your favorite apps that are incredibly polished down to the have-to-use-but-don't-want-to stuff like your bank's "virtual wallet."

Pay close attention. Look at little details like how certain functionality is explained or how the layout of the page and its functionality compliment a given task. Watch for things like feedback. When you perform a task, does the software let you know and make it abundantly clear that the task was completed as expected? These little details, you'll find, add up into a conversation. In your head, you're asking questions and—if properly designed—the software responds to those questions.

Why Amazon is a paragon of design

A great example of software that understands the conversation it's having with its customers is Amazon. Looking at a product page on the site, at first glance if we use the aesthetics definition of design, Amazon is quite ugly. If we use the "how it works" or utilitarian lens, however, Amazon's quality of design quotient skyrockets.

Highlighting some of the key conversations taking place in Amazon's product page design.
Highlighting some of the key conversations taking place in Amazon's product page design.

Let's consider the conversation taking place here. While we do, let's consider the objective: getting a customer to buy the product they're looking at. In the image above, we've picked out six different conversations taking place on a product page, each designed to nudge the customer toward that objective.

Conversation #1: "What does it look like?"

One of the most obvious questions that someone might have when looking to purchase an item is "what does it look like?" Here, notice that Amazon prioritizes this information by making it the very first thing that a user's eye will connect with when scanning the page (following the human tendency to read from top-to-bottom, left-to-right). In addition to displaying a large primary image, we can see additional images off to the left that answer the question "what's in the box?" As a bonus, a video is included further detailing the product and its benefits.

Conversation #2: "What am I buying, how much does it cost, and what do other people think?"

Next, an emphasis is placed on the what of the transaction. Once a customer has been visually primed, the next question to answer is "what am I looking at?" To the right of the image, several questions are answered at once: "what's it called," "how much will it cost me," and "is this recommended by others?" Pay attention to the hierarchy of the text here. The large title makes it abundantly clear what's being purchased, while marking the price in red makes it stand out amongst all of the other information.

We can also see a badge element being added to let us know that Amazon prefers this turntable (notice how they contextualize that choice based on our search query). Other important questions are answered here, too, like "is it available and how quickly can I get it" and "can I get it in different colors?" The "design" that's taking place here is very subtle, if non-existent. Consider, though, if this area were simply all-black text set to the same font size. It wouldn't be nearly as informative or compelling.

Conversation #3: "I want can I buy it?"

The most obvious of the elements on a product page: the "Add to Cart" button. Notice that even though the goal is to get the product into the customer's cart, additional questions are being answered in proximity to the main question. "If I buy this, can I get a warranty on it?" Further, we notice for the thrifty customer, although the "Buy new" option is selected, the radio button subtly suggests that the user can "switch" their option. Conveniently, at the bottom of the block, we see another option to buy the product used at a discounted price.

Notice that the design here isn't heavily focused on how it looks, but how it works. Everything here is focused on improving the overall experience for the customer. That's an incredibly important idea to grasp: you're not designing for yourself (or your team), you're designing for the people who are going to use your product.

Conversation #4: "I'm not ready to buy, but I don't want to forget this."

A quick but simple option, if the customer isn't ready to buy but is interested in the item, they can add it to one of their wish lists for later. There's some depth here, too. Consider that by providing this option, Amazon now knows which products the customer likes and can use that information to sell them to the customer later. This is by design. Remember, the objective is to get a customer to buy the product they're looking at. By including this, Amazon adds "eventually" to the conversation.

Conversation #5: "Can I save any money getting it from another seller?"

Although the answer here is "no," by providing a list of other sellers on the product page itself, customers can quickly shop around and make an informed decision about their purchase. Notice, too, that aside from just suggesting what other sellers are offering, an option to add one of the alternatives to the customer's cart is provided, too. Even more detail is provided if we look at the bottom of the list: they've even considered the "what if I have one of these I'd like to sell?" question!

Conversation #6: Thinking about the customer's thought process

This one is obvious when we see it, but not so obvious during the development process. Here, Amazon has considered what the customer is doing overall and making some smart assumptions about their motives. They're saying "hmm, it looks like you're buying a turntable...are you by any chance trying to set up a new hifi system? Oh, you are? Great! Here are some speakers that people often buy along with this turntable. You know what, we can bundle those up for you in one button click." The power of this is that the design is assisting in an upsell event. Notice, too, that even if the customer isn't ready to buy, they can still add both items to one of their lists for an eventual purchase.

The conversation informs the aesthetic

We could keep going here. The point being made, however, is that the conversation taking place is what informs the design of the page, and ultimately, the aesthetic. Notice that for things like the "Add to Cart" button, they're designed to stand out as the primary thing on the page. The primary button on the top right is given a larger size and more weight, but shares the same yellow gradient with all of the other "Add to Cart" buttons.

What's happening here is that, in addition to answering the customer's questions, they're training them to use Amazon for other purchases, too. Notice how the design of the page isn't specific to the product, but rather, to the task. Everything on the page has a purpose that leads back to the main objective: get the customer to buy something, either now or later.

Now, consider this: if Amazon just said "add the design later," is it likely that they would have come to the same conclusions that we see here? Nope. This is because the design of the page informed the functionality, not the other way around. By putting an emphasis on designing for the conversation taking place, Amazon knew what needed to be on the page. Further, they also knew how to apply aesthetics to add additional context to the conversation. Read that again: they didn't just slap on a coat of paint for the hell of it; the aesthetics we see on the page are there to improve the likelihood of getting the customer to fulfill the primary objective.

Talk it out

While you're working on your own product, consider the conversation taking place. Think about what might be said aloud if you were trying to help a person perform the same tasks your software does in person. What questions would they have while using it? When answering those questions, consider how your design can not only answer those questions, but give added context to improve the answers.

Don't just make a button green for the hell of it: ask from a customer's perspective. Consider that if a button is green on one page, you're training the customer to expect buttons that perform similar actions to be green as well. Work to move your thinking away from design as a purely aesthetic thing and more towards a functional thing. Over time, you'll find that your approach to aesthetics improves greatly because you're not just throwing paint on the walls for fun—you're designing a home for people to live in.

Want to learn how to build a great product with conversations?

Work With Us
Ryan Glover
Introducing: Merlin Patterson

Introducing: Merlin Patterson

A new Beagle!

Today, I'd like to introduce Merlin Patterson, the latest mentor to join the team at Clever Beagle. Merlin reached out a few months back about becoming a mentor and after getting the chance to meet him and work together, I knew he'd be a great fit.

Merlin began coding at the age of ten with an old children's website, Neopets, and then progressed to building games in QBasic in high school. He studied cognitive science and computer science at University of Pennsylvania and participated in over a dozen hackathons.

Upon graduating, Merlin moved to Baltimore and joined ClassTracks, where they continue to build vocabulary development tools for English Language Learners in academia and the workforce. He also teaches classes in basic HTML and CSS, and React at Betamore, a local incubation and co-working space in Baltimore.

Really excited to have Merlin on board. Make sure to have him bring his pupper on camera when you're working together :)

Start working on your product with Merlin

Book My First Session

I have an existing live scoring app written in .net/SQL that React and Meteor seemed to be a perfect fit for.  I've always been weak at JavaScript, so diving into learning React and Meteor for the rebuild was going to be a significant time investment. When I found Clever Beagle's service, I knew it was exactly what I needed to save time, learn quicker, and stay on track and committed to my new project. Weekly sessions with Ryan were so valuable in everything from saving time on troubleshooting and debugging to gaining a more solid foundation in the basics that you just can't get from traditional short tutorials or canned courses. We went from zero to finished product in a few months. I definitely recommend getting on the program with Clever Beagle.

Rob Meronek VP, The Boardr