Sometimes, a simple website is exactly what a business needs. Short, sweet, and immediately gets to the point. However, in the case of Experienced Advisory Consultants (EAC), their website was simple to a fault. The design was outdated, unprofessional, and was certainly not driving any new clients to the business.

After about six months of iteration in design and development, EAC had a brand new website to call home:

With all development done in-house, the website is reliable, built with the latest technology, and ready for public use. Excellent scores in accessibility, performance, search engine optimization, and best practices. See it for yourself at 

So, how did we get here? Here’s a little about our process for designing the home page.

EAC came to us with clear parameters: they needed a new website that evoked professionalism and hinted at the cutting-edge nature of their business. A mixture of traditional and cutting-edge. While most of their existing clients were acquired through word-of-mouth, EAC also wanted their website to act as a funnel for new potential clients.


We began iterating immediately on designs:

With the first pass, we focused on more traditional designs. Their feedback would help us gauge exactly where they wanted to fall on the spectrum between traditional and modern design.


Feedback from those designs pushed us into a more modern approach. “Get rid of the stock images, remove the box-y shapes, make a more interesting hero.” Can do. Our next iteration pushed the envelope into more modern designs. Instead of stock images, we began experimenting with 3D graphics and simulations.

We even experimented with a dark mode version (this was a quick iteration, so many of the contrast values on overlapping elements are incorrect):

Dark-mode-first was not what they were looking for, but everything else was starting to connect. The text felt good, the layout was coming together; this design started to click for EAC. But we weren’t quite there. The simulation was too thin, not visible enough, and looked outdated. We needed something richer that matched the rest of the website. Something more pronounced, but still elegant.

At this point, we started to run into concerns about the old logo clashing with the new designs we were creating. We expected this, and initially offered to create a new logo, but the task wasn’t accepted into the statement of work so we had tabled it for later. Instead we decided to just modernize the existing logo. This included tracing into a vector shape and exporting it in multiple formats with different color schemes; SVG and PNG files of the logo in color, black, white, and with transparent or solid backgrounds.

This work came out great, but about halfway through our interface design iterations, the talks of a new logo were renewed. The goal wasn’t to completely redesign the logo, more so iterate on the current logo to match the designs of the new interface.

We first adjusted the proportions of the E in EAC to balance out the weight of the logo:

And eventually, we combined them all and started matching colors to the ones we saw in the interface:

This was our recommendation for use in the new website and general branding for the business. It never got adopted, but we’re proud of the work that went into the process.

At the same time this logo exploration was underway, we started to make progress on the landing page. We found a particle simulation library we could use to generate an interactive background for the landing page. Choosing a background color that meshed well with the simulation was our next challenge:

The consensus was, the light blue was a clear winner. However, the particle simulation wasn’t enough. It looked too thin and too basic for what we were looking for. Fortunately the particle simulation library we were using to generate the effects had a massive configuration API that we could use to customize the simulation. Here is some of the configuration object we used to make the effect:

After several iterations, we ended up with a configuration that was unique and in our opinion, looked great:

After some adjustments to the fonts and copy, we had our landing page.

This is some of the design work that went into the landing page of the new website. Many more sections, conversations, and deliberations occurred with every section of the website, leading to a result EAC is very happy with. We put an emphasis on accessibility and performance, and we keep all development in-house to ensure excellent results:

We encourage you to visit the new website and see the landing page in action, as well as the other sections and pages we created that required as much attention to detail: 

How we designed and developed a new website for EAC, a leader in the financial outsourcing industry.

A New Home for Experienced Advisory Consultants

Looking back, one of my biggest lessons learned from building Gatsby is to avoid pre-mature automation.

What do I mean by this? Take our payments system, for example. Integrating Stripe was quite a doozy: a custom subscription job, saving payment methods, handling failed payments, handling account balances, etc. There was 

logic that went into all of this. All in all, it took about two months to complete our integration and get to the point where it works. (And at this point, total development time for Gatsby was only at ~3 months, so the payment system was 40% of total time spent. Yuck.)

That system, in hindsight, is completely overkill for the business' needs at that point.

 We had no users, no recurring revenue, nothing. So why did this payment system get built?

It's easy as a developer to get carried away with automation. "If only x was built, I wouldn't have to worry about y", is a common trap—and honestly, it's often not an incorrect one. 

