Featured.

Let’s Explore METS, Part 1
10
Min Read.
By
Five & Done
.

Let’s Explore METS, Part 1

Another Tool in the Risk Assessment Tool Belt?

All posts.

The Oft-Repeated Rants, Philosophies, and Motivational Speeches of a Company Founder
Company
2
Min Read.

The Oft-Repeated Rants, Philosophies, and Motivational Speeches of a Company Founder

Sure, the fish gets bigger every time I tell the story, but that doesn’t mean it’s not a good story.

When we started Five & Done over a decade ago, I had never been at the same company for more than 4 years; I had no idea what was involved with leading a company with consistent values and a consistent mythos; and I didn’t realize how much I would end up repeating myself as I got older. 

I’m a firm believer that how you do one thing is how you do everything and it’s been important to me, since day one, that our clients get a consistently great experience when they partner with us.  

To create that consistency, I’ve consistently shared (read: repeated) a growing set of stories, analogies, diatribes, and wannabe stand-up comedy routines to demonstrate the values that I hope we represent to our clients. 

These “Devinisms” are not exactly earth shattering on their own, but pooled together they represent the values we apply to our work, our clients, and our company culture.

  1. Do Great Work and Be Great to Work With
  2. Quality Assurance is the Cheapest Form of Account Management
  3. Gas Caps & Product Design
  4. Critical Thinking is Great, but What Does it Actually Mean?
  5. Why We Don’t Have Account Managers
  6. Project Managers Aren’t Paper Pushers: Provide Value and Perspective
  7. What We Can All Learn From a Good Real Estate Tour
Quality Assurance is the Cheapest Form of Client Management
Process
4
Min Read.

Quality Assurance is the Cheapest Form of Client Management

For over a decade, we’ve insisted that our clients prefer bug-free launches over free-drink lunches.

TL;DR

  • Winning clients is great, but keeping clients is crucial to a successful business
  • To keep clients, make sure they’re heard and provide the service they actually need
  • If we launch a buggy product, we look bad, but we make our client look worse
  • No one wants to work with a company that makes them look bad. 
  • Kill the bugs. Keep the clients.

Internet Explorer Could Make or Break You

Back in 2009, I was working for a small web agency managing some big projects for Coca-Cola. It was a funny time. Flash ruled the web, the Black Eyed Peas somehow spent 26 weeks on top of the Billboard 100, and about 60% of web traffic went through Internet Explorer. 

At the time, I.E. was up to version 8.0 but our clients at Coke were limited to, version…. Wait for it… 6.0.

SIX POINT OH!

That came out eight. years. earlier, in 2001. Fergie hadn’t even joined the Black Eyed Peas yet. 

Internet Explorer (especially early versions) was notorious for unique bugs. Something that worked perfectly in other browsers had all types of quirks in Internet Explorer. It seemed that, no matter how well we thought we tested, there’d be an inevitable stream of bugs to be reported by our client within minutes of launching something. Our stakeholders would have already tested, but due to the weirdness of I.E., the reported issues typically followed this format:

“A very important VP of something-or-another was looking at the new site and it started doing this horrible thing that made all of us look really bad and we need to fix it immediately”. 

Wow, those emails hurt. 

We were excited about our new launch, and wanted them to be excited too. Instead, we’d be in an excitement deficit pretty much as soon as we launched – and we’d have to dig ourselves out. 

What does this have to do with client management?

Account Management is a role at an agency, but everyone in the company participates in Client Management. 

Clients are people too and want the same things we all want:

  1. They want to feel safe (Read: Vendors they can depend on.)
  2. They want less stress (Read: Predictability is good. Fires are bad.)
  3. They want to look good (Read: Help them succeed)

But when your client finds bugs in a newly launched digital product or website, you’re poking at all the things they want to feel good about.

  1. You’re saying that they cannot depend on you
  2. You’re introducing fires into their world that they will need to put out
  3. You’re making them look bad

In short, you’re making their day harder.

Think of your reputation with your client as a meter that starts at neutral and can either go positive or negative.

When you launch something buggy and make their day harder, you’re taking some points away from the client relationship. How much it negatively affects the relationship will depend on how impactful the bugs are, how long the relationship has been in place, how many eyeballs are seeing it, etc. But we want to avoid any movement to the negative side of the meter; even a few negative points is too many.

That’s not to say it’s insurmountable, of course, but our goal is to build long and productive relationships with our clients. To do so, we need to consistently deliver, instill trust, and demonstrate value. 

Let’s double check the math on this…

We can and do invest in client management through traditional and non-traditional means. But part of that strategy is to avoid moving our relationship in the negative direction. Any step in the negative direction just means additional steps in the positive direction to get where you want to go.

Quality Assurance Testing is something that is baked into the process. We have to do it. If there are 100 bugs to find and remediate, why not invest QA time to address those issues before they become a bigger problem for your client and you. 

If you find and fix all 100 bugs before delivery, your whole team looks capable, your client looks good by delivering on their initiatives, their customers get what they need, and everybodys’ managers are happy. 

If you only find 75 of the bugs before launch, then there are 25 bugs that will be found later. You’ll still need to spend the time to fix them, so you’re not saving money. But now your team looks incapable, your client looks bad, their customers are frustrated, and everybody has to answer to a manager who wants to know where things went wrong.

The next thing they’ll want to know is how to avoid it in the future, and the most obvious answer will be “Don’t use that vendor again”.

Every bug is a papercut and you never know how many paper cuts it will take to kill your relationship.

In short, just do it right the first time.

More in this Series

  1. Do Great Work and Be Great to Work With
  2. Quality Assurance is the Cheapest Form of Account Management
  3. Gas Caps & Product Design
  4. Critical Thinking is Great, but What Does it Actually Mean?
  5. Why We Don’t Have Account Managers
  6. Project Managers Aren’t Paper Pushers: Provide Value and Perspective
  7. What We Can All Learn From a Good Real Estate Tour

How to Do Great Work and Be Great to Work With
Company
6
Min Read.

How to Do Great Work and Be Great to Work With

Who would have thought “Don’t be a Jerk” could be a competitive advantage?

Author’s Note on the Title: My 7th grade English teacher drilled the point home to “never use a preposition to end a sentence with.” And here I am blasting out a title like that, with reckless abandon. Apologies Mr. Dugan. 

Now that we got that out of the way…

TL;DR

  • One of our founding philosophies at Five & Done was to listen to the negative things our clients would say about other vendors, and not do those things
  • Most of the complaints we’ve heard were about the experience of working with that vendor, not the work they delivered
  • We’ve identified consistent complaints we’ve heard about other vendors, and strategically built our team and processes to avoid those problem areas

How it Began

Like many companies, Five & Done was founded with a healthy mix of hubris and naiveté and that nagging thought that pops into your head after a particular meeting, or maybe late at night when you’re filling your partner in on your day: 

I think we can do this better ourselves.

The “this” came from years of working with clients in different settings but hearing the same feedback (or gossip?) about their “other vendors”.  Maybe it’s human nature, but much of what we heard wasn’t positive, and very rarely were the complaints focused on the work they provided; it’s focused on how they provide it. 

So the hypothesis that kicked off this Five & Done experiment was: If our clients are unhappy working with their other vendors, can we succeed by avoiding their pitfalls?

To be clear, we consider great work to be a prerequisite for starting a design and technology studio. If you’re aiming for mediocrity, just go home now. That part isn’t revolutionary. But it’s easy to ignore the experience your customers are getting when they work with you. We believed that focusing on that would, somewhat surprisingly, be a secret ingredient in the Five & Done special sauce.

How are agencies and studios failing to serve their customers (or, what should you avoid if you want to do right by your customers)

