23 Tactical Company Building Lessons, Learned From Scaling Stripe & Notion


Introduction

Some startup operators have a clear lane, an easy-to-follow career progression. SDR to Sales Manager to VP of Sales. SWE to Director of Eng to VP of Engineering. Marketing Manager to CMO. Others have a resume that’s harder to pin down. Take the more elusive “business” folks, often the first non-engineering hires at an early-stage startup. They’re the generalists who can thrive in product, ops, business development, or even dabble in data science or developer advocacy. If you’re an aspiring startup leader who falls in this category, it’s often challenging to chart a broader course for your career.

And it can be just as murky on the other side of the table. From a founder’s perspective, bringing these types of hires aboard marks a new chapter in a startup’s journey. The focus shifts from building the early product, to building the company that builds the product. The org chart starts to fill out. Suddenly, you’re interviewing candidates and managing teams well outside your own functional expertise.

Cristina Cordova is well-positioned to share advice for both camps. As a repeat early startup employee, she describes her career as being “somewhere in between business and product.” That’s because while she cemented her expertise in business development and partnerships, she’s also been a product marketer in a pinch, managed teams of engineers, led DEI initiatives, and hired everyone from growth PMs to developer advocates. Cordova’s also a seasoned angel investor, and after backing over 50 startups, she’s helped founders work through every thorny challenge of company building. 

What makes that advice particularly valuable is the fact that she’s been at a collection of standout tech companies, developing deep wells of experience in SaaS, fintech, and the developer tools space. She started her career as the very first employee at Pulse (which went on to be acquired by LinkedIn), honing her deal-making and distribution chops. After joining as Stripe’s 28th employee, Cordova spent the next seven years at the payments juggernaut, building out the partnerships function from scratch and heading up a new business unit to take products like Corporate Card and Treasury from 0 to 1. In 2020, she returned to her early-stage roots and joined Notion as Head of Platform & Partnerships, launching the company’s long-awaited API and building out the self-serve growth team. 

But selfishly, we’re most excited for Cordova’s next chapter: joining us as a Partner here at First Round to back early-stage founders full-time. While we’re brimming with excitement to add her to the team — you can read more about that over here — on The Review, we’re focused on open-sourcing the hard-won advice that she’ll be sharing with company builders. 

What follows is a collection of her lessons on building and scaling a startup. Whether you’re a founder trying to figure out growth and assemble your team, or an operator hoping to architect a high-impact career, Cordova has been in your shoes very recently. From advice for leveling up your negotiation skills and API documentation, to guidance on getting layering right and hiring for roles you’ve never personally held, she shares tons of practical pointers that are worth bookmarking for later. 

TAKING CHARGE OF YOUR STARTUP CAREER:

#1: Challenge yourself to get more “technical.”

One of Cordova’s strengths is her ability to bridge the business and the technical. “Early on in my career, I disliked the distinction. There’s this wall up between the two. I loved being that person in a room where other people would say, ‘Wait, what team are you on again?’” she says.

This quality is particularly important for business development. “There can be an intimidation factor. But as a non-technical person working on a product, you should be able to read and understand the API docs, even though there’s a temptation to think, ‘Oh, that’s not meant for me.’ To get over this initial blocker, I often reminded myself that while an engineer on the team has strengths in certain areas, I also have strengths in other areas, and there’s nothing that either of us have that’s fundamentally unlearnable,” says Cordova. 

“At the first startup I worked for, we didn’t have a data scientist yet. So eventually I had someone teach me how to use SQL so I could start pulling my own data and running cohort analysis. And slowly I became the person who would update everyone on how our cohorts were performing,” she says. “Patrick and John Collison were particularly great at encouraging this. There were people at Stripe who started working in support or sales, and then later became full-fledged engineers at the company.”

Another helpful trick is to focus less on worrying about your own skill-set, and more on being helpful. “In a classic, people-pleasing way, when I started at Stripe I was looking for ways to make engineers’ lives better. And when it was clear that an engineer didn’t want to be in their 10th partnership meeting, I thought I could try to learn some of these things for myself so they wouldn’t have to come,” she says. “It was as simple as saying, ‘I know we’ve been having a lot of these meetings. Can we sit down at lunch one day? You can whiteboard this out for me so I can better understand the underlying architecture.’”

If you’re the first business hire at a startup, you can’t be afraid to get into the technical weeds. How can you shield the product and engineering teams from the more painful elements of deal work, or reduce their customer meeting load?

“Then on my own time I would practice communicating the details at different levels of technical depth, whether it was getting into it with a technical person, or giving an overview to a business person and making sure they really understood it.” Here’s her advice for the latter:

Cater to their POV. Try to understand what their function is and what they’re likely to care about in relation to the technical topic at hand. “For example, when pitching new APIs to a finance person, I’d focus on where the funds are flowing, which is what they’d likely care about.”

Incorporate different techniques. “Maybe you can map the flow of funds out on a slide. Or tell a story, like: ‘When the Uber rider requests a ride, we’ll make an API call to ensure their card works on our side, then when the ride is finished, we’ll make an API call to charge the card.’ The person I’m explaining this to may have no idea what an API call is, but taking them through the journey helps them understand the broad strokes.”

Old tweet from Cristina that describes how she was terrified to commit code to Stripe's team page for the first time.

#2: Pick your head up to observe (and steal from) others. 

“As is the case with many women in tech, I didn’t really have a lot of great mentorship in my career. I had some incredible managers, but mentors fill a different role, giving you that wider-angle lens outside of your specific function and company. And I always felt too intimidated to reach out to someone and say, ‘Hey, can I get 30 minutes of your time?’ That’s a big reason why I started doing career chat sessions for folks who are at an inflection point,” says Cordova. 

“But being at a fast-growing startup like Stripe, I learned a lot by just observing other people. I studied how company leaders I respected operated, stealing the tactics that I liked.”

Your manager might be too busy to directly help you with skill-building, but there’s real power in informally observing others in the org. If you want to learn as much as possible at a startup, you have to be proactive about your own growth. 

This can apply outside of the building, too. “I was very early in my career — six months fresh out of school — and our startup was so small we didn’t have a PM. There was a woman in a senior product role at the BBC who sent me a super organized follow-up email. I still have it, not because there’s anything earth-shattering in there, but because I stole it and started using it as a template for future partnerships.”

An old email (with blue, Times New Roman font) that outlines next steps for moving a partnership forward.

#3: Ask these questions before joining a startup.

“As I’ve been doing these career chats with folks, the top question is always: ‘Where should I go next?’ Especially in today’s market — there are so many opportunities that it can be a bit paralyzing. But the company that you select matters far more than any other factor, whether it’s title, scope of role, or salary,” says Cordova. “While VCs and angel investors can place multiple bets in a short period of time and hope one pays off, employees get just one bet.”

Spend the vast majority of your time figuring out whether this is the right company for you to join above all else.

Here’s how Cordova placed her bets: “I optimized for companies that had big or growing markets, like payments and e-commerce at Stripe. I also tried to get a sense of how the product was doing if it had launched. For example, looking at discussion of Stripe in HackerNews threads gave me confidence because it clearly resonated with developers,” she says. 

But in her experience of both investing in and joining startups, Cordova tends to focus most on the founding team. “A lot of things can change with the business or in the market, but the founders usually stick around. I’ve learned not to do too much pattern matching here. Ivan from Notion and Patrick from Stripe were very different, and yet both very successful,” she says. 

To dig in further, ask these questions of yourself as you’re interviewing with folks on the founding team:

Are the founders well-suited to build a product in this market? Are they the customer, or do they know the customer well?

Do they have passion that can be sustainable for decades?The story of how the Notion founders had to completely start over in 2015 is an example of that grit,” says Cordova. “And when I first met Patrick and John Collison, I had zero context on the problem they were trying to solve at Stripe, but I was fired up by them being fired up.”

How good are they at telling the company’s story? “Pay attention to how they’re positioning the opportunity when you’re interviewing.”

Do they care beyond the product? “Many early-stage founders focus just on building a product that people like, which is perfectly fine. But when I was interviewing at Stripe, I saw how they were already thinking about all of the elements that go into building a generational company, from hiring to retention to culture.”

Are they glossing over the challenges? “In interviews, I like to ask, ‘What area of the business would you say this company is behind on, given its stage? This can highlight surprising areas where you may have to fill in cross-functionally.”