As engineers, we're always thinking about scale.

 Yes, it's true that building this thing will make your job easier down the road when we have 10,000 users. The allure of stress-free development is tempting, especially if you have multiple tasks you're dealing with and want to run the business as passively as possible.

However, one must account for the business' position and its priorities. When considering further automation, you have to challenge yourself: "with the current position of our business, 

More often than not, it's not. Elon Musk has a brilliant quote in this department:

The machine that makes the machine is vastly harder than the machine itself.

The whole tweet is a perfect descriptor of what we're trying to accomplish: scale. If everything is automated, scale won't be a problem! However, the difficulty of automating that solution is much much much more difficult than creating a repeatable, manual process for solving that same problem.

That's what I wish we did for Gatsby. Instead of jumping the gun on automation, I wish I had created a lightweight admin interface where I can see whose turn it is to send an invoice that day. Then send them to a pre-built Stripe checkout page. That would've been the 

minimum viable product answer. Instead, we over-optimized by over-automating and burned through two months we could've spent on marketing or improving MVP features elsewhere.

I can't help but think about how this would've been avoided if I had properly outlined the work ahead and determined my 

 for this work. Basecamp created this idea of determining appetite, and 

When shaping, we focus less on estimates and more on our 

 Instead of asking how much time it will 

 to do some work, we ask: How much time do we want to 

If I had taken the time to understand that no, this payment integration idea isn't worth spending two months on, or 40% of our total development time, we could've avoided the over-automation.

In the end, it's a lesson learned. Treat all development efforts with great respect and always challenge what "needs" to get built next. I mean, it's not all bad; the payment integration is ready to go, so if we ever do hit scale we'll be set. However, we definitely skipped over some steps in between and certainly mismanaged our time.

This is one of those situations where it's tough balancing being 50% engineer and 50% businessman. Automating processes is tempting, sure, but automating too early can lead to wasted resources and wasted time.

It's easy as a developer to get carried away with automation. "If only x was built, I wouldn't have to worry about y", is a common trap. Here's how to avoid it.

Say No To Premature Optimization

One of the most important aspects of the Gatsby platform is enabling communities to earn money. We're "monetization-driven", which means many of our features will be designed to enable community owners to make some fat stacks of cash.

We came up with two strategies for implementing the collection method. Think about which one you'd choose. They differ very slightly, or so we thought...

The first method: when a user pays a community, the payment enters Gatsby's collective bank account. In our database, we keep track of the community owner's balance, not before Gatsby takes its percentage. When they're ready to use that money, they can set up a Stripe account within the Gatsby interface and trigger a deposit to their bank account.

The second method: before a community owner can start collecting money, they 

 to create a Stripe account. Then when a user pays a community, the money enters directly into their Stripe account. Gatsby takes a percentage on its way out. From there, they can send their money from Stripe to a bank account.

were building Gatsby, which method would you choose?

With the first method, you'll have direct control over the funds. Everything that enters the Gatsby platform will enter this account, giving direct control, insight, and safety to the business.

With the second approach, we don't have to worry about the security issues, balance tracking, and communities will get their money right away. However, it won't be so easy to reuse the money they earn. The term "Use your Gatsby Balance" probably won't be a thing.

Well, turns out, there are some serious legal implications operating with the first method. Technically, 

the platform would become a Payment Facilitator

, and like I said earlier, it's pretty similar to a bank. Now you have to be aware of how certain individuals could use your platform to cause harm. If you said option two, you are correct. (The first option is not impossible, but the overhead is way too much for a small team of one.)

In fact, the FTC would not take too kindly to a lackluster implementation of the first method. Here's an example:

Let's say you're a community owner and you happen to live in a country the 

. Then let's say, in the future, the platform had an option to withdrawal your money without using Stripe. The combination of those two things has now enabled a loophole for foreign entities to use Gatsby as a means for fraud and other financial crimes. Yikes!

When (not if) this gets uncovered, you'd be under investigation by the Financial Crimes Enforcement Network, the Office of Foreign Assets Control, the Federal Trade Commission, and whoever else decides they want to throw the book at you. They'd be queuing up fines in the many millions.

The reason method number two protects you is because we'd require Stripe authentication before you can earn money. So if you're cool with Stripe, you're probably cool with us. We'll let them do the hard work here.

Can't we still offer method one but not allow them to withdrawal to anywhere but Stripe later on? Yes, but that would set up a customer service nightmare (and potentially a PR nightmare as well). If these "restricted" users start earning money, then go to withdrawal and find out they can't because of where they live? Can you imagine the emails we'd get? "Robbery! Theft!"