So much of what you hear about other vendors might be project specific, personnel specific, or taken out of context, but themes do emerge. 

  1. Team Size / Bloat: The feeling that the team is either bigger than it needs to be, or it has gotten too big to move efficiently and your client isn’t getting value.
  2. Forced ideas / Concepts / Strategies: The feeling that the vendor is not listening and trying to force their ideas.
  3. Lack of Proactive Problem Solving: The feeling that the vendor is not in tune with the challenges and not acting in the client’s best interest.
  4. Difficult to Work With or Reach: The feeling that they can’t get what they need from the vendor, especially in a pinch.
  5. Missed Deliverables: The feeling that a vendor will not deliver and the anxiety that it induces.

I started each of these with “the feeling” because the issue with each is not the tangible deliverable that may be associated with the work; it’s the way a vendor makes their client feel within the working relationship. 

"People will forget what you said. People will forget what you did. But people will never forget how you made them feel"
Maya Angelou

I’m like 97% certain that Maya Angelou wasn’t referring to client management when she penned these words, but they couldn’t be more true here. 

How we provide design and technology services with a customer service approach

On top of creative chops or technological know-how, our backbone is customer service. We are a service business and we have customers, so customer service is as important to our success as it is to any other type of business, if not more. 

That mindset has influenced our operation in a variety of ways:

  • Hiring decisions: Sure, we’ll ask about professional experience in interviews, but we also ask about other jobs they’ve had to see if they’ve worked in any customer service type roles (waiter, host, call center, sales, hospitality). A past job as a Starbucks barista is more applicable than you’d think. 
  • Growth and mentorship plans: Each employee review comes with a growth plan and they often involve courses, books, and exercises that are closely or tangentially related to customer service (e.g. communications, public speaking, account management, even sales) regardless of role.
  • Project processes: When we start on a new project, we evaluate what our client needs from this effort, who the stakeholders are and what are their roles on the project, how they work together, and how other partners are involved. Then we tailor our process to meet those needs. That might include scheduling certain types of meetings or check-ins, choosing how we format our deliverables, identifying the breakdown of roles and responsibilities, and defining the best communication style.
  • Client deliverables and how we put them together: When we review deliverables internally, we definitely challenge the work itself, but also consider the best way to put it together to ensure our stakeholders feel heard and get what they need. Sometimes that means exploring concepts that we know our clients feel strongly about, even if we see issues with them, so we can provide a balanced perspective and offer choice.
  • Communication style: Doesn’t it all come down to communication? How you say often matters more than what you say. You’d be surprised how often everyone here asks a coworker to review an email, deck, or even Slack/Teams message to make sure it takes the right tone (productive, helpful, clear, and with perspective).
  • Being Human: We are people, our clients are people, and we want to form human connections so we can do great work together. That doesn’t mean we’re all going to be best friends, but it does mean we don’t pretend to be uniform cogs in a design and development machine. When you work with our team, you get to know each of them, and in most cases (hopefully), you get along and like working with them – and want to continue to work with them. 

But does it work?

Our hypothesis from over a decade ago has proven to be right. We’ve enjoyed consistent work from large and small clients alike. And while we’re proud of the work we’ve done over those years, we’re just as proud of the longstanding relationships we’ve forged. 

As of writing this, we’ve actively worked with each of our clients for an average of 34.5 months – nearly three years! And our first client is still a client today. That’s our evidence.

I’m sure you’re reading this wondering how good it can be to work with a friendly, dependable, respectful, and capable team. Reach out if you need help solving your customer experience and technology challenges and we’ll show you how we do it.

More in this Series

  1. Do Great Work and Be Great to Work With
  2. Quality Assurance is the Cheapest Form of Account Management
  3. Gas Caps & Product Design
  4. Critical Thinking is Great, but What Does it Actually Mean?
  5. Why We Don’t Have Account Managers
  6. Project Managers Aren’t Paper Pushers: Provide Value and Perspective
  7. What We Can All Learn From a Good Real Estate Tour

Parabol, Our Winner for Scrum Ceremonies
Process
4
Min Read.

Parabol, Our Winner for Scrum Ceremonies

Want to transform your dull Scrum ceremonies into engaging, productive sessions? Discover our secret weapon!

Our scrum team follows the traditional structure of scrum ceremonies, though we have encountered a challenge with team member engagement. So we started looking for a sprint poker style tool that could help improve engagement, but it needed to have a straightforward interface for providing estimates, and ideally seamless integration with Jira to enhance our workflow.

In our quest for the best tool, there was only one that really stood out. We found a few tools useful that allowed team members to vote on estimates anonymously, though these were lacking in other features we were really hoping for.

Our requirements for a sprint poker tool are not excessive. We needed something that was easy for members to join the session, a simple user interface for casting votes, and preferably something that integrated with Jira.

Tools that didn’t quite meet our needs

  • Scrum Poker: This is a free tool that allows team members to join per session, and even has integration with Jira. The user interface is not great and the ads can be quite annoying.
  • Planning Poker Online: Another free tool that allows team members to join by session, though there is no integration with Jira. This was one of our more favored tools, though it just feels like a lot is missing.

Along came Parabol

During our pursuit for improvement, we engaged in discussions with several Five & Done teams. Among their recommendations, Parabol stood out, as another team had discovered it while researching and perusing various articles. Their goal was to enhance their retro meetings as they had become stale. Parabol has enabled more engagement in their team meetings and led to the recommendation for our team as well.

Once incorporating Parabol into our ceremonies, our scrum team has found that it’s a great tool for our needs, particularly the Estimated Effort (sprint poker) feature, which once integrated with Jira, automatically updates the story points on the Jira ticket. Additionally, Parabol provides the ability to pull in the tickets planned for the meeting, eliminating the need to scroll through the backlog; as well as provides a nice summary of the estimated points once complete.

Based on a series of tasks, we can prioritize which one we will do estimates on.
Photo credit: Parabol

Team members can select their estimate based on a task.
Photo credit: Parabol

A team can provide their estimates on any given task.
Photo Credit: Parabol

To further enhance our utilization of Parabol, we have begun using the retrospective feature as well. As the team who recommended this tool to us mentioned, this has helped our retros become less stale as well by selecting different templates per retro. Again, we also find the summarization after the ceremony to be useful so we can easily go back and review.

Teams can create notes within the Start, Stop, Continue columns in a retrospective anonymously.
Photo Credit: Parabol

The team has an opportunity to group ideas that are similar to then be voted on to talk about.
Photo Credit: Parabol

Teams can vote on which subject is most important to talk through to share with the team.
Photo Credit: Parabol

Recommendations

If you are a Project Manager, Scrum Master, or any member of a development team that is in search of an estimation tool, we highly recommend checking out Parabol. While one of the highlights for our team is certainly the integration with Jira, the user interface and the ease of scheduling and joining the meetings in Parabol make it worth your time to check out, even if your projects do not utilize Jira.

From Concept to Reality: How I Used AI to Build a Slack Polling App
Development
7
Min Read.

From Concept to Reality: How I Used AI to Build a Slack Polling App

Struggling with a pricey Slack polling app? We detail how we built a free, AI-powered alternative using surprising tools - and the valuable lessons learned along the way.

As an Executive Producer at Five & Done, I've led digital projects that required a unique blend of technical and creative skills. For many projects and processes, we use Slack and its various applications. In this case, we’ve used the same Slack polling app for years to gather quick feedback, from where we should go to lunch to what music should be on the Sonos. When that app started charging a substantial subscription fee, I saw an opportunity to build a suitable replacement using artificial intelligence. In this article, I'll share my journey of creating 'Easy Polls,' a Slack app that harnesses AI to poll fellow users, including the challenges I faced and the valuable lessons I learned along the way.

Embracing AI in Development