Do I trust the founders to do the right thing if this goes badly? “Will they treat employees right if there are layoffs? Or only a subset of the team gets acquired?” 

Is this someone I think I can learn from? (Even if this person is in a completely different function?) 

Do I feel like the smartest person in the room when I’m with this team? (The answer shouldn’t be yes.)

#4: Be a gap filler.

Elad Gil talks about ‘gap fillers’ and I’ve always thought it’s the perfect phrase. Stripe was growing so fast that we needed people to plug holes in the organization. It’s essential to grow with the company — rather than having the company grow around you.” Cordova shares two observations here:

Don’t just look for the helpers — become one. “It’s very easy to fall into a mindset where you’re criticizing all the things that aren’t going well — it’s much harder to come up with a proposal for making things better. Are you constantly looking around to find new ways that you could help the people around you? Instead of being super frustrated by how busy your manager is these days, is there something you could do to help them get more leverage?”

Sign up for side gigs. “My core focus was on partnerships, but I always had responsibilities on top of that. At one point an engineering manager left, so I took over managing the team. I also led DEI initiatives for over a year before we made a full-time hire,” says Cordova. “These opportunities allowed me to build a reputation for myself and gave me more exposure to other functions for my own development. Promotions often require work that has cross-org impact, which these kinds of projects can help with. Eventually, as the company kept growing, I got the chance to head up a new business unit.”

Sign up for the “side jobs” of standing up new teams, helping to start new functions, or leading a company initiative. It was the projects I worked on outside of my day-to-day work that gave me the biggest opportunities.

STAYING FOCUSED ON CUSTOMERS WHEN TAKING A PRODUCT FROM 0 TO 1:

#5: If you add something on, take something off.

You’ve set your plans for the next six months — and then another company in a similar space launches something new. Or a big prospect gets in touch, but is demanding a major new feature. What do you do?

“There are two types of mistakes that can be made. One is when the plan completely goes out the window. The team pivots to work on the shiny new thing, and you end up going into an area that’s maybe not worth it. The second type is ignoring it, rigidly sticking to the plan and refusing to take on ‘custom work.’ Classically, the best is somewhere in between the two,” says Cordova.

Photo of Cristina Cordova in a black jacket against a white background with olive branches.

Here’s how to split the difference: “I love a good stack rank — if teams actually adhere to it. Get everyone together and say, ‘Here are the 10 things we’re working on this quarter and here’s the impact of each one if we don’t get it done,’” she says. “When a request comes in, if you decide to work on it, #10 on your stack rank has to come off. Or if it’s a much bigger new product initiative, then the bottom three have to come off. There’s a big difference between ‘Our most important customer is demanding this feature and threatening to leave if we don’t do this,’ and ‘A customer in the middle of our list is suggesting a nice-to-have capability.’ Religiously sticking to your stack ranking will help you sort through it.”

So many people delude themselves when they think they can just slot a new project on top of everything the team’s already doing. You have to put in the work to figure out if that shiny new object is worth throwing off the roadmap for.

If you’re looking to start a similar practice with your team, here’s Cordova’s lightweight template (built in Notion, of course).

#6: Cultivate a creative streak for serving customers.

“Patrick and John Collison always had a maniacal focus on customers. They taught me to always place a super high value on every facet of the customer experience. It built amazing brand loyalty,” she says. 

“Stripe sent out thank-you cards to our earliest customers. This eventually shifted to celebrating our customers when they hit their own milestones, such as sending them a nice gift when they hit $1M in ARR. Or when one of our customers had a huge outage, we’d send their team cupcakes to commiserate.”

#7: Go through your own flows — then go through them again.

“At both Stripe and Notion, many of the most successful growth projects involved going through the user experience and putting yourself in the shoes of a first-time customer. It sounds very simple, but you’d be surprised how many organizations don’t regularly do that,” she says. “At Notion, I signed up for a fresh account even though I’d been using the product for years. I went through and clicked every button, writing down every little thing that may annoy users.”

Here’s an example of an annoyance that had an impact: “Right before you finish setting up your account, we’d ask you to invite teammates to your Notion workspace. And as you started entering emails, it was unclear — do you put a comma after one email and then add another? It was such a small detail, but the user interface was poor,” she says. “We changed it so that adding groups of people was more intuitive. That enabled us to 9X the number of people who invited someone else in.”

So much of growth is perfecting onboarding. Even if you built your onboarding flow only six months ago, go through it again. You’ll still have bugs. 

#8: Self-serve ≠ set it and forget it

As you’re setting up a self-serve flow, proactively think about the high-value customers that you want to reach out to, even if they come in through the product. “There are a bunch of tools that can notify your entire sales team in Slack if someone with a top 1000 domain signs up for your product, for example. That way someone can reach out for a discovery conversation, or pull them out for a more white-glove type of onboarding experience.”

#9: Don’t fall into the signups trap. 

The rule above applies especially for your first launch. “You’re going to have a lot of high-value sign-ups that first day, and you need to prepare your team to follow up with those customers. Too many startups don’t track how many of those customers actually stick around,” she says.

“Stripe’s metric for a fully onboarded customer was receiving three payments from different customers into your account. At Notion, it was inviting at least two other people to your account and putting a certain amount of content in there. Growth is about focusing on engagement, not just getting more people through the door.”

A big mistake early-stage companies make around launch is focusing too much on sign-ups. It’s great to have 10,000 sign-ups in one day — but are they paying you? Are they actively using your product? Are they adopting new features? Those are the things that you really need to care about. 

BUILDING PARTNERSHIPS AND WINNING DEALS:

#10: Pause. You might not even need partnerships.

“Partnerships don’t make sense for most companies at the super early stages — which may sound funny coming from a person who did exactly that for a number of years,” says Cordova. “But it can truly become a big waste of time, and it’s a huge mistake to hire for it too early.” Here are a few reasons why:

They can change the company trajectory — in a bad way. “If you put half your engineering team on getting a partnership out the door, you might be abandoning critical work to find product/market fit,” says Cordova. “Or say you’re working with an early partner and they end up becoming 50% of your business. That’s driving a lot of value, but it can be very dangerous if you fail to develop a great core business. And if you lose that pivotal partnership, it can be a terrible signal.”

Partnerships might be an experiment that doesn’t pan out. “Stripe hired me at the perfect time. They had done two or three partnerships, so they had some data and the strategy was starting to look successful,” says Cordova. “But as is the case with many things in startups, partnerships can become this experiment you explore for a bit, only to find there’s not a there there.” 

You might just need APIs. “A lot of partnerships at the early stages don’t have a strategic shape. It can be as simple as participating in an open development program, or using open APIs from other companies. If you’re not getting into complex terms, tough negotiations, or first-in-kind deals, then it’s hard to justify a business hire.”

I’ve always believed that your best BD person is a well-documented API.

Worlds collided when Cordova joined Notion and was sent her corporate card — a product she’d led at Stripe.

#11: Share your specs mid-flight.

Speaking of APIs, Cordova often works closely with founders as they craft their strategy and timing here. “There was all this pent-up demand for what we launched at Notion. Some startups do this too early, and if the customers aren’t there, you don’t really know where to start from a product perspective. Just because you build out your APIs doesn’t mean that someone’s going to use it on the other side,” she says.

To get more clarity, write out the documentation, and share it with developers beforehand to get more feedback. “At Notion, we created an API spec that showed what it was going to look like before we started building it, and shared that with a number of interested users and partners to get feedback. That helped us see a lot of holes,” she says. “Digging into the details, we realized that we didn’t actually have the API endpoint they needed, or that tasks like searching across thousands of files would be difficult without more functionality or tooling.”

#12: Start at the middle — not at the top — of your target list.

It’s natural to set your sights on the opportunities that would reap the biggest rewards, but that’s a mistake. “Don’t start with the most important partners that you could potentially work with, but at the fourth or fifth down on your list. That way you can learn exactly what the objections from a big partner might be and start solving them. If you pitch that big company five or six months from now, you’ll be in a much stronger position.” 

It’s better to build your case with smaller players for several months than to crash and burn with the most prominent potential partner because you’re eager to ink your first deal.

#13: Focus on the 80/20 in negotiations.

Most founders don’t have a ton of experience negotiating terms. “There are two traps here: You either get bogged down in the details and drag out the timeline of a deal, or you cave too quickly to get it done, giving in on some important terms that you’ll regret later,” she says.

Cordova shares her best tips for heading into negotiations:

Build a framework of principles. “Outside of an individual deal, step back to think about the things that your company cares about. What are you not going to give in on in any negotiation? For example, with distribution deals at Stripe, we tended to not want to be exclusive with partners. We’d work with Shopify and Squarespace,’” she says. “Or how even if it was at a slim margin, we had to do deals that were profitable.” For a specific deal, outline the top five things that matter — ideally you’ll get at least four of those.

Look for a win-win. “Many feel that negotiations pit your company against another and that a successful negotiation is one where your company comes out on top. Billy Alvarado, Stripe’s Chief Business Officer, taught me that your most successful partnerships are the ones where both companies win together. It helped that Stripe’s economic model was built off of us taking a small slice of the economics, so accelerating our partners’ success enabled us to win too.”

Minimize the risk of egregious terms. “Take something like a five-year term on a partnership when your startup has only existed for six months. That’s a little crazy, unless you’re getting tons of value out of it. You could counter with something like, ‘Well, I’m happy to sign up for this five-year deal if it means you give us X amount of revenue every year,’ or ‘If that means Y amount of customers are being brought in,’ with the ability to wind down the deal if that doesn’t happen.”

The goal isn’t to just release a press release that says your startup and this big company are working together. A partnership really does have to work at the end of the day.

MAINTAINING CULTURE AND DEALING WITH SCALING:

#14: Pair first principles with advice seeking.

The question of when to build and when to borrow best practices is one every founder faces. “Stripe was very much founded on first principles and thinking about company building from the ground up,” says Cordova. “There’s a strain of thinking in startups that can get very inward-focused, rejecting any ‘BigCo’ ideas. But at Stripe, that first principles thinking was also coupled with a lot of advice-seeking. We did tons of reaching out to other founders and executives to pull in their insights.

She shares a specific example: “We were doing company planning for the first time and Patrick set me on a little mission to go talk to other companies and figure out how they do it. So I chatted with a Google exec, an Amazon exec working on AWS, and Mike Vernal, who was a VP at Facebook previously. Stripe would take elements that we liked from leading companies that had done this before, and then blend that with a more ‘Stripe-y’ approach,” she says.

“We liked Amazon’s ‘working backwards’ approach of writing a press release early on when building new products. Our first riff on that was including ‘User Ships’ in each team’s product plan, effectively forcing ourselves to outline what value we were going to deliver to the user that quarter. It was very similar to what Amazon did, but applied to smaller features and not just big bets.”

Photo of Cristina Cordova on a taupe, textured background, looking away.

#15: Beware of the dangers of waiting too long to add a function.

For any startups currently studying Stripe’s playbook, Cordova points to another contrarian move to be careful of copy-pasting. “I hear so many small startups say, ‘Well, Stripe didn’t have PMs until they had hundreds of employees, so we’re thinking we’ll do the same.’ That was not the ‘secret to our success.’ Don’t mistake not having a function (product management) for not having a role (PM) played by a team member,” she says. 

“Many folks wore the PM hat in the early days of Stripe without the company having a dedicated function. This worked because it was a developer product built by developers — but it may not necessarily work for you, in your market, at this point in time. When Stripe’s customer base grew and we needed to build for accountants, customer support and other teams using the product, we hired PMs.”

Furthermore, if you had reached out to someone at Stripe to share how that practice went over internally, you might have gotten some interesting perspectives. “Functions have reputations within a company. And sometimes waiting too long to hire can create difficulties for when that function eventually does come on board. Waiting to build a product management org caused some at Stripe to wonder why we needed them, or to have a certain impression of what PMs would do when they came in. It sparked ‘hold onto your Legos’ type fears that made it more challenging for those first hires to do their jobs effectively.”

When adding a new team or role, take the time to clarify a few things: What a role is, what it’s meant to serve, how existing people have been making up for the lack of that role, and how their lives are going to be changed by new people coming in — in positive and potentially negative ways.

#16: As an employee, getting layered sucks. But you can reframe it.

“So many early-career startup employees are afraid of getting layered with a more senior leader hired above them. I felt the same way when it happened to me. It took me a while to understand it from the founder’s perspective,” says Cordova.

This decision to layer you has little to do with how well you’re performing as an individual. It has everything to do with how well the business is performing. If a startup founder can attract and hire someone with more experience to help grow the business, they will.

If you’re in the midst of a similar situation, here’s her advice: “Turn this into an opportunity to help the company find a new leader and future manager who you believe you can learn from. The only thing worse than getting layered is getting layered with a terrible manager.”

#17: As a founder, get transparent about layering.

Of course, that’s only possible if the founder opens up a discussion around layering to involve the team. “Most companies layer terribly. So many times founders just are like, ‘Oh, by the way, we just hired a head of marketing.’ And the employee’s reaction is often, ‘I had no idea you were even looking for anyone,’” says Cordova. 

“Instead, tell the team, ‘Here’s what I think we’re looking for. Would love to get your thoughts on whether you think we’re ready for this person. What do you want to learn from someone who could come on in this role? What are the things you want to keep doing? What are the things you want to give up?’” she says. 

BUILDING TEAMS:

#18: Stand out in recruiting by getting into the financials.

“When I was making my first few hires for partnerships, it was a struggle. I wasn’t an experienced manager, and Stripe wasn’t a super hot company yet. The team was mostly engineers, and BD folks can be a bit wary of that. And I couldn’t give anyone a title because I didn’t even have a title.” (More of her thoughts on that subject here.)

Cordova found that spending time walking candidates through equity made a difference. “Not many companies do this, and very few startup employees have a deep understanding of it. I had a whole spreadsheet that laid out assumptions like, what if Stripe’s value stayed the same, doubled, or quadrupled — how would that affect your equity?” she says. 

If you’re a founder facing similar hiring challenges, there are other ways to emphasize that you truly care about the financial outcomes of employees. “Offer the ability to early exercise stock. Extend the option window to exercise to 10 years. And if you sell equity in secondary rounds, offer the same opportunity to tenured employees.” 

#19: Try to see “no” as “not right now.”

Greg Brockman taught me a lot about ‘long recruiting,’” says Cordova. She first learned this lesson from the current OpenAI (and former Stripe) CTO when she herself was being recruited. “They tried to recruit me several times and just kept spending time with me until I joined a few months later.”

After joining Stripe, Cordova took this lesson to heart. “I started to take the same approach with potential recruits. Candidates I rejected ended up going on to refer folks who I eventually hired. I remember Rishi Sachdeva turned me down midway through, but eventually came back around and joined my team. I always take a no as ‘not now’ thanks to Greg.”

Photo of Cristina Cordova, against green plant background

#20: If you’re hiring for a role you’ve never held, try to get your hands dirty.

“Especially after a funding round, when your company is about to go into hiring mode, it’s easy to default to hiring people for all the things that you personally don’t want to do. But you learn most when you try to do things for yourself,” she says.

Take hiring your first marketer. “As a founder, if you haven’t tried to figure out whether you need developer marketing, performance marketing or channel marketing, your chances of hiring the wrong person for the role go up exponentially.” 

But a DIY approach isn’t always feasible. “My first hire at Notion was for a developer advocate with a very technical engineering background to help empower other organizations to build to our API. So I reached out to an amazing developer advocate I knew from Stripe who wasn’t on the market.” Here’s what to ask folks who are too established or unpoachable:

What’s the kind of role that would attract you to work here?

What are the things that would be most critical for you?

Who are the five most amazing developer advocates that you’ve ever worked with?

“Then I reached out to every one of those people and had the exact same conversation,” says Cordova. “That’s where I picked up tidbits, like that many folks think Netlify has an awesome team.”

#21: If you’re taking over a team in a different function, don’t pretend to be an expert.

Another common scenario is when a key leader departs unexpectedly and you have to fill in for the interregnum. “There’s often a credibility issue to overcome. It’s important to be clear about how you can help — and how you can’t,” she says.

“When I first started managing engineers, I thought I was going to be terribly out of my depth. In an early conversation with an engineer, I shared that if he wanted to have a discussion about a certain element of API design, I just might not be the best person, but I would find the right person to give him advice,” Cordova says. “He let me know he had never had discussions with his former manager about that kind of stuff, and relied more on his peers for technical feedback.”

So many of the problems that teams have — communication, organization, strategy — are unrelated to the function.

In fact, it’s helpful to think explicitly outside a team’s expertise. “The best engineers often want to have business impact, so my business background was an asset for giving them more specific feedback and identifying opportunities for growth there.”

