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.
I've been a fan of Really Good Emails for awhile now. It's a wonderful resource for inspiration on marketing emails, transactional emails, and everything in between—a must-read if you're working on your own product.
Our job is basically finding all the awesome emails that we see and people send to us. We put them in collections, organize and critique them. We are trying to be the epicenter of email marketers, designers, and developers.
They do this extremely well. In this post, a handful of examples are shown ranging from Airbnb to Blue Apron. Each of the case studies explain why the emails are "good" and, if you're paying attention, offer up some wonderful tips for improving your own emails.
I tend to scoff at these types of complain-porn posts, but this one has some really good suggestions/requests in it that apply to a wide-range of SaaS products.
The last wish is the ability to export all relevant data from the account. Right now its close to impossible to move once we have adopted one of you simply because there is still data in there which is needed for a few active projects or project where the client could come back with another development push.
Features like this are easy to backlog, but can be essential to your customers depending on your product and what context it's used in.
[M]ost of you do not let me test out new features before you move them to production. I understand maintaining two versions is annoying and I am ok with there only being a specific time window. But every new release can have implications that I rather wish to be able to prepare for.
This one is a bit tougher for small-scale operations but having a way to beta/pilot new features or major changes is a serious boon on UX (something I'd like to work on at CB). As you work on future iterations of your own product, at the very least consider how significant the changes you're making are and whether or not they'll interrupt your customer's day-to-day workflow.
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.
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 this...how 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?
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 :)
A quickie post that was too good not to share. A handful of solutions to common Git scenarios, both positive and negative. As you build your own product, Git is a serious lifesaver. That said, it can be a little too confusing sometimes which can lead to catastrophic, keyboard-tossing events.
Hopefully this guide will help you to avoid that :)