Build a site on a single domain, but detect mobile, and render a separate mobile site
Build a separate mobile site on a subdomain
It’s funny how quickly huge industry-defining conversations fade from view. This was probably the biggest question in web design and development this past decade, and we came up with an answer: It’s #1, you should build a responsive website. Any other answer and you’re building multiple websites and the pain from that comes from essentially doubling the workload, splitting teams, communication problems across those teams, inconsistencies across the sites, and an iceberg of other pain points this industry has struggled with for ages.
But, the web is a big place.
This emailer specifically mentioned imdb.com as their example. IMDB is an absolutely massive site with a large team (they are owned by Amazon) and lots of money flying around. If the IMDB team decides they would be better off building multiple websites, well that’s their business. They’ve got the resources to do whatever the heck they want.
An interesting question was asked recently in LinkedIn’s JavaScript group:
Does JavaScript need to be renamed?
The question really got me thinking.
There’s no doubt there are problems with JavaScript’s branding:
1. The official specification for the language is actually called ECMAScript – a somewhat clumsy bit of branding on the part of the standards organisation that oversees the language’s specification, Ecma International.
2. Correctly, “JavaScript” refers to a subset of ECMAScript specified by Mozilla, but the word is used interchangeably to refer to multiple different ECMAScript supersets, depending on context.
3. JavaScript is a trademark of Oracle Corporation, which doesn’t fit comfortably with the language’s position as a central component of the web platform, which is meant to be built entirely from open technologies and standards.
4. There isn’t even an official logo for JavaScript, let alone a cute mascot like Go’s gopher or PHP’s elephant.
An unofficial, community-made logo for JavaScript. Source: https://github.com/voodootikigod/logo.js
5. And famously, JavaScript is unrelated to Java. This has confused the hell out of non-technical managers and recruiters for decades.
But for me, the big problem with the name JavaScript is its fuzzy scope. If a computer program is documented as having been written in JavaScript, that does not tell me everything I need to know to run the program. I do not know:
The minimum version of ECMAScript with which the program is compatible, or at least what JavaScript engines or runtime environments the program supports.
What host APIs – language extensions added by the runtime environment – the program depends on. Is the program intended to run “client-side” (in a web browser), “server-side” (in the Node.js runtime environment), or is it universal?
The confusion is demonstrated by the difficulty of consuming third party libraries. Browse GitHub for open source JavaScript packages that solve a particular problem, and for each solution you must dig deep into the README or the package.json file to discover if that particular JavaScript package is compatible with your own JavaScript application.
(The problem is made worse by the current period of transition between module systems: from community-derived conventions such as CommonJS, AMD and UMD, towards ECMAScript’s standard module notation.)
Rebranding JavaScript might help to clear up all this confusion.
A New JavaScript
If we did rebrand JavaScript, what would we call it?
JavaScript has already had lots of names. Brendan Eich – who designed and implemented the first version of the language – had wanted to call it Mocha, but the marketing boffins at Netscape called it LiveScript when it was first shipped in an early beta of the Navigator 2.0 browser, before settling on the name JavaScript for the final public release at the end of 1995.
Alternative implementations of the language were called JScript (Microsoft’s version for its Internet Explorer browser) and ActionScript (Adobe’s version). And various dialects of JavaScript that have enjoyed their time in the sun over the years include CoffeeScript and TypeScript.
I think Eich was right all along. Mocha is a great name. In the software space, this name conflicts only with the Mocha test framework for Node.js and a legacy decompiler for Java.
But my personal preference is to rename JavaScript to, simply, JS.
Most people refer to JavaScript by its acronym, anyway. It matches the official file extension. And we could turn that ubiquitous black-on-yellow community logo into the official emblem and not have to remake all our merchandise.
Over time, the origins of the JS name would be largely fogotten, in the same way most PHP developers couldn’t tell you what PHP stands for.
What would be better still is to come up with a standard convention to refer to the extended APIs made available to JS programs by particular runtime environments for the purpose of communication with the host system.
For example, if today’s ECMAScript becomes JS, then something like WebJS could be the official name for the JS superset that is supported in web browsers, as specified by the World Wide Web Consortium.
And perhaps there could be a ServerJS standard that specifies additional APIs that are expected to be provided by server-side JavaScript runtimes such as Node.js.
Finally, ECMAScript’s yearly release cycle and versioning convention is hugely convenient, and this should be extended to all flavours of the newly rebranded JS. Thus, WebJS 2020 would refer to a snapshot of ECMAScript plus all the web APIs that are standardised as of the year 2020.
As designers, we dream about the brand challenges we’d love to work on with the criteria often cited as “fame, fortune and fun.” But there’s another consideration that increasingly occupies our thoughts that is more to do with what we’re contributing or detracting from society. We now talk about the “purpose” of brands to underpin strategy and design. If this falls short, we’re suddenly at a loss as to how to start building positive relationships with the consumer. In today’s ever-evolving market, there’s an increasing number of brands whose purpose has become out-dated, irrelevant or in some cases just socially irresponsible. We have to ask hard questions of ourselves before accepting the challenge of making it appealing again.
I struggle to want to apply company skills on Philip Morris brands because we can’t condone the harm that smokers (inadvertently) do to other people and, despite a long career designing single-use plastic bottles, I’d rather be helping Evian find a sustainable alternative. Barbie, your days as role-model to a new generation of girls are surely numbered, whatever you do is undermined by your body proportions and out-of-touch version of female empowerment. Wrigley’s gum remains unaccountable (and unapologetic) for covering every city pavement the world over with spat-out litter. And Spam remains a totally processed meat substance with a provenance still firmly rooted in post-war rationing. As for Hummer, does the world really need a road-going, military-grade tank right now?
Should brands such as these simply fade away and join the ranks of other extinct products which failed to keep pace with social change and consumer attitudes? Or should they genuinely redefine their purpose and behave responsibly? Of course, by doing so, it would ensure that all designers would want to work with them again.
Opinions expressed in this article are those of the guest author and not necessarily Marketing Land. Staff authors are listed here.
Have you ever found yourself totally in love with a design mockup you created, only to see your client pick it apart? Even worse is when they advocate for changes you aren’t comfortable with.
Designing websites for other people can be a lot like rolling dice. Sometimes you get lucky and your client loves what you’ve done – no changes required. But more often it seems like a nearly endless process of making revisions until they’re fully satisfied (if that’s even possible).
It’s a common refrain for web designers. But we’re not totally helpless in this area. Even though we can’t fully control how our clients will react, there is one strategy that can help keep the situation from getting out of control: Explaining your design decisions, preferably right from the very start.
The Freelance Designer Toolbox
Unlimited Downloads: 500,000 Web Templates, Themes, Plugins, Design Assets, and much more!
A Proactive Approach That Yields Results
To clarify, we’re not advising that you craft a huge laundry list of every last detail. And certainly not before you’ve handed in a mockup.
What we are talking about is providing clients with a general rundown of what you did and, more importantly, why you did it. This is something that could be delivered along with your initial design.
This helps us accomplish a few things right off the bat:
It Provides Context
Clients are often more willing to accept something if they know the reason behind it. In the case of a website, this could mean anything from understanding why you chose a certain layout to why you reconfigured a navigation structure.
If your line of reasoning makes sense to them, it’s more likely to avoid the chopping block.
It Facilitates Productive Conversation
Once in a while, you’ll run into someone who is very quick to make harsh judgements of your work. This not only stings your ego, it can also make the design process that much more difficult. If nothing else, it kills your motivation and might make your client a little wary as well.
These reactions are often based on a client having a very different expectation for what they were going to see, as opposed to the design you provided. By offering up a clear and simple explanation, you can at least partially offset the element of surprise.
While they still might not love the design, the subsequent conversation can be much more productive. This will result in a better final product.
It Demonstrates Your Professionalism
Submitting a design for review with no real explanation is a bit like dropping someone off in the middle of a strange city without a GPS. Sure, they may find their way around, but it probably won’t be as pleasant of an experience.
That’s why, if nothing else, taking the time to help guide someone through a mockup reflects well on you. It shows that you put serious thought into your work and are willing to have an open line of communication. This is a great way to help build the ever-important client-designer relationship.
expert. When you provide clients with a better understanding of where you’re coming from, they can make more informed decisions.
Not only that, they will be more likely to make any changes within the framework you’ve outlined for them. That’s the difference between perhaps tweaking a font or color as opposed to ripping apart entire templates.
So, on your next project, try pointing out the design decisions you made along the way. While there’s no guarantee that your client will sign off on it without changes, you both should be in a better position to deal with what comes next.
Starting a creative agency is not something that most people have the stomach for. There are crucial hiring and marketing decisions to be made, important cash flow and time management issues to figure out, and (since you’re human) the inevitable flood of self-doubt the moment any of the above goes awry.
Spoiler alert: It will.
For most people, the decision to break away and make it on their own follows many years of freelance work or climbing the ladder inside of other organizations, and brings with it a whole new world of opportunities and challenges. In our Agency Founder Series, which delve into the backgrounds and beginnings of some of the most accomplished creatives working today, we ask each person a simple question: “What made you decide to start your own agency?” The answers differ in their deliberations and details, but the journey from seed to sprout usually follows a familiar pattern.
With that in mind, we’ve rounded up four questions you should ask yourself before deciding it’s time to start an agency of your own.
1. Why do you want to do this?
Identifying your why is the first step in figuring out how to achieve your goals and create the life and career that you want for yourself. As German philosopher Friedrich Nietzsche once said, “If we have our own why in life, we shall get along with almost any how.” There’s no record of Nietzsche’s own why for growing a mustache so flamboyantly large that it’s rumored to have scared strangers who saw him on the street— but sound advice nonetheless.
A common thread among the founders we’ve spoken with is that each one has had a strong belief in themselves and their ability to succeed on their own — no matter how overwhelmed and underprepared they may have seemed to others at the time. For some, being young and naïve was actually beneficial in their decision to start their own agency. “We thought starting a business was a bit like traveling around the world — do it while you’re young because once you start having kids or a demanding career, the time and money are hard to find,’’ says Kristen Morrison, one of the founders of Red Six Media.
Gravitywell founder Simon Bos was blunter in assessing his decision making process: “After a year of work in the real world, I arrogantly assumed that I could do a better job of running an agency than the people who were actually doing it. Not surprisingly, the first few years were the hardest!”
Not everybody has the wherewithal to start a business when they’re young and inexperienced, however. For most people, the decision to start their agency came only after gaining years of industry experience and making valuable connections. “I’d been in the agency world for more than a decade, and the most frustrating part was not being able to control the quality of your own work,” says Anton Zykin, co-founder of Clay. “Things would get rushed, clients would often change their mind, etc. I grew tired of it and decided to start a new kind of digital product agency, one that focused on quality and craftsmanship.”
Here’s the bottom line: Your “why” is just for you. If you can’t think of at least one solid reason why it would be a good idea to upend your personal and professional life and try to make it on your own, you’re never going to have the discipline to stick with it for the long haul. Save yourself a lot of sleepless nights and heartache if this isn’t something you’re 100% sure of.
The Gravitywell team putting the whiteboard to good use.
2. How will you bring in new business?
So you’ve quit your job, found the perfect space for your new agency, hired your staff, bought a ficus for the new office (hell, maybe you bought three ficuses for the office ???), and now you’re ready to hit the ground running.
Just one little problem. Who’s going to hire you?
A 2018 WordStream survey found that attracting new clients is overwhelmingly the top challenge facing creative agencies today. That’s certainly true for the majority of founders we’ve spoken with, as many found themselves barely scraping by in those early days, or forced to take on work that was out of their comfort zone. “People knew us, but nobody had heard of Clay. Instead of giving up, we doubled down on our marketing activities, which ultimately helped us a lot. We were also very aggressive in how we priced projects, trying to get as much work as possible to stay afloat,” says Zykin.
“Our first two years were hand-to-mouth,” recalls Ronnie Duncan, one of the founders of Meerkats. “We had to keep our egos in check as we attracted project-based, entrepreneurial-style clients with resources well below their ambitions.”
For others, though the transition from working for someone else to working for themselves went about as smoothly as it possibly could have. “There is definitely a slight weirdness when you’re used to having a 100 person agency behind you, and then suddenly it’s just you. We tried to communicate to the market that, despite our size, we were experienced leaders and a safe pair of hands,” says Adam Morris, co-founder of Today. “People love to share in the story of stepping out, taking some risks, and starting something new. We were genuinely surprised by how many people wanted to support it and be a part of it.”
Nick Ellis and Vern Edmonds add, “When we started Halo we didn’t have a single client, and no clue what we were doing. But we knew we could make it up as we went along and wing it until we figured it out. We were also stupid enough to believe that was true.”
Here’s the bottom line: Starting a new agency is hard work. You have to dig your heels in and get after it during those first few weeks, months, and even years if you’re going to survive. To quote a misquote often attributed to Abraham Lincoln: “Great things may come to those who wait, but only the things left by those who hustle.”
The wall of knowledge at the Meerkats office.
3. How will you address your weaknesses?
Everybody makes mistakes Everybody has those days Everybody knows what I’m talkin’ ’bout Everybody gets that way Everybody makes mistakes
Abraham Lincoln spoke those words at the White House in the summer of 1864 to the One Hundred Sixty-Fourth Ohio Regiment, who were on their way home from the front lines of battle.
Just kidding.
Those are lyrics from the opening verse of Hannah Montana’s “Nobody’s Perfect”, a song by a fictitious television pop star, who would later catapult (wrecking ball?) her way to fame as a real-life pop star.
As a matter of fact, nobody is perfect. When you start a new agency, whether on your own or with partners, your responsibilities grow exponentially. There will be things that you love doing and be great at (e.g., long-term strategy) or loath and suck at (e.g., anything HR-related). “In the early days, I was not a good manager. My background was in freelance, and I was used to working with other freelancers without much structure. So when I started Ueno my plan was just to hire good people and let them do their stuff. It took me a while to figure out that we needed to be more structured if we wanted to scale up to the level where we want to be,” says Halli Thorleifsson. “For the record, I’m still not a great manager, but I think I’m improving.”
Most of the founders we’ve spoken with were able to recognize their weaknesses early on, and either set out to improve them or handed off the responsibility to someone better suited. “Starting an agency is relatively easy, but sticking it out for years (decades even) means consistently going the extra mile,” says Andrew Hoyne, founder of Hoyne. “Recognize that you’re not that great, but if you stay hungry and work your guts out, perhaps you will be one day.”
Here’s the bottom line: You won’t be great at everything right away (or even good for that matter). That’s okay. As long as you stick to your strengths, acknowledge your weaknesses, and aren’t afraid to delegate responsibilities to your team, you’ll be doing more than most.
The team at Ueno gather around for (the last) supper.
4. Is now the right time?
Unfortunately, there is no hard and fast rule to live by when it comes to starting your own creative agency. There may not be an “aha” moment for you—no light bulb will appear out of thin air above your head, no swelling of music before your triumphant declaration, and no bat signal in the night sky signaling that duty calls.
Some of the founders we’ve talked to felt that they’d simply outgrown their lots in life and it was time for something new. “We were too ambitious and curious to carry on working for someone else, and we craved variety and felt the need to take control of our own future,” note Will Pepperrell and Ben Richardson. “It was a brave leap forward, but we thought we’d gained enough essential experience and that we had all the tools we needed to start Stepladder.”
For others, the decision was collaborative and well thought out. “Validating your ideas means you need human interaction. If starting up feels lonely, you probably aren’t speaking to enough people. Get experienced friends, people you’ve met on forums, consultants, family, etc. that understand your objectives and are able (and unafraid) to give you constructive criticism,” recommends Jonathan Smith of Catch.
Perhaps Justin Tan, co-founder of Turtle, sums it up best: “Ultimately, we asked ourselves, ‘What’s the worst that can happen?’, and there really wasn’t an answer that scared us!”
Here’s the bottom line: While everyone’s experience is different, there will be a moment when you look around at your life and your career and you realize that starting your own creative agency is not such a far-fetched idea any longer. The decision is yours whether or not you choose to act on it.
To find out more about what it’s like to run your own agency, straight from the mouths of the people who are actually doing it, check out the full interviews at Agency Founders Series.
If you’re interested in a simple, fast, and visual resource planning tool for your team, try Float free for 30 days.
The term ‘responsive web design’ has been a mainstay in the world of digital development for many years. Go to any early-stage client meeting and you’ll almost always get asked to ‘make sure it works on mobile’.
The standard response to this has generally been, ‘don’t worry, we’ll build it responsive’, but is this response out of date?
The limitations of responsive web design
The main ‘tool’ of responsive web design is the ‘media-query’. This lets us apply a subset of CSS only when a website is rendered at a specific size, orientation or when some chosen environmental criterion is met (for example, light level). This allows a front-end developer to easily manipulate how a website, digital product or app displays on different sized devices, or as a window size changes.
However, I’m starting to think that tying rules about how an element should display to the size of the overall page or device is very short-sighted. This is especially true in today’s world of component-driven design.
Component-driven design changes everything
Today, in modern web design, we usually build highly re-usable, environment agnostic components using methodologies such as Atomic Design, often with the aim of building out a pattern library to be used across a variety of applications. This approach saves time and money, as it reduces the need to duplicate work. There is a burden, however, as each individual component needs to be robust enough that they work appropriately when dropped into containers of different sizes.
For example, if we built a news item preview component, with an image above a text excerpt, this may display in a wide container (e.g. an index page), or within a sidebar (e.g. related articles). If we write a media query that changes the news item’s display based on the size of the viewport (for instance placing the image alongside the copy instead of above it) we will be limiting the contexts when this item is useful. This is because if the viewport is wide, the rule will apply, even if the component is being used in the sidebar where it doesn’t have adequate space.
This is the crux of my complaint; media queries are very manual and explicit. Instead of defining the ideal state for a component, we are forced to place it in context and test how it works in relation to the canvas, and then manually adjust. If you’re anything like me, you’ll find yourself doing the adjustment optically and then explicitly writing rules to tweak the display to your liking. If the page layout changes – and therefore how the module sits on the page – you will likely have to reassess these rules. This creates a huge maintainability burden and makes it easy for components to visually ‘break’ at certain viewport sizes, unbeknownst to the person making the changes.
Responsive web design, up to this point, has been concerned with the canvas, but what is really needed is a component-driven mindset.
Intrinsic web design
In 2018 Mozilla Designer Advocate Jen Simmons coined the term ‘intrinsic web design‘. This methodology takes a more content-out approach to digital design. Instead of changing styles based on the size of a viewport (or how big the screen of the device is), components automatically lay themselves out based on their own ‘ideal’ conditions.
Photo by Jeffrey Zeldman: https://bit.ly/2PuUYei
For instance, instead of saying at 768px wide, the news article image sits above the text instead of alongside it, we could give more rough guidelines: ‘the image should span the full width of the parent, but ideally be no bigger than 250px wide’. Then, when the image hits 250px, it will automatically move to sit alongside the text.
We can describe responsive/adaptive design as an imperative approach – you are describing explicit behaviour to occur at an explicit width. Intrinsic design, meanwhile, has more in common with a declarative approach; we are providing guidelines, but leaving the precise implementation up to the browser.
Flexbox, grid and multi-column layout
Intrinsic design is largely enabled by new(ish) layout methods such as CSS Flexbox and CSS Grid (using auto-layout). These are all complementary technologies and don’t replace one-another – Grid is two dimensional, Flexbox is one-dimensional.
Below is an example of how we might use CSS Flexbox to create an automatically adapting media-query-less component:
ul {
display: flex;
flex-wrap: wrap;
}
li {
flex-grow: 1;
flex-basis: 250px;
}
This is saying that when list items get smaller than 250px, they should wrap. 250px is their ‘ideal’ size, but they can grow to fill additional space.
ul {
grid-template-columns: repeat( auto-fit, minmax(250px, 1fr) );
}
This is saying, when columns get smaller than 250px wide, they should occupy their own row. We don’t need to explicitly say when to switch layout, instead, we are providing a content-driven rule. It is not bound to the viewport size, but the width of the content itself, so can be used within nested elements. If the grid is used within a small sidebar, for instance, it will be a single column, while if it is also used in a content area next to the sidebar (larger than 250px * 2), then it will split into columns.
Alternatively, we could use CSS multi-column layout with the column-width property:
ul {
column-width: 250px;
}
The behaviour of these three examples are all subtly different, with variances around the width of the wrapping items, and the distribution once they wrap. However the premise is the same: we advise the ideal width of an element, and let the browser worry about when and how to wrap.
These examples are ‘contextual’ and more ‘responsive’ than responsive web design, since they respond to their environment, not the viewport.
Bring on container queries
I expect that at some point in the future element or container queries will be introduced, and this post will be rendered moot. Certainly, until that point, it’s hard to fully do away with media queries, as much as I’d like to.
In the meantime, it is possible to point to the clever work that’s been done to make components responsive to their parent, not the page width. However, to me, a lot of these solutions are restrictively contextual.
So, where does that leave us?
Well, no, responsive web design isn’t dead, but we are at the point where we’ve evolved past what most people mean when they use the term. We’re no longer just trying to fit the things we make to varying screen sizes.
Instead, we’re now building digital products in a more flexible, module-driven way, and we have better tools now than five years ago that make working like this easy. We’re designing at the modular level, rather than the screen size level, and we’re moving to a more declarative approach. It’s still responsive web design, we’re just responding to a subtly different stimulus.
Suzanne Scacca is a former WordPress implementer, trainer and agency manager who now works as a freelance copywriter. She specializes in crafting marketing, web … More about Suzanne
Scacca …
Apps are no small undertaking. Nor are they cheap to build and maintain. So, before you move ahead with creating a new mobile app or SaaS for your client, perhaps you should consider launching a minimum viable product (MVP) instead. With an MVP, you have a low-risk and lower cost way of testing your concept on the market. What’s not to love about that?
Can you afford to gamble on an idea for an app or on an assumption about how consumers will respond to it? I bet your clients aren’t too comfortable doing that either, especially when it’s their money and reputation on the line.
An app can be a risky investment for a business if it’s not approached with care. Even then, the most well-researched of app concepts can lead to disappointing user download and retention rates.
Whether you’re in the business of building mobile apps or SaaS products, have you thought about using minimum viable products (MVPs) to safeguard your clients’ investments?
Not only do MVPs allow you to get projects through your pipeline more quickly, but they enable developers to create stronger products overall for their clients.
Here’s what you need to know.
The Value Of MVPs In App Development
Frank Robinson was the first to define what an MVP was back in 2001. At its root, an MVP is a scaled-back version of a product that’s released to the public for the purposes of testing and validating the product’s concept and viability on the market.
Eric Ries, the author of The Lean Startup, was one of the early advocates of MVPs and he had some interesting things to say about why and how we should use them back in 2013:
The point isn’t to create leaner products. It’s to get the most basic version or concept of an app into the hands of adopters and evangelists. That way, the developer collects user feedback early on that, in turn, is used to properly shape the product into its final version.
Take Dropbox, for example. This is what the product’s landing page looked like back in 2009:
It’s a simple page that includes the company name, an explanation of the software and a link to download the desktop or mobile app. For users that want to know more about what they’re getting, the “tour” took them to a mini-site with more information:
Dropbox’s MVP provides basic details on its software. (Source: Dropbox) (Large preview)
That’s a far cry from the powerhouse storage, content creation and collaboration service that both consumers and businesses use today:
But that’s the beauty of the MVP. Essentially, it forces developers to build products with only the minimum — but absolutely essential — set of features.
Dropbox didn’t need to foresee the power of cloud storage services or to create something that wasn’t right for the market at the time. All it needed to do was launch a simple solution that users needed then and there. Users could then validate the product and provide the company with the direction it needed to take its product.
There are other benefits to creating an MVP:
You can get the product on the market much more quickly than if you were to wait for the full app to be developed.
You get a chance to test the viability of the concept before you commit too many man-hours to the job.
You give yourself more room (and maybe even a little forgiveness, too) to work out the kinks in your final product.
You save money with an MVP. First, because you only spend time building features that are absolutely needed. Second, because you might find that users are content with the scaled-back version and you won’t need to do much more work to finalize the product.
With a tested idea that’s been embraced by users, you have something to bring to investors which could make the rest of the development process go much more smoothly.
As Eric says in the video, an MVP is the best way to maximize your chances of success and to do so in a much shorter timeframe than complete product development allows for.
How To Build A Valuable MVP That Users Want to Test
Your MVP’s success rides on its ability to leverage insights and feedback provided by early adopters — the ones who are 100% on your side, believe in the product and want to help you fill in the gaps. So, don’t lose sight of that.
An MVP is not some half-assed app thrown together. It still needs to be valuable.
Here are some things you must do before you build and launch your MVP:
1. Decide the Product’s Purpose
If you want your app to succeed, it needs to uniquely solve a problem for a large segment of the consumer base. That means your MVP needs to clearly break down what the product does and why users need it.
For example, this is how Uber (then UberCab) sold itself during its beta in 2010:
The website for Uber’s predecessor, UberCab, in 2010. (Source: Uber) (Large preview)
Like the Dropbox example earlier, it’s extremely simple in concept and no-frills in terms of explaining what it is or why it’s so valuable. But you still get the idea. It’s an app that lets people order and pay for a car from their phone. Essentially, it’s a convenient substitution for cabs.
Jump ahead a year, you’ll see that Uber started to firm up its identity and value proposition with its official product launch:
Uber starts to refine its image in 2011 after beta testing completes. (Source: Uber) (Large preview)
This was back in 2011 when Uber dropped the “Cab” and labeled itself an on-call private driving service. It was a way to let consumers experience certain luxurious privileges they might not otherwise have been able to afford.
Although that’s not the final form Uber ended up taking, you can see how early user feedback helped the product developers decide which parts of the platform were really worth highlighting and building upon.
This is exactly the kind of thing that will happen when you build an MVP and start to gather valuable insights from users about what they want and which features they need. But, first, you have to start by getting clear on its general purpose and value. You can refine it later on.
2. Locate Your Ideal Users
You have your concept. Now, it’s time to figure out if consumers are going to want it. Even though an MVP is cheaper and faster to build doesn’t mean it won’t end up a complete waste of your time and resources. You have to at least confirm that the interest is there and then define, in clear terms, who your target user is.
Specifically, you need to think about location.
In the Uber example above, you can see that the beta product was only tested in San Francisco.
The initial version of Airbnb did something similar. Joe Gebbia, the co-founder of Airbnb, tells the story of his MVP on a 2017 episode of How I Built This.
Basically, he was low on cash and decided to rent out air mattresses in his San Francisco apartment for an upcoming conference. Knowing that hotels would be short on rooms, he figured he could make money off of it. But it wasn’t just rent money he made. He got an idea for a new business after a lot of people showed interest in renting space in his apartment.
So, he and his partner created a website called “AirBed & Breakfast”. Once it went live, though, it spread far beyond the original San Francisco test area.
An early version of the AirBnB concept from 2009. (Source: Airbnb) (Large preview)
In 2009, there were AirBnB rentals in 72 countries. Today, you practically have your pick of the litter in any town around the world. But it all started with San Francisco.
So, as you set about building your product, think about where the best places will be to test and get feedback on your app before you do a full release of it. You want the area to be a good representation of the population and demographics you aim to target. You also have to make sure there’s a demand for the product and that your target users can afford to use it (once you start monetizing).
3. Choose an MVP Format
The format of your MVP is another important thing to think about before you do any building.
In some cases, you’re going to have to build a workable product. For example, let’s say your goal is to build a new dating app. There are tons of dating apps on the market; with two apps, in particular, that continually dominate the pack. You know that building any sort of mobile dating app would be a huge and costly gamble, no matter how much you cut back on features. So, what do you do?
You could build a PWA dating app instead. The costs would be lower, the time-to-market significantly faster and it would be much easier to get your MVP in front of users than if you were to put something on the app store. You might even find that the PWA suffices in terms of product format in the end.
In other cases, the MVP won’t even need to be an actual product. It can just be a website announcing the product or providing a wireframe/prototype of the concept.
In 2018, Rand Fishkin announced that he was leaving Moz, the company he co-founded in 2004. Simultaneously, he announced a new product called SparkToro.
The SparkToro MVP landing page describes the upcoming product, but doesn’t provide access. (Source: SparkToro) (Large preview)
Now, Rand is someone who can launch a concept as an MVP and for it to still be successful. He has a long-standing history and solid reputation in this space, so, of course, users are going to gravitate to this new product despite it being unavailable for consumption.
For those of you building an MVP for a new brand, you probably won’t get so lucky. However, it’s really going to depend on what type of product you’re planning to build.
If there’s absolutely no way to create the product in a scaled-back version, then this could be an option worth exploring. It would also be a good idea if you or your client have absolutely no funds and need validated feedback to prove the viability of your concept to investors. That’s really the only way I see Joe Schmoes getting away with this.
If you do go this route, you’re going to need a really good explainer section, too. This is what SparkToro has on its What We’re Building page:
SparkToro’s website explains what it’s working on building. (Source: SparkToro) (Large preview)
I think for the kinds of users that would gravitate to a product like this — namely, advanced marketers that actually need this kind of solution — this way of testing the concept and viability of the features is good. It’s written in their language and with visuals they understand.
However, for users that aren’t familiar with your brand or aren’t as well-trained as Rand’s audience, a wireframe or prototype of the product’s dashboard would be a better idea. Even an explainer video from the founder would work well. It just needs to be something that convinces users to sign up and start providing feedback as early as possible.
4. Find Your Actual Minimum
If you watch the video of Eric Ries, you’ll see that he provides a formula for defining the minimum features of your MVP. It goes like this:
# of minimum features you think you need / 8 = The True Minimum
It makes sense if that formula makes you feel apprehensive. But think about it like this:
You build an MVP that is as simple as it can possibly be without it becoming useless. You ship it out to users and give them a chance to provide feedback.
A few things might happen as a result:
They absolutely hate it.
They complain to you about how Feature A sucks and how they wish it did something else or how Feature B was almost there, but then fell short of expectations. That’s perfect! Your test users will tell you exactly what they want from your product. Get enough consistent feedback and you’ll have a list of must-have features that need to appear in the next version of the app.
They’re okay with it, but don’t love it… yet.
Again, it’s okay if users aren’t 100% happy with it. You’ve given them an opportunity to try out a product that’s going to be awesome and they see the promise in it. Give them a chance to speak their mind and let you know what they loved and what they didn’t. Then, focus on strengthening those weak points and including the features that will make it a real game-changer.
They’ll love it as is.
Let’s be honest, this isn’t likely to happen. But wouldn’t it be great if feedback was so scarce that you could roll with the MVP as is? Plus, think of all that time you saved yourself and money you saved your client by cutting the product back so much. Sometimes simpler is better.
Don’t forget to thank these users for their feedback and support of the product. There’s no way you could create the solution they need without their insights and so it would be in your best interest to recognize the role they play in this. In return, they’ll continue to be your product’s evangelists long after launch.
5. Design Your Landing Page Early
Although I’m not too keen on a landing page or mini-website serving solely as the MVP (for the aforementioned reason), I do think it’s a good idea to get a mobile-first landing page up while the MVP is in the works.
Gaming apps and SaaS would be especially good choices to launch a beta signup page early. Here’s an example from Hytale:
Gaming app Hytale uses its landing page to educate users on the game and get beta users before launch. (Source: Hytale) (Large preview)
If you want your MVP to succeed, you should put some of that extra time you now have towards building out a strong landing page. Start by researching the early websites from the companies featured in this post. They all successfully explained their concepts, soft-marketed their products and convinced early users to sign up for testing.
While you’re at it, you should set up your blog, social media accounts and community features (with an active newsletter), too. You never know. Someone might find the announcement of your MVP somewhere other than Google search and decide they want to bookmark the site or sign up early to be a beta tester.
It’s never too soon to start getting buy-in from your user set!
6. Define Your Success Criteria
Last but not least, you have to decide how you’re going to measure the success of your MVP. Because it’s not just about the quality of feedback.
Consider the following:
How many visitors visited your landing page?
How many of those people signed up for the beta?
How many users did you retain over a set period (1 month, 3 months, etc.)?
How many people provided feedback and was it a substantial enough set to make solid decisions about the product design and features going forward?
Did the demographics of your user set match the audience you designed the app for? Why do you think that was?
How much time, on average, did users spend inside the app?
Which features did they spend the most time with? The least?
Which features received the most favorable feedback? The least?
Were there certain users who had a positive experience with the product? What made them different?
Take all of the information you gathered — from the original landing page, the beta testers, the usage data and so on — and really look over it all. What is it telling you about the MVP you’ve designed? And, now, what are you going to do with it?
Will you leave it as is or build it out to the full product it’s meant to be and that users want?
Will it be easy to attract and acquire customers based on the usage data you’ve collected? What’s more, will you be able to retain those users or is it more cost-effective to keep your app browser-side instead of in native app form?
And, finally, how much can and should you charge for access to the product? Will it ultimately make the company profitable or is there just not enough interest (at least in the monetization side of things) to make this a worthwhile venture?
I know I’m leaving you with a lot of questions, but there’s a lot you’re going to need to sort out once the tests begin. Plus, it’s the whole reason you created an MVP in the first place. This user feedback is invaluable to the process and is the only way you’re going to know if it’s a product worth pushing out to the market or taking back to the drawing board.
expert. When you provide clients with a better understanding of where you’re coming from, they can make more informed decisions.