#22: Make this list before bringing on an opportunistic hire.

When a company starts growing in valuation and getting more press, inbound candidates begin rolling in. “When someone incredibly talented reaches out, you’re tempted to snap them up. But think about who would be complementary to the team you have,” says Cordova.

“I’ve seen this time and time again: You already have a fantastic product marketer, but then a head of marketing candidate comes along. Their specialty is also product marketing, but what you actually need is demand gen. So now you’re still not covering a gap and you risk undermining the team that’s already there.”

Take a step back and think outside of this candidate. “Write down the skill-sets you already have on the team, as well as the skills that are lacking. Then go back to the opportunistic candidate and ask yourself — does that person actually fit in my bullet point list? Or am I just trying to fit this square peg into a round hole?

#23: Remember that building a big team isn’t the ultimate goal.

“The advice to give away your Legos is so popular for a reason. It’s a hard feeling to get used to individually. But I’ve also found the concept useful at the broader team or functional level. Some teams like engineering or sales are supposed to reach incredible scale as the company grows. But a partnerships team is very different,” says Cordova.

“There’s a lot of nuance and complexity that goes into first-in-kind deals, like a distribution partnership with Shopify. But deals can become pretty repeatable and more off-the-shelf,” she says. “And even though that type of work produced billions of dollars in payments processing revenue for Stripe, it wasn’t really BD anymore, it was more akin to sales. So it made sense to move that work to a team that had expertise and scale to do repeatable deals.”

But that puts a ceiling on the BD team — something startup leaders may naturally bristle at. “You can see all these other functions growing quickly around you, and it can feel as though your team is getting swallowed up. As a leader, you may be tempted to hang onto that headcount, revenue and recognition,” she says.

“Changing your mindset to, ‘Well, now I’m looking for different opportunities that can alter the trajectory of a 1000-person company, instead of the work I was doing for a 30-person startup.’ It forces you to think bigger and stay strategic.”

You can’t be a hoarder of power within an organization. Once you get to a point where you feel like something is ready for lots of scale, get comfortable with letting it go so you can move on to the next building challenge.

Photography by Bonnie Rae Mills.

from First Round Review https://review.firstround.com/23-tactical-company-building-lessons-learned-from-scaling-stripe-and-notion

Snap Unlocks Landmarkers for Planet-Scale AR



As we’ve covered in our Space Race series (and corresponding AWE presentation), one of AR’s opportunities is to augment the world in geographically-specific ways. Place-based relevance is a key value driver in everything from search to social media. The same will apply to AR.

In fact, this principle may apply even more to AR than other technologies, given that its inherent promise is to digitally enhance the physical world. Points of interest and businesses are a key part of that formula, similar to the value that drives real estate (location, location location).

Meanwhile, several tech giants are basing their AR road maps on this principle – from Google’s visual search and AR navigation products to Niantic’s “real-world metaverse” ambitions. Also on that list is Snap, whose Landmarkers, Local Lenses and Snap Map breed location-relevance.

Today, Snap takes the next step in that evolutionary path with Custom Landmarkers. This puts tools in AR creators’ hands (Snap’s M.O.) to DIY their own Landmarkers. It builds on the 30+ Landmarkers Snap has created, scaling the program to the extent of the inhabitable earth.

The AR Space Race, Part IV: Snap

Digitally Anchored

Going deeper on Custom Landmarkers, they’re being delivered today as a centerpiece of the latest update to Snap’s Lens Studio. This will involve a framework for Snap lens creators to scan a given location, then create a lens that is endemic to that place and digitally anchored to it.

The scanning happens for a few reasons. It helps developers create lenses that integrate contextually and dimensionally with a given place. it can also serve as a trigger for subsequent lens activations. Once scanned, Snap can recognize that place and its associated lenses.

As background, this is a key concept of the AR cloud – a mesh of geo-anchored data that lets AR devices evoke the right content when and where relevant. But because it’s still an advanced concept, Snap is offering Snapcodes that creators can use to activate a Landmarker on-site.

Both approaches are important, Snap’s head of platform partnerships Sophia Dominguez tells AR Insider. While Snap is building out its own AR cloud for Landmarkers, Snapcodes provide a bridge that’s familiar to users. This bridge is analogous to the smartphone’s bridge to AR glasses.

Boiling this down to a practical example, a theme park can create Landmarkers all around their grounds and plant Snapcodes accordingly. These can both launch the intended lens and serve as a sort of nudge for users to pull out their phones and fire up Snap to see something cool.

Will the AR Cloud Underpin a “Real-World Metaverse?”

Statues to Storefronts

Speaking of potential use cases, one of the points in unlocking Landmarker development according to Dominguez is to crowdsource the discovery of new experiences. Again, this is aligned with Snap’s broader lens playbook which has vaulted it to 6 billion+ daily lens plays.

And like the broader lens universe, the results will be both practical and whimsical. BLNK founder and creative director Michael Nicoll tells us he’s been working with Custom Landmarkers to create geo-anchored artistic fare around LA – think virtual street art with an interactive kick.

But Nicoll’s goal is to bring this flavor of lenses to his entertainment clients. There, it can open up a new dimension to any marketing mix. This could include everything from consumer brands to recording artists, to lens activations at venues like Staples Center Crypto.com Arena.

It also brings to mind multi-location brands – the Subways and Chic-fil-As of the world. As it goes with martech, brands jump in before the long-tail SMB segment. But the latter could be where the scale is, letting SMBs spotlight their unique personas through storefront-anchored Landmarkers.

And the timing could be right given the advertising world’s flux. The combination of a pandemic and privacy reform (e.g. Apple’s ATT) has forced advertisers to get smart on new alternatives. AR – and Custom Landmarkers as a subset – could be propelled by those tailwinds.

More from AR Insider…

from AR Insider https://arinsider.co/2022/03/16/snap-unlocks-landmarkers-for-planet-scale-ar/

The Future of ‘Banking as a Service’


Subscribe to The Financial Brand via email for FREE!

The “banking as a service” strategy has quickly moved from a quirky niche play to a “golden opportunity” for a much larger group of players on both sides. There are several reasons for this shift.

Banks that have adopted “BaaS” in some fashion experience above-market returns on equity, in part because they are making much more efficient use of their technology stacks, according to Andreessen Horowitz. This is making BaaS more attractive to traditional institutions seeking greater profitability, especially community banks, that have been hit by troubles in the commercial real estate market.

“Commercial real estate is one of the great casualties of Covid, and commercial real estate has been where many community banks have made their bread and butter,” says Konrad Alt, Partner at Klaros Group. “A lot of community banks out there right now are needing to think harder about their strategy. As they look around for options, banking as a service is interesting and attractive. And they can see other community banks tiptoeing into the area. So, they are thinking, they can do it too.”

Ron Shevlin, Chief Research Officer at Cornerstone Advisors, says BaaS represents a $25-$50 million revenue opportunity these days.

The timing looks opportune because interest in BaaS and in the closely related concept of embedded banking is growing. This has increasingly brought in additional third parties interested in playing matchmaker and enabler between banks, which have the entrée to mainstream payment rails and all the other perks of bank charters, and fintechs and other companies that have innovative ideas but which lack the keys to the banking kingdom.

Bring On More BaaS Competitors, Says One Pioneer

You might think that a bank that has already established itself in BaaS might just as soon potential fresh entrants — competitors for deals, after all — would try something else. But Eric Sprink, President and CEO at Coastal Community Bank, which is a very active player in BaaS, says he favors more BaaS institutions.

“More banks in the banking as a service arena is healthy,” says Sprink. First, he says there are more than enough fintechs around who need bank partners to bring their ideas to market. Second, having more banks doing this “raises the education level of the entire ecosystem. Regulators will become more familiar with it. Trade associations will become more familiar with it.”

Banks active in BaaS already fall into two main groups. One consists of companies whose main business is banking as a service, including Cross River Bank, Bancorp Bank, Green Dot, and Meta. In some ways, they are really banks for fintechs, according to Sprink. The other group consists of active BaaS players that also maintain robust community banking operations, including branch networks.

The landscape for fintechs, banks and BaaS is changing and the decision to enter this activity from scratch cannot be taken lightly by either side, fintech and nonbank companies on one side and banks on the other.

The Field of BaaS Clients Is Expanding