My decision to build a Slack app with AI was driven by a desire to explore simplifying the development process and pushing the boundaries of my existing technical skillset. By harnessing the power of AI, I was able to significantly reduce development time, improve the accuracy of the code, and improve the app's overall functionality. This experience has opened my eyes to the immense benefits of AI in development.

Collaborating with AI: A New Way of Working

Working with AI is an incredibly collaborative experience. I would provide the AI with prompts, which it would use to generate code. I would then review the code, make necessary adjustments, and provide feedback to the AI to refine its output. This interactive process of human and machine made the development journey more efficient and made me feel like an integral part of the AI's learning process. It's this sense of collaboration and empowerment that AI-driven development brings.

Technologies Used

I leveraged a range of innovative technologies to bring my vision to life. Here are some of the key technologies I used:

  • Google's Gemini 1.5 Pro: This AI model was crucial in generating code and simplifying development. Its ability to accept file uploads was invaluable, allowing me to streamline the development process. However, this model had slightly longer response times compared to GroqCloud.
  • GroqCloud with Llama3-70b: I utilized this powerful combination to tap into the ultimate combination of knowledge and speed. This combination provided AI responses in a quarter of the time it would take Gemini to provide a similar response.
  • BoltAI: This innovative application allowed me to consolidate my various chats and discussions across multiple AI models into a single, convenient platform.

Overcoming Challenges

One of the biggest obstacles was setting up a secure database connection to store user poll data (in Google’s Firestore). Another challenge I encountered was configuring the Slack integration to enable seamless polling within our team’s communication channels.

To overcome these challenges, I used a command-line tool to troubleshoot port issues and carefully reviewed documentation to ensure the correct setup. Additionally, I consulted with our development team and online resources to resolve code conflicts.

Lessons Learned

  • AI-driven development requires a different mindset and approach, where you guide and correct the AI like an inquisitive teacher.
  • Human oversight and judgment are still essential to ensure AI-generated code meets standards, highlighting the vital role of developers in AI-driven development. 
  • A technical background helps you ask the right questions and correct AI when necessary. 
  • The future belongs to developers who harness AI, not those who resist it. 
  • Not all AI models are equal; sometimes, switching between models is necessary to overcome specific obstacles.

The Future of AI-Driven Development

Whether automating testing, generating boilerplate code, or assisting with debugging, AI has proven to be an invaluable tool in our development arsenal. AI will continue transforming our digital product development, and harnessing this technology in your workflow will be more important than ever.

At Five & Done, We're Committed to Innovation

At Five & Done, we're committed to embracing innovative technologies like AI to drive innovation and efficiency in digital product development. As we continue to explore the possibilities of AI-driven development, we want to inspire others to join us on this journey and create innovative digital products that make a real impact. What's next for you? Will you harness the power of AI to create something amazing?

Detours & Discoveries: A Five & Done User Research Journey
Process
6
Min Read.

Detours & Discoveries: A Five & Done User Research Journey

Explore the challenges of understanding car shopper behavior through surveys. Learn how combining research methods can lead to richer user insights and a more effective car shopping experience.

Backstory. 

Shortly after I joined the design team at Five & Done, I was asked to put my data science hat back on and dig into some user research we had just completed for one of our clients in the automotive industry.

We’re constantly looking for ways to improve online car shopping, and one of our areas of expertise is the Special Offers part of the site. This is where an auto brand will advertise regional incentives, finance deals, lease specials, and other promotions.

Examples of OEM (Original Equipment Manufacturer) Special Offer pages

To improve conversions for our client, our team had to better understand what car shoppers thought of these offers, how well they understood them, and where in their shopping journey they considered them. Armed with tons of caffeine, another designer & myself set out to seek answers (and maybe a few tips for when I eventually buy my first car 👀).

In this post, I’ll share some challenges and lessons we learned on our user research journey.

Survey sorcery.

On average, a car shopper takes 100 days from “I should buy a new car” to actually driving off the lot. Well, when you're looking at website analytics, you don’t always know if that shopper is on Day 1 or Day 100 of their journey to new car ownership. Our team needed to understand more about intent at different stages of the shopping and decision-making process. We also needed a statistically significant data set. User testing would be too anecdotal at this stage. 

We needed to go breadth-first.

This is why we kicked off with an industry-wide online quantitative survey. We cast a wide enough net to collect data points from 500 recent car shoppers & purchasers, and then manually performed cross-analysis on the Qualtrics platform (as a former data scientist in big tech, I nerded out here). So! Much! Data!

This method served our purpose, which was to understand general roadblocks in the shopping funnel. We also found it to be an efficient way to gather statistically significant answers, such as discovering that 60% of customers shop with a ‘vehicle-first’ mindset and use OEM websites mainly to understand which models & trims fit their needs. 

But that doesn’t mean the survey on its own was the most comprehensive for our research goals.

For example, one of the eyebrow-raising stats we gathered from our survey analysis that was relevant to our goal of revamping our client’s offers page was: 

“65% of shoppers are price-conscious, but only 18% considered OEM offers”

The data told us that people cared about price, but also told us they did not care about offers. Unfortunately, that’s all the data told us on this topic. It did not address the reasoning behind the apparent contradiction there. This example actually represents a limitation we discovered with surveys when trying to unravel the mystery behind car shoppers being lost in the sea of car offers. Sure, all of those stats are great. But when you can’t pinpoint the why, there isn’t much to evaluate and consider when designing new screens later on. 

This limitation became more obvious when paired with other research challenges we encountered - 

  1. Poor response quality. Conflicting survey data, incomplete answers, & ambiguity of answer options all made it difficult for us to identify shopping frustrations and trends.
  1. Recall bias. A good chunk of surveyed shoppers had purchased a new car several months prior, leading to unreliable responses without knowing more about the person.
  1. Lack of user familiarity. Several shoppers may not understand how offers are applied to a car purchase and their final payment.

So at the end of the day, while we surfaced what some pain points were and how many shoppers experienced them, we still didn’t fully understand shopper habits and motivations…

…which brings me to my next point. 

Context matters. 

As a next step, our team conducted remote moderated 1-1 user interviews to dive deeper into the survey data we found interesting, such as the one pointed out earlier. Specifically, we talked to 10 recent purchasers, 5 early-stage shoppers, & 5 late-stage shoppers across the country.

How did we reach this decision? 

While the survey was a good way to get insights on how widespread certain problems were, we chose user interviews to explore individual motivations & experiences that numbers alone couldn’t reveal. At the end of the day, car shopping is a niche activity. If we were studying user behaviors in e-commerce, our approach may have been different. 

Our decision to continue with this form of qualitative research was fruitful, as we got juicy insights we wouldn’t have otherwise. 

Getting to talk to shoppers about the actions they actually took/are taking was a stark contrast to the previous survey responses, in which people indicated what they would do in theory. For example, in our 1-1 interviews, many users stated that during their journey, it was mentally taxing to interpret the information & overall value of online OEM offers amidst an already stressful process. As one of them best put it - “It’s a $50,000 purchase, I’m not just buying shoes!”

An interviewee resorting to ChatGPT to try to make sense of an offer

One challenge that we faced was deciding the number of users we should talk to. If you’re a stats nerd, you’ve heard a large sample size is foolproof because of lower margins of error & standards of deviation. But, this is a manual process and not scalable. It was critical to get valuable insights as efficiently as possible. In our scenario, we found that less is more. After talking to just 5-7 users, the same patterns started to emerge. If we were to go back and save some time & money on this project, we probably could have gained the same insights with a smaller sample size. 

Couple final thoughts.

Still there? 

If you’re currently in the midst of combing through lots of data or are about to start your UX research journey, some things to consider - 