Plus, another one of our pillars of success is a great user experience. And that, my friends, would not be a good user experience.

We came up with two strategies for implementing a payments collection method. One gets prison, one doesn't.

The Payments Dilemma

Growing a network reliant on network effects is extraordinarily difficult. This graph helps illustrate the “self-fulfilling prophecy” phenomena of growing a network reliant on network effects.

The orange line here is the expectation of users a potential newcomer has when joining the network. The blue line is the actual number of users. If the actual is less than their expectations, they will be disappointed and leave the network. If the reality surpasses their expectations, then they stay! The arrows denote “pressure zones”, or how the actual number of users will be affected in that area.

As an example of this graph in action, let’s say we’re starting a new social network. We have a huge advertising campaign, the product is great, launch day is a huge success. Users hop on to your social network day one and find… that none of their friends are on the network. Not just that, nobody they even know is on the network. But what about the expensive marketing campaign? The messages? The hype!? This was supposed to be the next big thing! That user may try again a few days later, but the results will probably be the same. The user is disappointed, and leaves the network forever. Sound familiar to something you've built?

Multiply this effect by a thousand people and a thousand dollars and… the network still fails. People still get disappointed and 

the total number of users can’t seem to get off the ground.

 This is that “downwards pressure zone” you see in the graph, in action. That first hill is extremely difficult to climb, and 

users need to quickly see and experience the network’s benefit before deciding to stay

. This is why you don’t see any successful private social networks. I know this because I

. Without a focus on discovery, without users having a feeling of how many people are on the network, without a clear benefit screaming in the user’s face, the platform will ultimately fail, because new users have no incentive to stay! Only by reaching that tipping point on the graph do we start to see success. Climbing that hill is hard, and I’ll show you how to beat it.

Now there are strategies for overcoming this initial downwards pressure zone and that's something I'd like to get a little bit more into. This is often called the chicken or the egg problem, and there are 

quite a bit of strategies for overcoming it

. But if we're talking about network effects, we have to talk about how we're going to apply this to our product and do it successfully.

I don’t want to understate how important this is. Being the first network to reach the tipping point is crucial to a platform’s success in a volatile market. In a market of products with network effects, there isn’t room for second place. It’s either sink or swim. The success of one network will make using the competitor’s network much less attractive. Reaching this tipping point is more important than being the “best”.

Every network has to start somewhere. There was day one for Facebook. There was day one for Twitter, a day one for YouTube. Every platform has its day one. And how you approach that day one is going to separate the winners from the losers.

Now, if your product has benefits other than just users, it’s a different story. So Figma, Venmo, and other services don’t fall victim to the ruthless downwards pressure zone as much. It becomes much easier to surmount that upwards hill if you also provide a service that benefits users without network effects.

The following strategies focus on facilitating a “surprise effect”. The goal is to beat the expectations of the user when they first enter the platform and surprise them with either direct benefits. Remember, if they become disappointed with what they see on the network, they’re going to leave and the total number of users will trend back to zero. You need to beat the downwards pressure.

There’s certainly psychology at play here, and I’d argue it’s working against us. Unfortunately, today’s users have a high-expectation of what a network will be. We’re used to being able to find anyone we’ve ever met on Facebook, any celebrity on Twitter, and any colleague on LinkedIn. We’re spoiled with diverse networks, and will make that initial user-disappointment phase hard to overcome.

is launch your network to the world with no initial content and no pre-existing users

. Do not do this. You’ll be cursed to the realms of downwards pressure forever as your network suffocates from stagnant growth. It will fail. No amount of marketing will convince a user to stay on an empty network.

The first real strategy is to convince a large initial group to join your network. By getting a large, connected group on the network, you can create a network with strong ties between them. Facebook unintentionally used this tactic to its benefit. Zuckerberg targeted students that went to Harvard, and users quickly hopped on to see their peers on the network. Within the college, Facebook went viral, with that virality serving as a catalyst for the large initial group. And by the way, 