As Konrad Alt likes to say, the classic BaaS user has been “two guys in a garage” who had an innovative financial idea in mind but who needed a banking partner. Typically they needed not only access to the banking system, but help with the byzantine world of compliance and other factors that banks have long since been initiated into. (Who knew that someday compliance would be cool?)

Other types of users have begun to explore BaaS relationships. Sprink says Coastal Community Bank has a partner that is a national consumer brand that is working with his institution to explore launching a buy now, pay later service of its own. Still a work in progress, this could be part of a “BNPL 2.0,” Sprink suggests.

Dov Marmor, COO for North America at Railsbank, says that retailers with enthusiastic fan bases are a natural customer for BaaS because they seek financial infrastructure to support new forms of commerce. For example, the ability of a sneaker store to provide financing from a salesperson’s tablet, or even to give away a pair in exchange for a signup, has strong appeal. In a report Deloitte Digital suggests that financial institutions enabling cashier-less shopping — akin to the Amazon Go stores — could become a ubiquitous application of BaaS as it becomes more the norm.

“You’re going to have more brands get into financial services and one way to do that is to partner with banks. Fintechs were the first big wave. But I think the next wave will be different. It will be companies with large, loyal followings that want to sell financial products to their customers.”

— Eric Sprink, Coastal Community Bank

In a way, the 2019 deal creating the “T-Mobile Money” account between T-Mobile and Bank Mobile was a forerunner of the trend.

Accompanying these broader trends is the commercialization of the growing fragmentation of American society. “The fractionalization of the larger community into affinity groups, or ‘community banking’ groups, for want of a better term, is very real,” says Peter Hazlehurst, Co-Founder and CEO at Synctera. His firm has some deals in the works that are highly specific, yet the sheer size of the American market makes them appear viable.

The New Middlemen

In just the last year or so, there has been a new wrinkle in BaaS. Traditionally BaaS arrangements were direct arrangements between the financial institution and the fintechs that needed them. However, as more players want to offer BaaS and more types of companies want to obtain some version of it, a new breed of middlemen, or matchmakers, have come to the fore.

“I call them ‘connectors,’ because that’s what the Federal Reserve calls them,” says Sprink. These are companies like Synctera, Treasury Prime, Synapse, Rize, and Nymbus that “curate” banking providers, help enable connections to partners, and connect the fintech and nonbank partners with some of the BaaS banks. (Sprink notes that Coastal Community owns a piece of Synctera.)

When Nymbus entered the BaaS fray in late 2021, it offered assistance with strategy, program management, operations, call center service, accounting, and compliance.

Sprink sees this “connector” movement driving increasing entry into BaaS by traditional players, by simplifying aspects of partnerships through the third party participation.

Need to Consider the BaaS Risks

The advent of the connector concept and its role in the future in helping banks and nonbanks find the right partners leads to a broader concern: Are BaaS enthusiasts on both sides looking under the hood enough?

Konrad Alt says that the views of regulators must be considered, and he believes that they will be taking a closer look at how well banks getting into BaaS are controlling the potential strategic risks of these arrangements.

He also points out some fintechs haven’t delivered on promises to “do great things for consumers,” says Alt, and some of those which have entered the lending business tend to charge very high rates.

“So you’ve got a portion of the public policy establishment that is very concerned about whether these companies are doing right by consumers,” says Alt. This makes for at least a yellow light as the Consumer Financial Protection Bureau shows increasing activism and other regulatory developments under the Biden administration follow this trend.

Profit Has A Price:

For any community bank launching into BaaS, a key matter is that they are taking on significant risk management responsibility for their nonbank partners, and not all newcomers seem to appreciate this.

Both banks offering BaaS and companies taking advantage of it must look at the full picture of what they are getting into. Alt sees issues that both sides must weigh.

“They need to be prepared to invest in and grow a really talented risk team,” beyond the team handling their own needs, says Alt, a former federal regulator who has worked in banking. (The latter includes time as Chief Banking Officer at Green Dot Corp.)

Another risk BaaS providers face can face is concentration and lack of diversity in their client portfolio, says Alt. “A community bank may be successful in getting a fintech partner that’s generating a bunch of earnings for them,” he explains. “But the bank is in kind of a precarious position unless it has several partnerships. Fintechs can move on to different partnerships if they want to and you don’t want to have too much revenue concentrated in a single partner.”

There’s a risk in success, too, according to Alt.

A fintech partner that goes from “two guys in a garage” to something really big can dwarf its community bank partner, potentially. This can be just as much a risk for the nonbank partner, should something happen to their banking system entrée. A regulatory order or worse can put a critical relationship in jeopardy, notes Alt, and BaaS arrangements can’t be unwound overnight.

For the nonbank partners, he adds, the opaque nature of the regulatory relationship can be a risk as well. Mandatory confidentiality regarding examinations, ratings and more mean that nonbanks don’t have the full picture. At least one major neobank has multiple BaaS providers and such redundancy could become standard at some point.

With risks for players on both sides, Alt believes there will be more regulatory attention to BaaS. This could possibly lead to a public example being made of some deal where the BaaS provider and their partner “are not on top of those risks as much as the regulators believe they should be,” Alt warns.

from The Financial Brand https://thefinancialbrand.com/130876/the-future-of-banking-as-a-service/

XR Talks: How Will AR Evolve from Toy to Tool?



Emerging technologies often follow a common evolutionary path from novelty to utility. It’s all about fun & games before settling into lasting value in everyday utilities. Consider the iPhone’s evolutionary arc from novelty apps like iBeer and Zippo to staples like Uber and Spotify.

The same happened on the web. After the early 2000’s bubble burst from an inflated atmosphere of grandiose visions, the web eventually reached those elevated valuations… but in a different form. The web’s killer apps are decidedly mundane: search, email, news, and productivity.

“Mundane” sounds like a bad word, but it’s not. The above killer apps have one thing in common: frequency. All-day, everyday use cases aren’t as sexy as the novelties that preceded them, but they breed sustainable business models through scale. They’re things everyone uses.

The question is if AR will follow this same trend. This is why we’re bullish on use cases like visual search a la Snap Scan. Speaking of Snap, it’s in tune with AR’s evolution towards utility, which it discussed at AWE USA – the topic of this week’s XR Talks (video and takeaways below).

2022 Predictions: Visual Search Establishes AR’s Utility

Approachable & Whimsical

At Snap’s recent Lens Fest, it announced a series of new milestones. Among them, it has reached 6 billion AR lens engagements per day. That’s the equivalent of one lens engagement per day for every human on the planet. This makes it by far the consumer AR leader today.

How has it gotten to this point? There are several tactical lessons in Snap’s rise to AR dominance, including the fact that it let AR piggyback on – and make better – an existing and prevalent behavior. In its case, that behavior was socially-fueled multimedia sharing, a la selfies.

This strategy was chosen because AR is so new and it needed that piggyback ride. For the same reason, Snap took the tech-geek ethos out of AR and simply made it fun. This approach – replete with dog ears and rainbow vomit – made AR approachable and whimsical.

Snap’s social-sharing framework meanwhile infused another key element: virality. So with this list of ingredients, Snap’s lenses began to skyrocket in usage, eventually leading to the 6-million figure above. But it also has grown in the last few years through lens evolution.

How is Snap Evolving as an AR Platform?

Ultimate Cocktail

That’s where the “toy to tool” progression comes in. Snap’s Carolina Arguelles asserts that the above approach was necessary to achieve scale. But there’s more sustained value in becoming an everyday tool in people’s lives. Virtual dog ears have novelty… utilities have staying power.

One of those utilities that’s been baked into Snap’s lens virality since the beginning is communications. The “chat” in Snapchat is meaningful here, in that AR has been propelled (along with the above factors) through the utility and frequency of messaging. It’s an all-day use case.

Moving on to other types of utilities, Snap Scan is a useful tool in that it helps identify and annotate the world. But unlike Google’s “all the world’s information” mission that drives Google Lens, Snap Scan has a more focused set of use cases, such as fashion and food discovery.

For example, one target use case is what Snap calls “outfit inspiration.” Point your phone at a friend’s jacket to browse colors, sizes and buy it on the spot. And that all leads to Snap’s real target: camera commerce. It’s the ultimate cocktail of utility, frequency, and monetization.

We’ll pause there and cue the full video below, including insights from Arguelles, as well as Snap’s Kimberlee Archer and Sophia Dominguez…

More from AR Insider…

from AR Insider https://arinsider.co/2022/02/04/xr-talks-how-will-ar-evolve-from-toy-to-tool/