It’s okay to combine different methods. A two-pronged approach that focused on breadth & depth was very useful for this project. At Five & Done, we value diverse perspectives and using different methods covered unique POVs that may have been missed with a single approach. It was also helpful because of cross-validation, as combining methods allowed for validation of certain survey findings, increasing the reliability of insights. 

(If you’re short on budget and time, however, I’d suggest going straight into a few user interviews.)

Moving forward, how can we leverage AI for UX research? We all know AI is taking the world by storm, and there seems to be a new AI-based tool for just about everything. Even an ‘AI Excuse Generator’, a godsend for the perpetually tardy among us. 

AI is already revolutionizing UX research by automating data analysis and uncovering user needs faster. 

Tools like - 

A huge challenge in our project included using a not-so-user-friendly Qualtrics platform to run multivariate analysis with their cross-tabulation tool while remembering different combos to try, and going back & forth to watch interview clips at 1.5x speed while reviewing transcripts in-depth. If we were to redo our approach (or apply this learning to future projects), I believe leveraging AI-based tools will save time in manual processes, reduce human error in data calculations, & take it to the next level of contextualizing user pain points. 

Anddd that’s a wrap!

Thanks for reading my reflections as a data scientist-turned designer. Hope you learned a thing or two from our user research journey, and stay tuned for more content in the near future!

Slack, API Gateways, Step Functions, Lambdas, Oh My!
Development
10
Min Read.

Slack, API Gateways, Step Functions, Lambdas, Oh My!

Struggle with daily lunch decisions? This guide unveils a Slack app solution! Integrate Google Sheets for a personalized lunch recommendation system, all within your Slack workspace.

Premise

The struggle of deciding where to go for lunch is real, especially at Five & Done. Fueled by the collective frustration, I built this app to streamline the lunch decision process. It seamlessly integrates with our existing Google Sheet of favorite restaurants, allowing us to get recommendations, avoid repeats, and even add new discoveries – all within Slack.

Building a Slack app that communicates with Google Sheets seemed easy at first. Then, I ran into a timeout issue. The problem was that Slack expects a response to its request within 3 seconds (3000 milliseconds) and the request to Google Sheets simply took longer than that. To address this, I needed to add API Gateway in front of the Lambda function. This allows for a quick response to Slack, letting it know that the request was heard and processing is underway. Tutorials got me 90% there, but the last 10% was tricky. Hopefully, this walkthrough on how I connected Slack, Lambdas, and Sheets can help you as well.

Side note - DB: I used Google Sheets as my database because that's what we started with. You can, of course, use any database you'd like, as this tutorial focuses on connecting a Lambda to Slack and not to Sheets.

Side note - Focus: This guide focuses on lunch recommendations, but I can't assume everyone has the same problem. Fortunately, the solution can still be applied to multiple cases. However, if you'd like a similar problem to get started, here's a dummy lunch list.

Set up: Slack App

First, I started a Slack app and created a new slash command called `/lunch-lad`. My expected syntax is `/lunch-lad [command]`.

Set up: Lambda Functions

Next, I created two Lambda functions:

  1. Sort and Parse: This function grabs the response URL, used to respond to Slack, and also identifies the command type, which will be crucial for Step Functions later.
exports.handler = async (event) => {
 // ~ Parses the body of a Slack request, decoding the URL-encoded key-value pairs.
 function parseSlackBody(body) {
   const keyValuePairs = body.split("&");
   const parsedBody = {};


   for (const keyValuePair of keyValuePairs) {
     const [key, value] = keyValuePair.split("=");
     const decodedValue = decodeURIComponent(value);
     parsedBody[key] = decodedValue;
   }
   return parsedBody;
 }


 const parsedBody = parseSlackBody(event.data);


 const { response_url, text } = parsedBody;


 let fields = {};


 switch (text) {
   case "recommend":
     fields = {
       response_url,
	type: text,
     };
     break;
 }
 return fields;
};
  1. Recommendation: This function reads the lunch table in your Google Sheet and returns a random recommendation, excluding recent visits. You can configure messages to be ephemeral (visible only to the user) by excluding `in_channel`.
const { google } = require("googleapis");
const axios = require("axios");


const SPREADSHEET_ID = "SHEET_ID";
const SHEET_RANGE = "SHEET NAME!A:A"; // Adjust range based on your data


exports.handler = async (event) => {
 let status = "success";
 async function getRestaurants() {
   const sheets = google.sheets({
     version: "v4",
     auth: "AUTH", // Switch out your own auth
   });


   try {
     const response = await sheets.spreadsheets.values.get({
       spreadsheetId: SPREADSHEET_ID,
       range: SHEET_RANGE,
     });
     const restaurants = response.data.values || [];


     let filteredRestaurants = restaurants.filter((item) => item.length > 0);


     const oneMonthAgo = new Date();
     oneMonthAgo.setMonth(oneMonthAgo.getMonth() - 1);
     const oneMonthAgoTime = oneMonthAgo.getTime();
     filteredRestaurants = filteredRestaurants.filter((item) => {
       if (!item[4]) {
         return true;
       }
       return new Date(item[4]).getTime() < oneMonthAgoTime;
     });


     return filteredRestaurants;
   } catch (error) {
     console.error("Error fetching restaurants:", error);
     status = "failed";
     return [];
   }
 }


 async function recommendLunch() {
   const restaurants = await getRestaurants();
   if (!restaurants.length) {
     return "Sorry, no restaurant recommendations found!";
   }
   const randomIndex = Math.floor(Math.random() * restaurants.length);
   const restaurant = restaurants[randomIndex];


   return `Today\'s lunch recommendation is ${restaurant[0]} (${
     restaurant[1]
   }). ${restaurant[4] === "" ? `` : `Last eaten at ${restaurant[4]}`}`;
 }


 const recommendation = await recommendLunch();


 const params = {
   method: "POST",
   url: event.response_url,
   headers: { "Content-Type": "application/json" },
   data: {
     response_type: "in_channel",
     text: recommendation,
   },
 };


 await axios(params)
   .then(() => {
     console.log("SUCCESS!");
   })
   .catch((err) => {
     console.error(err);
     status = "failed";
   });
 return status;
};

Step Functions

What are Step Functions?

Step Functions is an AWS service that lets you define the flow of your code visually. Imagine a recipe with multiple steps. Step Functions helps you manage these steps in your code.

  1. I created a new State Machine in Step Functions and chose a blank template.
  1. In the Config tab, I named the machine “lunch-machine” and changed the type to Express. According to this video tutorial, the main reason I got 90% to the finish line (thanks, Magestic.cloud!), Express can do asynchronous and synchronous executions, and it’s cheaper than standard.
  1. I set the first step to call my sort and parse function by dragging the AWS Lambda Invoke block from the left sidebar and setting Function Name to target my `lunch-sort` function. I know the return will include a command type which I will listen for in the next step.
  1. Using a Choice Flow as the next step, I can sort which function will be called by checking if the variable `type`, returned in step one, is "recommend." Later, when other commands are added, more conditions can be added to the Choice Flow. I prefer this branching method since it’s visually organized, and lambda functions are created separately from each other, making it easy to edit and debug.
  1. Under the "recommend" rule in the Choice Flow, I added another AWS Lambda Invoke block to call the `lunch-recommendation` function. Later, I’ll add an error function to send a Slack message if the command isn't set, but for now, I set the flow to fail.

Side note: I like to label the State names as something easy to read at a glance to know what’s happening at each block level.

When you create the state machine, an IAM role will automatically be created alongside it. If you add new Lambdas, you’ll have to manually update the IAM's Lambda invoke policy to include those functions. Otherwise, you’ll get permission errors.

API Gateway: Part One - IAM Role

What is an API Gateway?