Tinder, the location-based dating app, did something similar by targeting sororities and fraternities at local colleges and onboarding several users at once. 

 (that's the goal!) to find all those girls or guys they knew from the other sorority or fraternity. With several users joining at once, the network would become sustainable among them, and be able to support further growth from solo newcomers.

A similar strategy can be employed by influencers and having their followers join the network together.

By setting a low price, or even free, users will be more inclined to try the product. This is less tactical than the other approaches, but helps get that large initial group of users at once. 

, as “small changes in the properties of the market can cause enormous changes in the size of the equilibrium audience that is reached, starting from zero”. While you may be discouraged from lowering prices for various reasons, it may be worth it to beat your competitor. Once market dominance is achieved, the rewards are yours to keep 

: “This price below the cost of producing the good will result in early losses, but if the product catches on — if it gets over the tipping point — then your firm can raise the price and perhaps make enough profit to overcome the initial losses”. Remember: improvements to the product can always be made after. Reaching the tipping point first is most important.

Now, another thing to consider here is the velvet rope effect. 

 an article explaining how startups are using a “velvet rope” to create a hype cycle around their products before launch. In short, the velvet rope strategy is essentially creating a waitlist, then choosing which users you let into your platform. These are usually industry-leaders, influencers, or other notable figures.

The hype, while great for publicity and marketing, is a double-edged sword. On one side, it allows you to control the network effects of your product. That is, you decide who is “in” the exclusive network and who gets to create the content that others will later be able to consume. The downside, however, is that with hype comes expectations, and 

with higher expectations comes a higher chance for disappointment

. If new users wait months to access this network, constantly listening to the founders and other evangelists tell us how great it is, the content better be good. Because if it’s not, the disappointment will be very real and the user will promptly exit. Your hype has worked against you, and perhaps even sunk a ship that could’ve floated without it.

If you’re using the velvet rope strategy, you need to ensure the users you let in are planting their roots. 

New users need to be seeding exceptional content, and seeding the network with desirable information

. Imagine finally getting access to YouTube after being told it’s the best network ever! It’s so useful! … and seeing there are only three videos published. No amount of hype will fix a disappointing network. But if the network is good, the hype will create a list of users that can form the aforementioned large initial group. The content and its newly active users will push the network out of the downwards pressure zone and towards its stability point.

Bots, fake users, paid users, etc. Make it seem like more people are using the network than are actually using it. When Reddit first started, the founders were using several different accounts to post links and comments. They pretended to be several users, and by doing so, 

forced the perception that the network had more people on it than the actual

. New users would be surprised by how much content was being posted, and saw the benefit of the network. They’d stay around for a while, and 

soon those fake accounts would become useless, replaced by now-active users

. The network became sustainable on its own without those initial false accounts.

Now, this specific strategy is only possible for anonymous networks. But the point remains. Making it seem like more people are on the network will force your real user-base past the tipping point and towards success.

When I co-founded a product called HotTub, it was anonymous and we planned to incorporate a feature where users could 

 a post an unlimited amount of times. The app Citizen does this too.

Now, if you think about a feed with those two features, 

it's going to be impossible to tell whether it's one person creating all this content or 10,000 people creating this content

. With unlimited likes, you could sit there and spin the like counter 400 times. A new user will be shocked to see this small app has such an active network, and will decide to stay around. With this combination, the founders control the “actual” users line on the graph, forcing it beyond expectations, and towards its stability point.

Region Locking And Reputation Preservation

For localized services, like Lyft, Citizen, or Grubhub, it may be best to limit the availability of the network. At first, it sounds counterintuitive to lock the network down to a certain region and limit its growth, but with a locked region, 

we lower the burden of providing an active community to a fixed area

. Within this area, the evangelists of the app (most likely the developers and close friends) can populate the network with community-building in mind. A more focused attempt can be made at 

strengthening the engagement on a smaller network

, while also preserving reputation elsewhere. Essentially shrinking the size of the network will make what users see, how they interact, and what they perceive, easier to control.

you now control the expectations of users in certain areas

. For example, if Lyft becomes active throughout the whole country, but there are no drivers in one area, a user in that inactive location will become disappointed when trying to use Lyft for the first time. This perception of an empty network will lead the potential user to disregard the app in the future, possibly losing a customer for life. Repeat this several times as the user base grows, the network’s success will hurt its growth when trying to capture these users in the future; a victim of its own success. With region-locking, the network will be able to reduce these negative first-impressions with a coordinated roll-out and focused efforts, populating each new region with its valuable service, riding one success to another. In this example, Lyft would recruit drivers prior to opening the network in that area. Especially with limited resources, the company will be able to dedicate full attention to the upcoming rollouts, ensuring a beneficial adoption. Instead of becoming turned-off by the empty network, future users will become excited and look forward to when the network is released to their area.

The moment your users begin to feel not disappointed, but surprised by the content on a network, you’ll start to surpass the tipping point. Users will begin to feel like they’ve been missing out, they’ll spread the word about your platform, and become a regular user, hopefully contributing back as well. Multiply this by a thousand users and a thousand dollars, and you hit a point of explosive growth. 

That feeling of surprise drives the user to be a consistent one.

 This is where you enter the upwards pressure zone. It’s going to catapult you to a point where your network is sustainable and successful. This is where the bandwagon effect of something new comes into play and thrives. Users realize the value of being on your network, and decide to stay around a while. That’s when you reach the stability point. Your growth has become automatic, and you’ve become a major player in the market.

At this point in your network’s growth, you’ve become nearly immovable. You are now the big fish. It will be very difficult for a competitor to take your place as king. As long as you continue to capture the network effects of these users, your business isn’t going anywhere. Remember, network effects is about defensibility. Your company, your business, your network, has become defensible, and now you’re ready to reap the rewards.

it doesn’t matter if you have an inferior product

. It doesn’t matter if you’re the biggest fish or the smallest fish. You can turn market instability into market predictability, and you can lock in the market big time. With network effects, you become king. Your network becomes the defining aspect of a market, and there’s no way to stop your growth. Monetization possibilities become endless, and your time to figure that out only lengthens as more users join your network. And if, one day, you have to stop using the phrase network effects because of antitrust investigations, pop a bottle of champagne for me.

You launched your network and nobody's sticking around...now what?

How To Make Your Social Network Succeed

On Monday we're opening up Arcade to its first 10 customers. We're pushing a new website live, sending some emails, making some announcements, and more. It's gonna be a big week.

When starting a new project, I have the habit to use "when we launch" as a cornerstone of communication regarding timelines and goal-setting. We were using it all the time on our Zoom calls and Slack to frame some conversations.

It wasn't until we started getting into arguments about what needed to be done that we realized 

. We know it means some form of "something about this is becoming public", but we never specified what the heck we're launching, what's included, what that will look like, and more.

For our team, Dan set us on the right tracks and made it clear that "launch" would be incremental. It wasn't going to be all-or-nothing like I had originally thought. For our first launch, we'll release to 10 customers. That's it. No plan to launch beyond that (just yet).

Once that definition was set, it enabled us to actually plan for this launch way better and enabled clearer communication. Now when we talk about a launch, we know exactly what that means and makes our meetings much more productive as we remain on the same page.

For every subsequent launch that we have, for Arcade and elsewhere, I'll be sure that we define launch and get on the same page.

It's one of those things that nobody tells you to do when you're building cool things with other people. It's something we had to realize, learn, and fix. But since you're reading this you don't have to worry, I gotchu. Define "launch".

It's one of those things that nobody tells you to do when you're building cool things with other people. It's something we had to realize, learn, and fix. 

Define Launch

, we're discovering so much about design tokens that go against conventional understanding.

What does that mean? Today, most people would simplify design tokens by describing them as a key-value pair. A name and a value. However, 

we created a way for a single design token to have 

Before digging in to that concept, we need to address the idea that design token = key-value pair. To me, this is wrong. Instead, we've been thinking of a design token as a big object of instructions that include how to transform the token, the context of the decisions behind it, various meta information, and more.

This big object of instructions is the design token.

 Those CSS, SASS, iOS, whatever variables that get outputted are exactly that: an output of a design token. Not a design token itself. In short, 

design tokens only exist in a pre-processed state

So within this big object of instructions, we can now specify a field for 

, like what platform we're rendering.Dynamic values gives huge amounts of power in enabling tokens to support multiple platforms.

Dynamic tokens in Arcade allow the value to change depending on what platform is rendered

For example if we render CSS, we can use sizes in rems or px units. If we export to Android however, we can use values in dp, sp, or whatever we see fit.

This puts so much control in the hands of a designer or developer. There's no implicit transformation happening if you don't want it to. Everything can be explicit if you need it to be. 

It's worth noting that this is only possible with a custom engine. If Arcade relied on 

 for our transforming, we'd be very limited with what kind of operations and optimizations we can perform.

The more we work on Arcade, the more we understand the depth of what a design token is. Each day it becomes 

Most of all though, we're excited to see how people might use these concepts in a way we never imagined. For us, it's all about empowering the designer and developer.

Today, most people would simplify design tokens by describing them as a key-value pair. A name and a value. However, we created a way for a single design token to have multiple values.

Dynamic Design Tokens

Design tokens are a new concept in design and development that simplifies how we think about supporting brands across different platforms. They enable a single collection of variable objects to power the design of web, iPhone, and Android products, as well as any other branding that a team may need.

There's no standard for working with design tokens, however there are efforts currently underway that are trying to standardize definitions and best practices. The effort is being tackled by a 

, individuals, startups, and established companies alike.

 have been building a design token manager for this reason and have been learning 

Design tokens are new. As we think about them and apply them in our workflows, our understanding will evolve. Two days ago while discussing Arcade, that happened to me.

It's going to challenge the current consensus of what a design token is. You've been warned! Here we go...

Design tokens only exist in a pre-processed state.

Once compiled and transformed, the output is 

Instead, it's simply what it is: a key value pair fit for the platform. A variable in a form the platform can understand.

The reason for this conclusion is because the purpose of a design token is to exist as a value, surrounded by context, ready to be transformed. When the design token goes through that transform process, 

That meta information is very important: it provides context to the token and instructions for how that token should be transformed.

For example in Arcade, we have a schema for our tokens that supports fine-grain control of how the rendering engine will handle that specific token. Should this token be ignored for a certain platform? Does the value change depending on the platform? Should we 

render this token in certain circumstances?

This is only some of the information that makes up a design token. 

Each token object grows more and more as we find more useful information that can be stored in them.

 Once that crucial information is gone though, we lose its transform-ability.

Think about it: we can go from our token source to CSS very easily. We can also go from our token source to Android very easily. But can we go from CSS to Android? No. Because 

we lost all of the meta information and rendering instructions

 that were included in the original, pre-rendered design token. Not only that, but the name and value might have completely changed from the source!

When explaining this concept to the team, I used a metaphor of a tomato. You can go from a tomato to pasta sauce 

. You can go from a tomato to a slice of it on a sandwich 

But can you go from sauce to a sliced tomato? No! Because that original tomato has been completely transformed and its original state is completely unrecognizable.

So moving forward, I'm going to be using this frame of thought when talking about design tokens. I can't see it any other way. 

While organizations might not have this expansive amount of information around their design tokens yet, I imagine they will soon

 to further enable their teams. Considering what 

Design tokens only exist in a pre-processed state in their source. Do you agree? Disagree? I'd like to hear what you think.

Once compiled and transformed, the output is no longer a design token. Instead, it's simply what it is: a key value pair fit for the platform. A variable in a form the platform can understand.

Design Tokens Only Exist In A Pre-Processed State

As creators, it's our responsibility to keep up with the demands of users and build the best possible experience for them. As time goes on, users' expectations rise as they see what is possible with current technology.

 great experience to show what is possible and to change our users' expectations forever.

Consider dark mode! Just five years ago it was somewhat of a rare feature. But now, users expect the option from almost every website they use.

That's what makes building a product so difficult: our users' needs are 

 to our user's needs and provide the best experience for them.

 And like I said before—if we don't, our competition will. And users will always go where the best experience is.

It you go back to 2010, you'll see the emergence of 

that makes web pages render well on a variety of devices

". While the title is referring to a web page that responds to different viewport sizes, I like to think that term has another meaning: 

the ability of a web page to respond to users' needs.

In 2021, we're entering a new stage of user's needs and expectations—Responsive Design 2.0. Today, users expect a certain amount of theming abilities and accessibility features. Take a look at this Tweet below covering the new 

This is becoming standard across all websites and applications. Designers and developers have to adapt their process of building new products to account for this new demand. And if they don't, your company will lose users, and subsequently lose value.

So, how can developers and designers meet this new need of theming, accessibility, and customization? Think about it from the very start. Prepare your code to handle these types of features. Focus on creating a reusable design system from the very start, and consider how 

 might power the components to create beautiful experiences like this.

Don't put it off either. The longer you wait to face this challenge, the harder it'll be to fix later on. And the longer you take, the more time you give your competition to eclipse your functionality.

So there you have it. Looking for something new to learn and master?

 Responsive Design 2.0: themes, accessibility, and customization

Responsive Design 2.0: themes, accessibility, and customization. It only takes one innovator with one great experience to show what is possible and to change our users' expectations forever.

Award-Winning Technology Products