Build and Ship a Design System in 8 Steps Using Backlight

What is a Design System

If you ever wondered how Apple, Uber or Spotify keep their UI and UX perfectly consistent over their hundreds of pages, it’s because they use a Design System. Enhanced version of what used to be “pattern libraries” or “branding guidelines” a Design System could be defined as a library of reusable components, that includes documentation along each of these components to ensure the proper use of it and its consistency over the different applications. The documentation is at the core of the system, going beyond components by covering accessibility, layouts, overall guidelines, and much more.

By creating Design Systems, companies are building a Single Source of Truth for their front-end teams, thus allowing for shipment of products at scale, with perfect consistency of the User Experience guaranteed over the entire product range.

As well documented in this article, a Design System is made of different pieces which we can split into four main categories: Design tokens, Design kit, Component Library, and a Documentation site.

Who Design Systems are for

You could think that a Design System is costly to build and maintain and would need a dedicated team. If some companies do rely on a team, there are now tools that allow any company to benefit from a Design System, no matter the size of their frontend team or their existing product. One of these tools is Backlight.

What is Backlight

Backlight is an all-in-one collaborative tool that allows teams to build, ship, and maintain Design Systems at scale.

With Backlight, every aspect of the Design System is kept under a single roof, teams can build every component, document it, share it to gather feedback, and ship it, all without leaving Backlight environment. This allows for seamless collaboration between Developers and Designers on top of the productivity gain and the insurance of perfect UI and UX consistency among the products relying on the Design Systems.

Steps to build your Design System

#1 Pick your technology

You might already have existing components and you could choose to stick with your existing technology. While a lot of companies go for React, other technologies are worth considering.

If you would prefer to not start a new Design System from scratch, Backlight offers a number of Design Systems starter-kits to chose from. Each comes with built-in tokens, components, interactive documentation, Storybook stories, all ready to be customized to your liking for your products.

#2 Set your Design Tokens

Once your technology is picked, you often start by creating (or customizing, if you chose to use a starter-kit) the basics Design tokens. Design tokens are the value that rules your Design System components, such as Color, Spacing, Typography, radii…

In Backlight, Design tokens are conveniently listed in the left-side panel so you can get an overview at a glance.

To create a new Token, simply hit the + button and start coding. In edit mode, the code is displayed next to the token so you can edit as you go with the benefit of having the preview window side by side with the code. Any change to the tokens code can be pushed automatically to the preview window so you can see the result of your changes instantly.

For users simply consulting the Design System, the list is displayed next to a preview for better clarity. You can observe that the UI of the documentation mode doesn’t display the code which allows for simpler and noise-free consultation of your Design System. You can see for yourself by playing with this starter-kit.

#3 Build your Components

Components are the core of your Design Systems, you can picture them as re-usable building blocks. Buttons, avatar, radio, tab, accordion, this list will be as complex or as simple as your UI need.

Most companies already have existing components. To get started with your Design System the first step would be to create an exhaustive list of every component used in the products to date and identify the most appropriate architecture, then you can start building them one by one.

In Backlight you can build your components straight in the built-in browser IDE, always keeping the preview panel next to it, to verify the result at all times.

Once a component is created, it will live on your Design System for as long as it exists (or as you delete it) and because it will have to grow with it, Backlight makes it extra easy to update components on the go.

Also, if you build upon existing assets, with GitHub and Gitlab native support you can push changes on branches directly from Backlight and review pull-request in a click.

#4 Add Stories

Collaboration between Designers and Developers is one of the bottlenecks that every team creating Design Systems will have to solve. One way to ensure alignment between the two is by providing simple visual iterations of a components state, which is a live representation of the code instead of being a simple screenshot at a given time.

In order to do so, Backlight added support to the most common solutions: Storybook

Backlight natively supports Storybooks’s story files. Stories are visual representations of a state of a UI component given a set of arguments, and one of the best ways to visualize a Design System or simply get a quick overview of a component iterations.

Stories can be coded directly into Backlight and displayed next to the documentation

#5 Link your Design assets

If you already have design assets, Backlight support Figma as well as Adobe XD and Sketch. By embedding a link to the assets, Backlight will display them live within the interface along with the documentation and the code so developers can make sure that both are in sync.

  • Figma libraries

Among Designer tools, Figma is often one of the go-to, and its libraries can be natively displayed within Backlight, giving Developers direct access to the visuals.

  • Adobe XD

Next to Figma, Adobe XD hold a special place in the Designer community and it is as well supported in Backlight

  • Sketch

By supporting Sketch links and allowing them to be embedded within the documentation, Backlight ensures once again proper alignment between Designers and Developers, removing the need for long back and forth as well as team members relying on tools they are not comfortable with.

#6 Generate the Documentation

A Design System is only as great as its documentation. The core of your system, the documentation has multiple facets but will mostly be able to:

  • Facilitate the adoption of the design system among the product team thanks to visual preview and concise how-to.
  • Ease the maintenance, a well-documented system is like a documented code, knowing the how and why of every bit, it gets easier for the team to scale or adapt parts.
  • Ensure the survival of the Design System, an easy-to-digest documentation of your system will avoid team members taking shortcuts and ending up not using it.

Backlight supports multiple technologies to build your documentation, MDX, MD Vue, mdjs, or Astro, you can pick the one that suits you best. If you are wondering what technology to chose, this article will be able to guide you. However keep in mind that the best practice is to use a technology that can embed your real component, thus ensuring that the documentation has the latest visual iteration of it, at all times.

Backlight allows for users to build interactive documentation, with menu, dark and light mode, live code sandbox, components preview, and more.

Like for the rest of the Design System, the code is displayed next to the preview to have visual feedback at all times.

For inspiration purposes, here is a list of the best Design Systems document sites to date.

#7 Gather feedback from the team

One, if not THE, main bottleneck front-end teams encounter while building a Design System is communication between Developers and Designers. Both sides are living within their own tools, and it often ends up with teams creating multiple asynchronous Design Systems, which are costly to maintain and often sources of mistakes.

Backlight offers a platform that non only regroups everything under a single roof, but that outputs documentation and visuals that are easy to share to entire teams.

  • At any time a Developer can share a live preview of what he’s working on, and edit the components as he receives feedback. Each edit will be pushed to the live preview and the other side can directly see the results.
  • Designers can update a Figma or Adobe Xd library, it will be automatically shown in the respective tabs inside Backlight for a Developer to update the impacted components.
  • Thanks to the live preview panel, Designers that know code can quickly update any component or token to their liking, which then can be reviewed by a developer before pushing for release.

#8 Ship your Design System

Once you have a proper Design System, tokens, components, and the documentation that goes with it, it is now time to use it which means generating the outputs of the Design Systems (code, documents site…) for the team to consume it.

Before releasing you can double-check unreleased changes at a glance, using the built-in visual diff panel, and even automate testing.

Once everything is properly verified, to facilitate the release Backlight has a baked-in npm package publisher, so you can compile, package and version your Design System on demand.

Once published, you will be able to see the history of previous releases and access every corresponding package directly from the release panel.

Kickstart your own Design System

By simplifying every step and keeping it all under the same roof, Backlight makes Design Systems affordable for every team, no matter their size.

Sound promising? Wait until you learn that there are a LOT more built-in features and that you can start your own Design System now! More than a product, Backlight is a community that will set the starting blocks for you and guides you through the finish line.

The post Build and Ship a Design System in 8 Steps Using Backlight appeared first on Codrops.

from Codrops https://tympanus.net/codrops/2022/01/24/build-and-ship-a-design-system-in-8-steps-using-backlight/

Refreshing our Icon System: the why and how behind the changes


It’s a new year and we have a new look! In case you haven’t seen them yet, we’re in the process of rolling out a refreshed, bolder look for our icons, starting with the mobile and desktop apps.

Our current suite of icons has been with us since the last redesign in 2016 – and while they’ve served us well, recently, we identified a need to update them, bringing them in line with the evolution of our visual language. 

Framing the problem

To refresh our icons, one of our design systems teams, Encore Foundation, teamed up with Rob Bartlett, the skilled iconographer who worked on the 2016 redesign. Together, we identified the key challenges they needed to address:

The weight and thickness of strokes were too thin

