The startup phase can be a wonderful time for mobile app design companies. Free of the rigid constraints of a larger organization, workers can collaborate in an informal structure that fosters creativity and the development of new skills.
But as the organization grows, that informality can become a hindrance. Instead of a small team wearing multiple hats to handle design, development, marketing, and other tasks, you have a larger staff with more specialized duties. There’s too much going on for everyone to be involved in key decisions — and that can spell disorganization and projects that end up dead in the water.
Here’s how to grow past your freewheeling startup days and start designing for scale.
Prioritize Your API
APIs are often a low priority for apps early in their product life cycle — and there’s a good reason for that. If you’re just trying to get a product to launch, why bother with an API? After all, if your product never gets wide adoption, it’s a lot of wasted effort. You can always go back and build it later once there’s a demand for it.
Although these are all reasonable arguments for a company working on a shoestring budget with an unproven product, once you start designing for scale, they become less convincing. In fact, there’s a growing movement among developers and other mobile app design professionals to build the API first.
According to François Grante, co-founder of Hunter.io, you can save work, improve productivity, and even help your marketing position by starting with the API. The most obvious benefit is that the API speeds up development. It greatly reduces the amount of work you have to duplicate as you adapt to new mobile platforms, or build complementary functionality in plugins and websites.
Equally as important, the API insulates developers from unnecessary complexity. Your frontend devs don’t need to understand the structure of the backend in-depth — as long as they understand how to use the API, they can do their jobs.
For Hunter.io, the API also helped from a marketing perspective. When they launched their first product — a tool to find email addresses associated with a domain — Hunter opted to launch the API and app simultaneously.
For non-technical users, the app was a useful product on its own, enabling them to connect with people more easily. For technical users, the API made it even more valuable, because they could start adapting the new tool immediately to their own needs. This gave them a revenue stream right away, even though according to Grante, “the tool was still too minimalist to be sold alone.”
Some of the other benefits include:
- Retention: Once customers use your API, they depend on your technology, which makes it less likely they’ll leave.
- Faster Product Release: If your API is valuable in and of itself, you don’t have to wait until your interface is perfect to release. As soon as the core functionality is ready, you have a product.
- Support for Idiosyncratic Use Cases: Your customers can build their own custom apps around novel use cases you might not be able to address in-house.
- Inspiration for Product Improvement: As you get a vibrant community of developers, some of them will have great ideas that go beyond their own internal apps. You can produce new APIs and app features to address these use cases.
That doesn’t mean that everyone should start with an API. Some APIs may be too niche to scale well, which decreases the benefit significantly.
Releasing an API also requires you to split your attention and resources between serving the developers who will actually use the API and your core market, which is not always feasible or desirable. Grant points out that developing an API can also make it harder to identify the most common use cases, as developers use your product to meet their own needs — which won’t necessarily match the needs of your other customers.
This can lead to product management mistakes and poor priority setting. However, you can address this challenge by focusing on customers. “You need to be proactive talking to your customers and creating appropriate content to help customers use your API depending on their needs,” says Grant.
Even when an API isn’t useful from a marketing perspective, it may still be worth prioritizing when designing for scale. After all, the earlier you create it, the more work you’ll save your developers, and the easier it will be to upscale what you’ve already made.
Drive Innovation with Talent
When mobile app design companies scale up, they typically focus on structural changes to their production processes. They consider new infrastructure or third-party providers to help them manage a larger user base or market to a mass audience. They try out new product management approaches to increase efficiency and replicate earlier success.
While these kinds of factors are crucial in designing for scale, there’s a danger in focusing on them too intently. Companies too driven by the mechanics of internal innovation can paradoxically lose track of what really drives innovation: the people. Because ultimately, no matter how good your tools are or how shiny and new your infrastructure is, without the right people, your company won’t succeed.
This is even true for big companies with substantial infrastructure costs, like Evernote, as VentureBeat noted:
“Here’s a crazy tidbit about Evernote’s infrastructure costs: They’re almost nonexistent.
Why? Because servers, bandwidth, and overall infrastructure are cheap — so cheap that, for Evernote, they pale in comparison to the real costs: people. For [CTO Dave] Engberg, the real goal should be ensuring that your talent is happy, well-compensated, and not spending time on projects that come with a lot of work but little payoff.
‘Hardware is cheap, so you should be innovating on it as little as possible. Startups should focus on the most established stable commodity infrastructure and then focus on their core businesses and people,’ he said.”
To design for scale, you need to empower your team. Treat them as fungible work units, and you’ll drive off good people and shoot your company in the foot. But treat them as valued collaborators, and you’ll be able to harness their skills and innovative ideas far more effectively.
When scaling your startup, remember to focus on supporting your workers, so they’re happier and more effective. Hire staff for positions that make everyone else’s job easier. Streamline or automate routine and time-consuming tasks, and make sure employees are well-compensated, rather than just focusing on pushing everyone to work faster.
Use Design Thinking to Design for Scale
Focusing on the needs of employees is not only a good basis for scaling up — it’s also a key ingredient in scaling the actual structure and processes of your organization. Design thinking solves problems like scaling up by focusing on human needs and experience. This enables them to do more with their teams and resources without sacrificing creativity.
Design thinking has five phases leading from Empathizing to Testing (one of the most important and often neglected stages in mobile app design and development). The process then can be iterated on as needed to solve various components of the main problem.
Empathize
There’s a difference between knowing your stakeholders and understanding them. Design thinking ambitiously aims for the latter. In the Empathize stage, you try to understand the problem you’re trying to solve from the perspective of the people whose problem it is.
The Interaction Design Foundation recommends consulting experts, “to find out more about the area of concern through observing, engaging and empathizing with people to understand their experiences and motivations, as well as immersing yourself in the physical environment so you can gain a deeper personal understanding of the issues involved.”
Realistically, a mobile app design startup may not have the budget for experts. However, they can develop an understanding using the resources available, such as the experiences of different team members, volunteers or family members, user interviews, online surveys, and research.
Define
In the Define stage, you produce a problem statement, using your knowledge and understanding from the Empathize stage. As with the previous stage, you should strive to build your concept of the problem around human needs you’re trying to solve.
For example, imagine your mobile app design company is releasing a new, multiplayer game called Laser Ray Arena early next year. You expect the game to create a 20% increase in demand on your computing resources in the first month and high but unpredictable growth over the first 6 months. Likewise, you need to ensure your infrastructure can accommodate it by end-of-year.
A traditional way of phrasing the problem might be “we need to put a system in place by December 31st that can accommodate an immediate 20% surge in users, and scale up to accommodate further growth.” A design thinking approach would be phrased much differently:
“We need to ensure all our new users can enjoy Laser Ray Arena next year.”
That might seem a little arbitrary. Why not phrase the problem around the data you know about it and the steps you need to take?
The simplest answer is that the traditional phrasing may not address the core problem. In fact, it’s skipped right from the problem (“new users need to be able to enjoy Laser Ray Arena”) in favor of a proposed solution (resizing the infrastructure around a certain predicted rate of growth). There are a lot of assumptions the traditional approach makes, which need to be investigated further — for example:
- Your user growth predictions may be way off.
- You may have unused resources which can be tapped to address this problem.
- Usage patterns may be different than you’re anticipating. E.g., your new users may spend less time on your app than you anticipated.
- Your existing infrastructure might already have scaling capabilities of which you’re not aware.
Ideate
Now that you’ve researched and framed your problem in a human-centered way, it’s time to start brainstorming.
During the Ideate phase, you will focus on letting the ideas fly so that you can create the best possible solution. Unconventionality is encouraged. Users will use ideation exercises to think of new ways to view the problem, as well as ways to solve it as phrased.
The goal is not to isolate the one perfect idea, but to examine the problem from every possible angle. Once you’ve done that, you can winnow your input down to one or a small handful of ideas — depending on your resources.
Prototype
The Prototype phase is where you build a model of the solution (or solutions) you’ve identified in the earlier stages. For our imaginary startup designing its new release for scale, this might include anything from building out automated scaling routines to investigating and implementing tools available in your current platform, to demoing third-party software and services.
It’s important to keep users in mind, even when you’re building out complex technical solutions. This is especially crucial for startups designing for scale. A lot of startups use an informal approach to problem-solving, where everyone wears multiple hats to do what’s necessary.
As you move to a more mature approach based on more formal metrics and procedures, it’s easy to start drifting away from actual problem-solving in favor of the numbers themselves.
Test Phase
The Test phase is arguably the most crucial stage for relatively young companies scaling up. As a young company, you may have minimal organizational experience and data to draw from so thorough testing can help you vet your decisions more effectively. Additionally, a good testing program is a worthwhile goal for designing to scale.
To get there, you’ll need to evaluate your testing processes, their outcomes, and the ultimate success of your projects — essentially, testing your own testing procedures. It will take some work, and there will be mistakes along the way. But in the long run, it’s worth it to make sure your organization doesn’t just grow into a bigger organization, but a better one as well.
Building Design Systems
Design systems are ambitious projects, but the goal is worth the work. With a design system, companies can build out not only a coherent design language but a modular approach to designing for scale. Each component of the process has rules for combining with other components, making it easier for others to replicate results, which streamlines design and development.
The same goes for processes. Companies build modular workflows that can be reassigned to new projects and challenges as they come up, preserving innovation while improving efficiency.
For startups in the midst of a growth period, it can be helpful to think of a design system as an ongoing approach or initiative, rather than a deliverable. As you continue to explore new ways to scale mobile app design, development, support (and hopefully, adoption and revenue!) you’ll be able to fine-tune your design system to meet the needs of your company.
Prototype for Scale
Prototyping is one of the most important tools and processes for designing for scale — in fact, it’s nearly impossible to effectively scale up without it. Prototyping makes design systems effective, helps you get good ideas and harness creativity, and has the potential to tremendously increase productivity.
Proto.io is a mobile app prototyping tool that can scale with your company. Whether you’re a new startup looking for a flexible, user-friendly prototyping tool, or a rapidly expanding brand in need of a more powerful tool to upgrade your product cycle, we’re here to help.
Proto.io lets anyone build mobile app prototypes that feel real. No coding or design skills required. Bring your ideas to life quickly! Sign up for a free 15-day trial of Proto.io today and get started on your next mobile app design.
How are you designing for scale? Let us know by tweeting us @Protoio!