API Gateway is an AWS service that acts as a secure, centralized entry point for applications to interact with your services (like Lambdas).

  1. While Step Functions automatically create IAM roles, API Gateway does not. To grant API Gateway the necessary permissions, I manually created a new IAM role. I specified the role type as 'AWS Service' and designated 'API Gateway' as the service.
  1. I created the role with the name LunchGatewayRole, then added Step Function permissions to it.

API Gateway: Part Two - Set up

  1. In API Gateway, I created a new REST API and named it “LunchAPI”.
  1. Then, I created a new resource that will be invoked by the `/lunch-lad` slash command and pass on the payload to Step Functions to be parsed.
  1. Under the resource, I created a POST method with the following configuration:
  • method type = POST
  • integration type = AWS service
  • region = [same region as step function]
  • aws service = Step Functions
  • HTTP method = POST
  • action name = StartExecution
  • execution role = [IAM role ARN for Gateway]

API Gateway: Part Three - Integration Request

Here’s where the last 10% of work took the longest to complete. I needed to transform Slack’s HTTP POST request into a format that Step Functions understood. I knew from testing that Slack's slash command payload would come in as encoded content, but I could not get the payload to work with the mapping’s JSON. I finally figured out that the mapping template’s content type had to match the content type of Slack’s request, `application/x-www-form-urlencoded.` The payload also had to be changed so that it would pass in input. You can read more about the slash command here and more about creating mapping templates here.

TL;DR

  1. Edit the Integration Request's mapping template and set the content type to application/x-www-form-urlencoded.
  2. Set the template body with your State Machine ARN (replace the placeholder). The name is optional (for logs).
{
 "input": "{\"data\": $util.escapeJavaScript($input.json('$')).replaceAll("\\'","'")}",
 "name": "MyExecution",
 "stateMachineArn": "[REPLACE WITH YOUR STATE MACHINE ARN]"
}

API Gateway: Part Four - Integration Response

I also customized the response Slack gets, confirming that the request was received in the Integration Response tab. For now I kept it simple with a “Command received.” but you can find more information about confirmation receipts here

{
 "text": "Command received.",
}

Deploying the API and Wrapping Up

I deployed my API Gateway and created a new stage called dev. Then, copied the Invoke URL under the method (it includes the stage and resource path) for Slacks slash command settings.

Set Up Slack Integration

In my Lunch Lad app settings, I pasted the copied Invoke URL into the Request URL field and then installed the app to my workspace.

Done!

This tutorial covered a basic app with a single command, but other features could be added like:

  • Modals for more complex user interactions
  • Shortcuts for easier access to specific commands
  • Additional commands

Troubleshooting Tip:

Step Functions provides a visual log that helps pinpoint where errors occur in your workflow. This makes troubleshooting much easier!

Security Note:

Consider using environment variables like your State Machine ARN to store sensitive information. This improves security by keeping sensitive data out of your code.

I hope this comprehensive tutorial empowers you to build your own Slack app!

Putting the Proof Into the (E-Commerce) Pudding
Thoughts
8
Min Read.

Putting the Proof Into the (E-Commerce) Pudding

E-commerce has too many options, making shopping hard. People trust friends and influencers more than brands. The article proposes an online store design that uses recommendations and user reviews to make shopping easier and more trustworthy.

Welcome back! It’s In Case of Inspiration from Five & Done — a series of Case Study Projects and stories that provide insight into ideas we believe are better digital experiences and solutions. Each Case Study experiments with new tools and methods for building emotionally evocative stories and experiences.

In this Case Study, you’ll get a hot take from us, see a problem we identified through some user research, and then get a peek at a solution we came up with.

Let’s get after it.

Hot Take.

Everything that made e-commerce so great is why it sucks now.

I grew up watching the internet grow up. I printed maps off of MapQuest. I buffered Netflix ‘Instant Play’ movies hours before we wanted to watch them. I had an Amazon account with free Prime membership before it became paid.

E-Commerce has come a looong way since then. But at the same time, it hasn’t. Until influencers. But I’m getting ahead of myself. We’ll come back to that. Let an old man reminisce a bit longer, won’t ya? (Ed. He’s only 30.) So yeah, being able to buy things online was practically magic. “Any sufficiently advanced technology is indistinguishable from magic,” said Arthur C. Clarke

You didn’t have to drive around store-to-store checking for a product you wanted. Magic.

You weren’t limited by whatever your local brick-and-mortar store had in stock. Magic.

Heck, you weren’t limited by whether a store existed in your town or not. Magic.

But the world was a lot smaller then. To put things in perspective, when Amazon Prime first launched in 2004, there were only 1 million eligible Prime products. Fast forward nine years to 2013, and there were 20 million eligible Prime products [1]. In 2023, that number has grown to over 100 million [2]. In just 20 years, we saw the number of products available on Amazon grow over 100X. And that’s to say nothing of all the direct-to-consumer brands, marketplaces (e.g. Etsy), and social media shops.

I don’t know about you, but I don’t need THAT many options to find what I’m looking for.

But maybe that’s just me?

Getting Some Answers.

To find if it was just me, or if others felt the same way, we interviewed 4 people from our team. We prompted them to “tell me about a time when you had a difficult experience shopping online” and sat back to listen.

Hoo boy did we go down some rabbit holes! We heard about everything from trying to buy a new toolbox, to buying a kid’s first bike, to finding a ‘fit for the office holiday party.

As it goes, people aren’t single dimensioned, and had opinions all across the spectrum.

I’d rather pull my hair out one strand at a time than go shopping in person.

BUT ALSO…

There are so many websites, and I don’t know which ones are good, which are legit, which work for me…it can be really frustrating.

In summary, we heard that people love the breadth of options and convenience of shopping from home/phone/work/toilet, but are overwhelmed by the same breadth of options and inability to evaluate the product from home/phone/work/toilet.

Humans, man. Who let us evolve to have opinions beyond the best kind of banana?

But hey, our interviewees did validate that e-commerce is both benefited by and kneecapped by its value proposition of options and convenience.

Smart Cookies.

If you’re in the technology space like we are, you probably think this section is gonna be about web cookies, or something like that. Sorrrrrry, I’m actually talking about the four employees we interviewed. They’re smart cookies. They all have ways of cutting through the noise to find the product they finally end up buying.

Here’s what they said:

An influencer can be like a best friend you can just call.
When a product is on an influencer’s Linktree, I can trust that it’s something she’s actually wearing out of the house.
I get really detail oriented and dig through reviews like crazy. I will scroll through pages and pages until I feel satisfied.
It’s nice that there are people out there who look into products for people who aren’t experts.

I told you we’d come back to influencers, didn’t I?

Overwhelmingly, we heard our shoppers say that they go to lengths to seek out trustworthy recommendations from trusted sources such as friends, blogs, and influencers.

But it’s not just our shoppers who say that.

Forrester’s August 2023 Consumer Pulse Survey says that, “For Gen Z youth, nearly half say that online influencers/creators are the primary way they discover new products or brands.”

(Ed. Pause for dramatic effect and personal reflection here.)

The Problem.

The Problem: Trusted sources aren’t on hand where you’re shopping.

To solve this problem, we directed our design efforts around three guiding insights distilled from our interviews:

  1. Affiliated social proof builds trust with new shoppers.
  2. Third-party content is more useful than branded content.
  3. Ruling a product out is just as valuable as ruling it in.

A Solution.

We conceptualized a solution with an imaginary online bike shop called “Five & Ride”. Inside of this fake store, we re-imagined four key areas of the e-commerce experience to bring those insights to life.

  1. Bring Your Affiliates In-Store.
  2. Demonstrate Social Proof ASAP.
  3. Let Product Pages Become Conversation Places.
  4. Connect Your World To Your Shopper’s World.