We wanted to revisit the weight of our icons based on a few things:

  • In the evolution of our visual language over the last few years, we’ve increasingly switched out text-based buttons for icons and made them more prominent in our UI.

  • On top of that, we’ve also increased the size and weight of our typography, which made thin icons look a bit out of proportion.

  • Most importantly, we also saw an opportunity to increase the readability of icons, especially when they’re sitting on top of a variety of different backgrounds.

We had a few different sets of icons to merge

Over time, Encore systems had diverged and we set out to create a new set that could accommodate them all, making things more consistent and easier to manage.

Creating and managing icons wasn’t as easy as it should be

We saw a need to simplify our icon system for teams in general. One key aspect was to build on our recent switch to Figma by bringing the design source files for icons and creation flows there in full. Another one was to try and reduce the number of icon sizes we had to create for every single icon that was being added to the system.

Enabling a seamless transition for everyone

We wanted this update to feel like a seamless transition for end-users. For the vast majority of icons, we’ve kept the current metaphor intact for this very reason so that users can find their way but enjoy a refreshed icon style.

So, what’s new?

Along with an overall refresh, the key difference is that we’re increasing the weights of our icons by changing the main stroke size. We’re going from 1px to 2px at 24px icon size.

Two, bolder sizes: 24 & 16px

We’re increasing the stroke weight of our icons and simplifying our icon system by now only maintaining icons in these two sizes:

Any other sizes that are needed will be scaled versions of these distinct sizes.

The result is a balanced set of icons and typography, that’s more readable.

Refreshed style across the set

We merged the sets by redrawing every single icon in the new style with the thicker strokes. The vast majority of icons keep the same metaphor as before.

Increased the difference for active states

To increase clarity, active states are no longer using only subtle changes to weights but instead filling up a portion of the icon.

This is how we did it

Partnering with Rob Bartlett

Encore Foundation is responsible for all the core elements of Spotify’s design language. For several months, Rob Bartlett embedded with the team to ensure a very close and successful collaboration.

Identifying the new icon weight(s)

One of the key steps in this process was defining the icon weight we would use going forward. We primarily used 1px stroke weight and we knew we wanted to increase it – but by how much? We tried several different options; the bolder we got from where we’d been, the more we could see a clear improvement. After rounds of iterations, we settled on the two new weights. This decision was based on two key aspects:

  • In order to meet our goals for the project, the new weights needed to be noticeably bolder than before. With 1.5px and 2px, we were increasing the stroke-weight at 50% for the 16px sizes and 100% for the 24px sizes.

  • The new weights needed to be easy to design when creating new icons. This meant staying as close as possible to whole pixel or half-pixel values, which designers would find easier and faster to work with.

Which sizes would we use going forward?

In our previous icon set we had more than 220 icons x 5 size variants = 1,100 individual assets. Our aim with the refresh was to reduce the number of individual assets as much as possible, in order to make it faster and easier for teams to add to the system.

We already knew that Encore Web had successfully moved to using only 24px icons, but we also had to take the needs of the entire system into consideration. Using analytics, we could clearly see that 16 and 24px were the most used icon sizes – by far!

The main use-case for 16px icons was found to be in apps like desktop and in any instance where the icons might need to be even smaller, like our download indicators in all track rows for example. For downscaling to work properly in these cases, the 16px icons needed to use the full width and height of that icon space.

We determined that scaling the 24px size up would work for the vast majority of cases where icons are needed at larger sizes.

The final outcome was that we reduced the number of size variants in the system down to 40% of what we had before by using 2 sizes instead of 5 – a reduction by 660 individually drawn icons. When we make new additions or changes to the set going forward, that efficiency win will have great impact.

Streamlining the contribution flow with Figma

Another big focus for us was to bring as much of the contribution flow for new icons as possible to Figma, as that’s now the default tool at Spotify Design. This meant several things:

  • The whole process for adding icons is documented within Figma.

  • All the guidelines on how to follow the new structure and visual style are available in Figma.

  • When teams are making their icon submission, we’re encouraging them to also share explorations that led them to their final design. This means we can build a collective history of icon-focused explorations in close proximity to where all the production icons are being housed.

  • All icons have both their editable source vectors available, right next to the optimized versions used in production. This means everyone can easily build on top of existing icons when they’re considering an addition or an edit to the icon system.

Through close collaboration with our engineers, we also managed to automate almost all aspects of generating the necessary code and different output assets needed for our various platforms.

What’s next?

We’re excited for everyone to experience the refreshed icons in our mobile and desktop apps now and you’ll start to see them in other platforms gradually throughout this year.

Credits

Andreas Holmström

Senior Product Designer

Stockholm-based, 10 years at Spotify (5 in Brand, last 5 in Product/Design Systems working on Encore). Loves golf, running, deep house & spicy food!

Read More

Rob Bartlett

Icon Designer

A specialist in global icon deliveries, with 25 years of interaction design experience. Rob is also proud to be a carbon-neutral designer.

Read More

Spotify Encore Team

The Encore design systems team makes sure that Spotify looks, feels, and works great anywhere. We love building tools that allow designers, developers, and writers to create incredible experiences at scale.

Read More

from Sidebar https://spotify.design/article/refreshing-our-icon-system-the-why-and-how-behind-the-changes

Fintech Emerging Markets: Frictionless Cross-Border Payments

Mario Shiliashki, CEO of PayU tells us why emerging markets are leading the … has become a very lucrative source of growth for global merchants, …

from Google Alert – https://www.google.com/url?rct=j&sa=t&url=https://fintechmagazine.com/digital-payments/fintech-emerging-markets-frictionless-cross-border-payments&ct=ga&cd=CAIyGjRiZjI0YzRlZjA5NmMxYjQ6Y29tOmVuOlVT&usg=AFQjCNFdY8uaipPZFmvlkNn0MiLmRsn6GA

Sound design and the perception of time

A nonsense image generated by neural network
The image was generated by ruDALL-E with a text query “Game audio and perception of time”

We often say that humans are visual creatures. The Colavita visual dominance effect demonstrates that visually abled people are strongly biased towards visual information. When they see an image and hear a sound, they might pay so much more attention to the visuals that they entirely neglect the audio. There are some known phenomena when visual information overrides auditory input, such as the famous McGurk effect. But visual dominance is not universal. There are contexts and situations where vision becomes less efficient as our primary sense, and we start relying on other modalities. One of such contexts is the subjective perception of time.

Disclaimer: When reading my blog, you may get a false impression that I know something about cognitive psychology and other research fields I typically refer to. I have no expertise in those. I am a practicing sound designer, curious enough to read a couple of research papers every now and then. I check my sources and mostly mention things that make sense based on my professional experience, but I lack the competence and supervision to make scientifically accurate statements. Keep in mind that most studies I refer to were done outside of the video game context, and I did not conduct any experiments to confirm my hypotheses. In other words, prepare your grains of salt!

There is a lot of evidence that audition dominates vision in temporal processing. Experiments show that when we perceive the duration of audiovisual events based on the duration of the auditory, not the visual component. The effect of sound modulating the perceived duration of a visual stimulus is often called temporal ventriloquism, as opposed to the classic ventriloquist effect. The ventriloquist effect is the reason why we perceive movie characters’ speech as it is coming from the TV screen itself, not from our speakers. In this case, our vision “captures” sound, influencing our judgment of its spatial location. Temporal ventriloquism is the reverse effect that happens in the time domain.

My posts are usually oversimplified but pragmatic explanations of complex perceptual mechanisms tailored to the game development context. This one is no different, so here is my take on the phenomenon. Whenever we perceive audiovisual information, we mostly rely on visual cues to understand how things exist and behave in space, but we prefer sound to understand how they exist and behave in time. I’m not saying we don’t perceive time visually; rather, we use auditory information as the clock or the source of truth whenever we get somewhat conflicting inputs on both sensory channels. Given that hearing is faster than sight (more on this in an upcoming separate post), it is not surprising that the faster sense delivers more reliable input data to inform us about time.

A nonsense image generated by neural network
The image was generated by ruDALL-E with a text query “Temporal ventriloquism”

How can we use this knowledge in our day-to-day work? I see three levels of practical application. On the smallest scale, we can use individual sound effects to alter the visual events on the screen, making them subjectively faster, smoother, snappier, etc. On a medium scale, rhythmic sound patterns become helpful in efficiently communicating the gameplay dynamics or timing of individual events. Finally, on the largest scale, we can alter the soundtrack or soundscape to make the player feel that time passes subjectively faster or slower.

Sound effects and visual motion

A well-timed sound may affect the perception of visual events. One famous example is the so-called Double Flash Illusion, where sound makes some people see two rapid flashes instead of one. A less known but more fascinating example is the Motion-Bounce Illusion that demonstrates how sound can alter the visual motion perception and, in a way, completely change the meaning of the visual event. Those illusions are not particularly useful in the game development context, but they show how strongly can audio modulate what we see.

Thanks to auditory dominance, we can intentionally break audiovisual synchrony to separate simultaneous events in time and better communicate their quantity. I made a short example video to demonstrate this:

In the video, the arrows reach both targets at the same time. Intuitively, we want to synchronize sound with visuals and play them simultaneously, as in the beginning. However, without a proper separation in time, two sounds blend into one, which feels odd — such coincidence is unlikely in real life. But notice what happens when I start incrementally delaying the sound, associated with the right target, 50 milliseconds at a time. Both 50 and 100 ms delays feel natural and believable. Some of you may even perceive the second hit as visually delayed (thanks, temporal ventriloquism!). At 150 ms, the delay is noticeable but still acceptable. And only at 200 ms does the lack of synchronization become apparent, which aligns with the thresholds mentioned in ITU-R BT.1359–1.

This trick is helpful to perceptually clarify the visually cluttered scene with many simultaneous events. But there are other practical applications. One study shows that sound effects can influence the perceived smoothness of rendered animations. Motion smoothness variations at lower framerates became more apparent to the audience when the animations were presented with no sound. On top of that, it is not uncommon to observe a sharp, snappy sound making the visual movement appear faster than it would be if seen with no audio cue.

Note: I do not advocate using audio to compensate for visual shortcomings. The proper way to solve the problem above would be to separate the events visually in the first place. Any lack of audiovisual congruity decreases perceptual fluency, potentially adding to the cognitive load the player experiences. But these tricks could be helpful when you are desperately short on resources or want to experiment with different feels.

Keep in mind that these effects only appear on a relatively short time scale with a limited range of asynchrony. If audio and visuals are noticeably separated in time, they appear as two different messages, disconnected from each other. ITU-R BT.1359–1 recommends specific thresholds of audiovisual desynchronization in broadcasting: detectability thresholds of +45;-125 ms and acceptability thresholds of +90;-185 ms where positive value means that sound precedes the visuals. Given the interactive nature of our medium, I’d stick to even smaller ranges of detectability and acceptability to be safe.

Rhythmic patterns

Remember those countless videos on YouTube with funny animals dancing to music. Watching them carefully makes you realize that the animal’s movement doesn’t usually match the music rhythm that well. Your brain adjusts your perception of the movement based on the song’s rhythmic structure, tricking you into thinking they fit, even if they are out of sync. Most humans are pretty bad at visually analyzing rhythmic sequences. If you want to find out how bad you are, check the video demo on this page. Unless you have a kind of synesthesia that allows you “auralize” visual rhythms in your head, you will have difficulty differentiating between the pairs of flash sequences.

From the game development perspective, it means that audio becomes a primary information channel to communicate rhythmic patterns. This is obvious in rhythm- and music-based games but easy to overlook in cases when understanding a rhythm could help the player win the challenging fight or time their jumps in a platforming sequence. Of course, you don’t want to turn every game with repetitive event sequences into a rhythm game, but luckily you don’t have to. Accurate and synchronized sonic representation of in-game events is usually enough to guide the player. It is easy to understand this idea if you carefully listen to any popular fighting game and observe how rhythmic, not necessarily in the musical sense, the character moves are and how sound helps you understand these rhythms.

You may argue that intentionally omitting the auditory component of rhythmic action could add to the challenge. I think this is a valid point, but please remember that dealing with the shortcomings of our sensory systems is rarely a fun challenge. So, I’d strongly recommend carefully evaluating such design decisions in the context.

Auditory dominance is also why many sound designers seek framerate-independent implementation of gunfire sounds in shooter games. The player may not notice when the game skips a frame or two, but any deviation in steady auditory rhythm becomes too obvious to ignore. Check this video about the weapon audio of Borderlands 3 if you want to hear an example.

Music and temporal judgments

Although thematically connected to the other effects I describe in this post, long interval judgments, at least to my knowledge, have nothing to do with temporal ventriloquism. But given a vast amount of research on the effects of music on the perception of time, I thought I should mention it in this post.

A nonsense image generated by neural network
The image was generated by ruDALL-E with a text query “Music and chronoception”

First, there is strong evidence that the mere presence of music leads to time overestimation in an audiovisual context. It means that whenever any music plays while we experience something audiovisually, we think that experience has lasted longer than it did. Plot twist: there is also evidence about the mere presence of music is causing people to underestimate time! And both sides tend to agree that the mere presence of music leads to less accurate time estimations than an absence of music.

A large-scale study by Ansani and colleagues links the overestimation with arousal: the more intense music is, the more people overestimate time. Authors particularly highlight tempo and musical complexity as factors increasing arousal and thus influencing the perception of time. And there is no shortage of studies that support those ideas. It also makes perfect sense to me: whenever we are activated, time slows down to make us react to whatever happens around us.

Another study shows that adding music to the game causes the players to underestimate experienced (but not remembered) time. Researchers asked one group of test subjects to keep track of time while playing, while the other group was asked to evaluate the duration of play after the experiment. Only the first group members have significantly underestimated time when playing with music.

And as a cherry on the cake, a study on racing games demonstrated that players overestimated time when the music was selected by them and underestimated time when others chose the music. It parallels the notion that people spend less time shopping when familiar music plays in the background. More interestingly, the racing game study says that arousing music makes people report shorter periods of time, not longer ones, as mentioned above.

So, what the hell is going on? Overall, the area of research on music and perception of time is a rabbit hole, and I could spend months investigating it. I did not, so my takeovers are probably not very profound, if not just lame. One logical explanation for the contradiction would be that the influence is bidirectional; some music features cause overestimation, others result in underestimation. But to my knowledge, there is no clear, non-conflicting evidence supporting this idea.

There is evidence that perception of time shifts depending on whether people like the music or not. In an audiovisual context, overestimation likely happens when music is congruent with the experience. Unpleasantness and incongruity result in underestimation. If this is true, we can expect overestimation in most game-related contexts: games usually have congruent music that supports the experience even when the music itself is unpleasant to hear. Both studies on games linked above showed underestimation, but none of them used pieces explicitly authored to support the gameplay experience, so people likely perceived the music as incongruent.

Ansani and colleagues propose an alternative explanation that aligns with what I see from the studies. In most cases of underestimation, people were consciously aware of time passing by — either waiting for something to happen or knowing that somebody would ask them to estimate time spent. On the contrary, in most cases of overestimation, people did not track time and evaluated it retrospectively. So, music may have opposite effects on prospective and retrospective judgments of time. In cases when people are aware of time, music can be a distractor that drags our attention away from monitoring the time flow. In instances where we are not aware of time, it adds to the complexity of experience, making the brain register more events and use more attention and memory resources, leading to overestimating. The intensity of the music, resulting in higher arousal, could be a modulating factor in both effects.

A nonsense image generated by neural network
The image was generated by ruDALL-E with a text query “Temporal effects of music confuse me”

Why would we want to shape the player’s perception of time in the first place? Game designers may have a better answer for this question, but I see a few creative applications. For instance, we could alter the soundscape to make certain moments perceptually longer and more memorable. Or we could try to increase the average session length in a free-to-play game. I am especially interested in the audio treatment of low-intensity moments when the players wait for something to happen, such as matchmaking, loading screens, or similar idle periods.

Being familiar with only part of the evidence before writing this post, I thought I’d finish it with a clear recommendation: don’t add any complex custom audio to idle moments in your game, or they will appear to last longer than they are. Every bit of my subjective experience and professional intuition screams this is still true: when we add a custom music track to, say, loading screen, we make the players consciously aware of the time they need to wait for the game to load and seemingly stretch that time for them. But as the evidence suggests, there could be an opposite effect.

As an individual who writes this blog on weekends, I cannot test this in a proper experiment. But I would be very interested in finding this out: knowing how to make the idle moments less noticeable, we can tremendously improve player experience in many games. I’d be happy to discuss this! If you share my interest and know the answer or can find the answer (by experimenting or in any other way) — please reach out.


Sound design and the perception of time was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

from UX Collective – Medium https://uxdesign.cc/game-audio-and-perception-of-time-9569a963772a