1: Bring Your Affiliates In-Store.

Our Riders.

Brands work hard to curate their Affiliates and Brand Ambassadors. Why not feature them and their recommendations in store? It’s no secret that influencers have transformed the way we shop, so let’s embrace that.

Shoppers say, “[they] take the need for true research out of it.”

Filter By Expertise.

Most brands have product offerings in many categories, but most Affiliates and Brand Ambassadors have a niche they specialize in. Let’s allow a shopper to identify and relate to Brand Ambassadors in the niche they are specifically interested in.

Rider Highlights.

Do you read the blurb and quotes on the back of a book before buying it? We imagine bringing that to products online. As a shopper is browsing the Affiliates (or Riders) page of a site, this feature helps demonstrate the Affiliate’s area of expertise and preferences.

Shoppers say, “yes, there are biases, but if [all the affiliates] are recommending it, it’s probably worth it’s salt”

2: Demonstrate Social Proof ASAP.

Categorical Social Proof.

We heard shoppers say it’s risky to trust new brands, and it’s easier to stay loyal to brands they already know and have a history with. But, a recommendation from a trusted source can build trust immediately. By demonstrating this social proof at the category level, e.g. Mountain Bikes, we’re giving the shopper the ability to browse products with a sense of trust and confidence.

Product Cards.

Designed to inspire confidence while browsing, the product card surfaces Shopper Engagement, Customer Satisfaction, and Social Proof. These elements are designed to facilitate easier browsing and clicks down the funnel to the product page with greater confidence that the product will fit your needs.

Shoppers say, “[I scroll] hoping that something will spark a little hope in me.”

Social Proof Filters.

Because Social Proof is such a confidence builder for shoppers, we’re giving shoppers the ability to view only products that are recommended by Brand Ambassadors.

3: Let Product Pages Become Conversation Places.

Product Forum.

For all shoppers, there will be a time when you’re shopping for something for the first time. And at that time, you need advice and education. Shoppers struggle to trust the advice from a brand, because it has an inherent bias toward their own products. This is why we imagine a Discord, or Stack Overflow, like forum for shoppers to ask and answer questions, view community content, and gain confidence in their research journey.

Shoppers say, “I want to make sure I’m not settling.”

“For You” Message Tags.

Messages by people you follow, are connected with, or are brand ambassadors will pin to the top of the message thread. These are the most relevant to the shopper and should provide the most valuable context and content.

Shoppers say, “I want to make sure I’m investing my money in things that aren’t sh*tty.”

Social Media Connections.

Seeing real people with the real product feels more trustworthy and authentic than branded content. This connection to social media apps, such as Instagram and TikTok, accelerates the amount of organic content that would normally make it onto a Product Page.

Shoppers say, “I really lean on reviews…[even though] it’s so hit or miss.”

4: Connect Your World To Your Shopper’s World

Social Connections.

Shoppers are able to follow purchases of their personal connections, not just the Brand Ambassadors, when they connect a social media account. This connection enables social media posts to be shared from the social app to a Product Thread.

Followed Profiles.

Shoppers can manage who they follow at this store. They are able to follow Brand Ambassadors and connections from linked social media accounts.

Previously Viewed.

Window shoppers tend to put items in a cart and sit on it, but not everybody does that. With a clear viewable history, shoppers can easily revisit products they’ve engaged with. Additional to items left in cart, items from a shopper’s history becomes another dynamic email campaign touchpoint.

Fin!

So, what do you think? Would you want to see this where you shop?

When we demo’d this concept to our team, we saw a split of who wished it existed and who didn’t really care for it.

It came down to a mindset split. For people who already seek out recommendations and reviews, this felt like a big, desirable step forward. For people who didn’t already rely on recommendations, this didn’t do much for them.

And you know what? That’s perfect. There’s never a one-size-fits all solution. “People do not want all-purpose; they want high-tech specificity” says James Dyson.

He’s dead right.

At the end of the day, as designers and builders of products, our core goal is to help people do what they’re already trying to do (or want to do) better.

Sometimes it’s more abstract, sometimes it’s more obvious. Every time we’re gonna bring something thought-provoking to the table.

P.S. — This blog is not the best place to experience this concept. It just doesn’t facilitate great image experiences. To really experience this concept in full, pop out to this mini-site we built for it!

P.S.S.— here’s an index to other articles in this series.

  1. Nella: From AI to ZZZ
  2. Putting The Proof Into The (E-Commerce) Pudding
  3. Build-A-Bronco: Finding The Right Look

…and much more to come!

My Lord and Savior Werner Vogels: From Monoliths to Serverless
Development
15
Min Read.

My Lord and Savior Werner Vogels: From Monoliths to Serverless

Feeling stressed about managing servers? Us too! That's why we're obsessed with serverless architecture on AWS. This article dives into our journey, exploring the benefits (cost-efficiency, scalability, development speed) and challenges (vendor lock-in) of going serverless.

This article is about how we generally architect our products and platforms to be more resilient, low maintenance, and stress-free for our clients. This is also a biased opinion, as we've put many eggs into one cloud bucket (AWS). Our expertise in AWS services has allowed us to address many of the drawbacks you might hear about in other articles you have read. 

Most organizations choose one path, but there is a middle ground between microservices and serverless infrastructure, and I'll also explain how some organizations might consider architecting their solutions. Again, this does require choosing AWS as a long term partner and incurring vendor lock-in, but if that's ok with you, as it is with us, you'll find that systems can run smoothly without a vast team and much cheaper for most use cases.

The goal has been simple for us: put as much responsibility on AWS as possible to keep operations running with low overhead while following the shared responsibility model. Serverless allows us to do this more effectively. 

Servers Suck, and Vogels Knows Better!

The very first time I realized servers suck was back in June of 2012. It was my first day on the job, and we were launching a brand-new E-commerce site. I know it's not the best situation to find yourself in on the first day, but I was up for the challenge. Surprisingly, the launch went over smoothly, and I was more than happy to take the credit for a system someone else designed and architected. The real horrors started to creep their ugly heads when the weekend came, accompanied by a store-wide sale that would unleash massive traffic onto this new system I had just inherited. Bound to licensing that limited my use of the underlying software to 1 CPU, the system toppled over faster than a house of cards in a wind tunnel.

For the next week, we monitored the system's performance and were forced to do manual restarts as we worked tirelessly to build a suitable caching system that allowed our systems to breathe. During this time, I was introduced to the famous quote by Werner Vogels.

"...everything fails all the time."

I sat there questioning the life decisions I had made to that point. This quote comforted me, as it does for many people in my field. I knew that Mr. Vogels had once felt that dread I was feeling in those moments and that he was looking at me from his big cloud on the internet.

That horrible experience in my first couple of weeks and this quote developed a deep bias in me that would shape how I architect solutions for clients today. The quote taught me three things: never assume a system is ever bulletproof, AWS really gets me and knows what keeps me up at night, and servers just SUCK!  

AWS Lambdas wouldn't be introduced for another two years, but I would like to imagine Mr. Vogels hearing my nerd prayers and working on a solution to my problems after that day, and from that day on, I accepted my new world view and looked for everything to support it. Mix this with the fact I'm really cheap and like to find ways to save on infrastructure; the past ten years have been an exercise in shedding the shackles of server dependence and embracing the elegance of ephemeral computing. It's been a journey of constant learning, experimentation, and optimization, always seeking the most efficient and cost-effective ways to build and run applications. From the early days of containerization to the serverless revolution, the quest for a truly hands-off, scalable, and resilient architecture has been my guiding star.

From Monoliths to Microservices

I was involved in early talks for a startup in 2010 that would utilize LXC (LinuX Containers) for a new hosting solution. Most of it went over my head at the time because my expertise was still mainly on the front-end JS/CSS of this whole web thing. It wouldn't be for another five years before I became a fanboy.  

When Docker brought containers into the mainstream, I embraced the concept of microservices and containers. It freed me of the pain of Virtual Machines and ushered in an era of modularity and agility, allowing us to break down monolithic applications into smaller, independent services. This newfound freedom empowered us to develop, deploy, and scale individual components with unprecedented ease, fostering a culture of continuous delivery and experimentation. Like a master Lego builder, we could snap together different services, each with its own specific purpose, creating a flexible and adaptable architecture that could evolve alongside our ever-changing business needs.  

Our first project in production utilized containers in AWS Elastic Beanstalk, of all things. As some might imagine, it wasn't the best example of continuous development, but it got the wheels spinning. We built a reusable user management service, a product service system, and a few other services that made us see ourselves as cutting edge engineers. 

Soon after looking in the mirror and seeing the limitations of Beanstalk, the biggest one being the max service limit of ten, we moved our internal services inside Docker Swarm but quickly migrated to AWS Kubernetes because that’s what the cool kids were doing at the time, but also because Swarm kept falling over. We finally landed on AWS Elastic Container Services (ECS) because of its ease of use and lower costs.  

We quickly saw many of the benefits a microservice architecture promised, mainly around decoupled code and fault isolation. However, I still had to hit that proverbial reset button when something broke down. Some services stopped working unexpectedly for whatever reason. My having to adjust the orchestration layer to make sure we have enough computing power and memory was still something in my tasks of things to do. That bothered me, but it wasn't my biggest annoyance.  

The biggest annoyance and most nagging realization that loomed over my head was AWS Cognito! Cognito was a better version of our own user management microservice. Why would anybody spend time building a service like this when AWS is doing it for you WITH HIPPA COMPLIANCE INCLUDED? This nagging realization was that I had spent the time to build something AWS was doing better – not as a microservice, but in the ever growing serverless realm of products.  Some might say there are great teams out there creating open source microservices like KeyCloak that allow you to avoid vendor lock-in while helping with time spent in development, but running these services still cost money and every minute someone isn’t logging in is money down the drain.

Serverless Salvation

While containers and microservices offered a significant leap forward from the monolithic nightmares of the past, that nagging feeling of "servers suck" never entirely dissipated, and AWS kept coming out with services for pennies that required no maintenance from us. The constant need to monitor, manage, and scale infrastructure, even with the help of orchestration tools like ECS, still felt like a burden. Thankfully, the winds of change were blowing, and on the horizon emerged a beacon of hope: serverless computing.

Diving into the Serverless Sea

Serverless, with its promise of "No servers? No problem!" immediately resonated with my inherent server aversion. The idea of focusing solely on writing code and letting the cloud provider handle the underlying infrastructure was like a dream come true. AWS Lambda, the poster child of serverless computing, became our new playground. With each function deployed, I felt a weight lifting off my shoulders. No more worrying about server provisioning, scaling, or patching – just pure, unadulterated coding bliss. And Lambdas are just the beginning.

While serverless functions like AWS Lambda form the core of this architectural style, diving deeper into the serverless world reveals a rich ecosystem of supporting services that truly unlock its potential. Embracing the serverless Kool-Aid means immersing yourself in an event-driven architecture, where services react and respond to events rather than waiting for direct calls. This paradigm shift opens doors to building highly decoupled, scalable, and responsive applications.

Here's a glimpse into the serverless toolbox:

  • Event Sources: These are the triggers that set your serverless functions in motion. They can include cloud storage events (e.g., file uploads to S3), database changes (e.g., DynamoDB updates), HTTP API Gateway requests, and much more.
  • Messaging Services: Tools like Amazon SQS and SNS act as communication channels between different parts of your application. They allow asynchronous message passing, ensuring loose coupling and reliable delivery.
  • Workflow Orchestration: Services like AWS Step Functions help you coordinate complex workflows involving multiple serverless functions and other AWS services. They provide a visual interface for defining state machines and managing the execution flow.
  • Databases: Serverless databases like Amazon DynamoDB offer on-demand scaling and pay-per-use billing, perfectly complementing your serverless functions.
  • API Gateways: Services like Amazon API Gateway act as the front door for your serverless applications, handling API requests, authorization, and traffic management.

This is just a taste of the vast serverless landscape. Each service plays a crucial role in building a robust, event-driven architecture that can adapt to changing demands and deliver exceptional user experiences.

Pros That Made Me a Serverless Convert:

  • Cost Efficiency: My inner cheapskate rejoiced at the pay-per-execution model. No more idle servers burning a hole in my (or our clients') pockets.
  • Operational Nirvana: The shackles of infrastructure management were gone. We could finally focus on what we loved – building awesome applications.
  • Scalability on Autopilot: Traffic spikes? No sweat. Serverless functions scaled seamlessly, handling whatever load was thrown their way.
  • Development Velocity: With less operational overhead, development became a breeze. Time to market shrunk, and innovation flourished.

Challenges on the Serverless Seas

Of course, no technology is without its challenges. Serverless presented a few hurdles to overcome, but we've figured it out:

  • Vendor Lock-in: Embracing AWS Lambda meant tying myself to the AWS ecosystem, which could limit flexibility in the future. However, I saw solutions to all of our needs inside AWS. Not to mention, AWS has been the leader in all things cloud for many years. I have all of the flexibility I need.  Embrace AWS, and feel good about that decision.  What I’ve noticed is that projects that are vendor agnostic, end up getting migrated over to AWS sooner or later.  I never see them going from AWS to Azure or google.
  • Cold Start Quirks: The occasional cold start latency was a minor annoyance but manageable with careful design and optimization. It is entirely acceptable for an API call to take a couple of seconds to load some data when your front-end assets are being served statically from a CDN.
  • Monitoring and Debugging: Gaining visibility into serverless applications required adopting new tools and techniques. We've learned to utilize other services like Kenisis to handle logs at a higher volume.  
  • Limited Control: The serverless environment imposed some constraints, requiring adjustments to certain coding practices. For example, when writing Lambdas, you may use things like layers. We've avoided using this for testing purposes.  
  • Time to Deploy: I've seen teams complain about the time it takes to deploy ( sometimes 45 minutes for larger projects), but we've mitigated this with tools like Nx, which only deploys the logic that has changed.

So What Now?

Throughout this exploration, we've seen how serverless architecture, particularly within the AWS ecosystem, has revolutionized how we build and manage applications. By offloading infrastructure concerns to the cloud, we've unlocked remarkable benefits: cost efficiency that aligns with our "cheapskate" sensibilities, operational ease that allows us to focus on development rather than server babysitting, automatic scaling that effortlessly handles traffic surges, and accelerated development velocity that keeps us at the forefront of innovation.

While acknowledging the existence of challenges like vendor lock-in and occasional cold starts, we've demonstrated that these hurdles are easily surmountable through careful planning and optimization techniques. Our experience has solidified our belief that the advantages of serverless far outweigh any limitations, making it the ideal path forward for building resilient, low-maintenance, and stress-free systems for our clients and ourselves. Although we still utilize microservices via ECS ( Fargate) occasionally, we do this by regularly fusing it with Serverless architecture. 

If you're ready to break free from the shackles of server management and embrace a future of agility and efficiency, Five & Done is here to guide you on your serverless journey. Our expert team has extensive experience designing, implementing, and optimizing serverless architectures within the AWS ecosystem.

Navigating the Mobile Frontier: Journey From React to React Native at Five & Done
Development
5
Min Read.

Navigating the Mobile Frontier: Journey From React to React Native at Five & Done

Stuck building separate web and mobile apps? Five & Done reveals how React Native's single codebase sped up their development and led to a cool AI-powered bedtime story app!

In Case of Inspiration
Thoughts
5
Min Read.

In Case of Inspiration

This article introduces "In Case of Inspiration," a series showcasing the design studio's creative process behind app projects. Each Case Study explores innovative tools and methods to craft delightful user experiences that go beyond functionality. Dive into their unique approach to app design and get inspired by their ever-growing portfolio!

In the early 1940s, Arts & Architecture magazine announced the Case Study House Program. The country was just emerging from World War II and post-war housing was a popular topic with varying thoughts and opinions. Arts & Architecture saw this as an opportunity to develop a point of view and recruited eight renowned architects to study, plan, design, and construct eight houses, each to a specification for a special living problem in the Southern California area.

This program explored how best to utilize new materials and construction methods to design better living solutions (aka houses). Most importantly, no architect was allowed to break the “rules”. Each house was subject to ordinary building conditions and the usual building restrictions. In addition, each house was to be capable of duplication and not a one-off circumstance.

Due to the success of the first eight houses, the program continued through the 1960s to conceptualize and construct nearly 30 homes across the country. These are some of the most sought after and desirable houses still standing today.

Consider what follows to be our studio’s take on a “Case Study App Program”.

In Case of Inspiration is a series of Case Study Projects and stories that provide insight into ideas we believe are better digital experiences and solutions. Every Case Study exists well within the realm of feasibility, while aiming to achieve a new sense of desirability currently absent in existing solutions.

In compiling these Case Study Projects, we aim to demonstrate how we shifted the traditional focus from functional and familiar experiences to refreshing and delightful experiences. Each Case Study will experiment with new tools and methods for building emotionally evocative stories and experiences, while still fulfilling the specifications of unique consumer problems.

You will see how we experiment with AI, flex new web technologies, raise eyebrows with unconventional design, build with budding mobile technologies, bring micro-interactions to life, and so much more.

What follows is a growing list of Case Study Projects. Whether you revel in or revile each of these projects, we’re excited to present you with this ever-expanding body of work.

Case Study Apps

  1. Nella: From AI to ZZZ
  2. Putting The Proof Into The (E-Commerce) Pudding
  3. Build-A-Bronco: Finding The Right Look

…and much more to come!

Is there something you don’t see here, that you wish a Case Study existed for? Would you like to partner with us for a Case Study? Drop us a line at contact@fiveanddone.com.

Nella: From AI to ZZZ
Thoughts
6
Min Read.

Nella: From AI to ZZZ

Tired of reading the same bedtime story over and over? This design studio used AI to create Nella, an app that lets you and your child co-create unique bedtime stories every night!

Welcome back! It’s In Case of Inspiration from Five & Done— a series of Case Study Projects and stories that provide insight into ideas we believe are better digital experiences and solutions. Each Case Study experiments with new tools and methods for building emotionally evocative stories and experiences.

In this Case Study, we’ll introduce you to a brand new product our studio built from the ground up and explore the new “methods and materials” we used along the way.

Let’s jump in.

Never Get Comfortable.

We’ve been in the business long enough to know you’re never done learning and growing. When we say “long enough”, we mean we’ve got designers who harken back to the “good old days of Flash”. From Flash, they evolved through Photoshop, Illustrator, Sketch, Xd, Figma…and now AI?

ChatGPT caused the world to take a collective seat when it launched in April 2023. Some people were amazed, others were stressed, and many had no idea what to think. I’d like to think we fell somewhere between the former and the latter. But like I said, we have experience evolving, and this would be another evolution. The reality is, in our line of work the day you stop learning is the day you stop being relevant.

We’re a design & technology studio, so when AI started smashing rules/boundaries that had existed for years, we didn’t want to sit idly by on the sidelines. We didn’t want to wait for people to tell us, “this is how we’re going to use AI now.” We wanted to have a say in defining that future. Frankly, we were itching to figure out what we could do with it.

New Parents.

Around this same time, we had a bunch of people becoming first-time or second-time parents. ON PURPOSE. Call ’em crazy, call ’em saints, the truth of the matter is that they’re all exhausted.

You know what exhausted people do? They have really good ideas. Something about being uninhibited enough, but lucid enough…

SO, like I said, from that exhaustion struck inspiration — what if I could use AI to help me put my kid to bed?

On the surface, that’s a loaded question. What parent wants to mix Skynet and the meaningful moments of tucking your child in to bed? But taken from another perspective, what parent wants to be come a SuperParent™️? (Hands shoot up across the world.)

So let’s take another look at the question — what if I could use AI to help me put my kid to bed? As most parents know, or will find out, little kids love a good bedtime story to help them fall asleep. And there’s nothing, I repeat nothing, more important than making sure that little human gets their full sleep. Well rested kids > cranky and tired kids is a law as old as time itself.

That became the nugget we set out to explore–how could we help parents with their tired children and familiarize ourselves with AI at the same time?

Three Great Products.

Today, we’re proud to introduce you to three great products. The first is a superb new word game. The second is a fantastic new graphics generator. The third is a fun new collection of short stories.

So, three things:

  1. A superb new word game
  2. A fantastic new graphics generator
  3. A fun new collection of short stories

A word game. A graphics generator. A collection of stories.
A word game. A graphics generator. A collection of stories.

Are you getting it? These are not three separate things. They’re one thing. And we call it Nella.

Nella is the app to create beautiful bedtime stories with your little ones.

With Nella, parent and kid choose the story blocks together, then AI generates the story. For the first time, every story is an adventure for both kids and parents. For the first time, parents get to feel a sense of childlike wonder at where this story will go. It’s not the same story being read over and over anymore (nothing wrong with that, we all have our favorites!); it’s a new story with new lessons, new ideas, and new memories to be made.

Once it became clear to us what we were building, it was just a matter of bringing it to life.

Show (and Tell).

They say a picture is worth a thousand words…so I’m gonna zip it.

At the core of it, Nella builds on the concept that every story has three core pieces: a main character, a setting, and a plot.

Parents (and their little ones) get to select one of each, like a mad libs, and generate their very own, personalized bedtime story. The images barely do the experience justice.

Now, you’ve got an endless library of stories right at your fingertips. You can create countless new stories every night, or stick with your favorite character and create different stories about them. It’s up to you, and it’s never been more fun.

Back To School.

Building Nella was definitely venturing into unknown territory for us. Luckily, unknown territory is our favorite place to explore. It’s how we’ve learned new skills in the past, and it’s how we’ll continue to learn going forward.

If you want something you’ve never had before, you need to do something you’ve never done before.

With many of these newer tools and resources, it’s early days and the maps are still being charted. We jumped in because we wanted to have a hand in staking the path forward.

To create Nella, we built with four new tools: React Native, ChatGPT (AI), Stable Diffusion (AI), and Rive.

React Native…for the mobile application (iOS + Android)

ChatGPT API…for story generation

Stable Diffusion (AI)…for image generation

Rive…for interactive animations

Webflow…for a landing page

It’s Bedtime.

If you’re still with me by the end of this, maybe you’ll download Nella! We’re quite obsessed with how it turned out, but I guess that’s like any parent being biased toward their baby.

Only this time, it’s cool if you want to give us some feedback. We’d love to hear your thoughts.

Otherwise, here are some baby photos of the folks that built this fine app. Don’t you want to download their app and make them feel good?

Download Nella

P.S. — here’s an index to other articles in this series.

  1. Nella: From AI to ZZZ
  2. Putting The Proof Into The (E-Commerce) Pudding
  3. Build-A-Bronco: Finding The Right Look

…and much more to come!

Is there something you don’t see here, that you wish a Case Study existed for? Would you like to partner with us for a Case Study? Drop us a line at contact@fiveanddone.com.