Over a decade ago, at the beginning of the modern smartphone era, app design remained the province of graphic and interface designers who specialized in creating websites or native software or interactive multimedia design. These early frontend designers sketched ideas, built wireframes, simulated interfaces, and previewed animations and interactions using an ad-hoc assemblage of tools.
Since then, entire disciplines now exist that tease apart the process side of creating an app, notably user interface design and user experience research and design. Once, a single boat builder would cut the timber, mill it, join it, make it seaworthy, and hand it off to a sailor. Now, the industry prefers to buy its wood from a lumberyard, commission designs from ship architects, and assign woodworkers to their unique tasks.
Ask anyone in UI, UX, or frontend development how they ply their trade and theyʼll rattle off a lengthy list of tools they’ve used across their careers: Adobe Photoshop, InVision, Sketch, Adobe XD, Axure, Balsamiq, Justinmind, Framer, Marvel, Adobe Illustrator—even Google Slides, Dropbox, PowerPoint, and PDF. (Programmers will laugh knowingly at this list: Even when backend development environments are relatively unified, a plethora of additional tools and hand-off processes permeate the workflow.)
But modern design and development processes require better integration and communication than these tools currently provide. In any sufficiently big project, each contributor is likely to have a particular specialty; a user interface designer rarely writes the JavaScript, and a backend developer is unlikely to add specular highlights to glowing buttons. App design is a collaboration. The bigger the organization and the more complicated the needs, the more people will be involved in the design phases of developing new apps, overhauling existing ones, or making key feature changes.
Development environments and versioning systems make it relatively easy to keep track of forks and trees for frontend and backend code, especially when it comes to marking and tracking changes and rolling back to earlier versions. But what if design tools—largely a series of separate programs, each with their own interfaces, strengths, and limitations, which act, in effect, as silos—were a complete, end-to-end system?
The current many-tool approach doesn’t lend itself to speedy design iteration, quick turnaround, or the involvement of key partners across the app design and development process. Many design tools require keeping track of individual files, which means collaborators must exchange or share documents, all of which need to be kept track of. Sure, among a small group working on similar tasks, that can work. But for larger design processes with many stakeholders, managing files and revisions can reduce the opportunity for feedback. Non-designers may lack effective previews and may not have the ability to mark up or annotate designs, or to leave comments directly on the appropriate elements or version. Plug-ins can allow some apps to hand off easily to others—Photoshop is a notably rich example—but they rarely help people outside of the direct design process interact with the design itself. The right set of apps and plug-ins reduces file management and conversion, but single systems make feedback, markup, and commenting far easier. Moreover, some tools are limited to particular platforms—the macOS-only Sketch is a leading example, given its broad use in the field.
Design teams need systems that can bridge three directions: between tools (less to learn, fewer or no file handoffs), between stakeholders (everyone gets access to the same stuff with different levels of permission, from commenting to full-on modification), and across platforms (so nobody is left out if they don’t use platform X). New design environments are helping to bring about this sea change with tools that manage the entire process end to end.
Two in particular point to a new course: Figma and Sketch for Teams, which opens the desktop-specific program to a team environment and was taken out of beta in January 2020. Figma is already fully realized, while Sketch has just smashed a bottle of champagne on the prow of its new ship. Both, however, pursue a single line of creation, management, and collaborative feedback, envisioning a future in which everyone on a product team is, quite literally, on the same page.
Integrating design tools
Companies have shifted in the last decade from long product cycles to ever-shorter ones, spurred on by development techniques like Agile that attempt to overcome that old Fred Brooks maxim from The Mythical Man-Month, “Adding manpower to a late software project makes it later.”
But design and prototyping tools that introduce friction don’t mesh well with workflows that emphasize small changes, quick throughput, and collaboration. Programmers might be working in shared environments that let them build, test, and deploy rapidly, while those involved in app design are stuck assembling pieces from an assortment of tools. As design work is increasingly brought in house and quick changes become the norm, the environments have to keep up.
“The processes by which people do design [are] undergoing this big change—partly as a result of the software, and partly [as a result of] the shifting nature of design within organizations,” says Sho Kuwamoto, director of product at Figma. At companies like Uber or Airbnb, he says, “it’s not like you build a product and once every nine months you call the designer.”
Figma is currently unique in that it’s offered only as a web suite, and it provides a set of tools that encompass functions typically handled by discrete software programs. Sketch for Teams pushes more file management and workflow interaction into the cloud. However, the prototyping features remain in the Sketch app, which is for macOS only; as a result, Sketch for Teams doesn’t yet encompass a full web-based workflow.
Neither ecosystem will let you toss out, say, Photoshop or Framer just yet—it’s more likely that other tools will expand their offerings or try to match Figma’s scope—but the direction these products suggest seems inevitable. Ultimately, all design tools will need to enable faster prototyping and hand-off. It’s like bringing all the specialized craftspeople into a single shipyard, where boats can be designed and built without needing to be moved until they’re ready to launch.
Figma’s choice to build its platform on the web instead of as one or more native apps makes sense in the context of recent history. Development costs have skyrocketed for multi-platform native apps due to the scarcity and high demand of programmers for particular platforms, notably iOS. Building out in four directions at once, plus a full-featured web app, reduces the speed of change. With Figma’s relatively recent founding and launch—it left beta in 2015—the company could leverage increased browser capability and scripting performance.
For tools with histories longer than Figma, any point before 2015, the choice to make the web the centerpoint would have been unreasonable for software that focuses largely on forms of illustration and typography. It’s only recently that computational power and widely available browser drawing and scripting features have been up to the tasks the design process requires, especially real-time, multi-person drawing environments. Even local storage and offline capabilities have come a long way since the early 2010s. (There have been plenty of attempts to enable both bitmap and vector web-based drawing, but there’s a reason there’s no Google equivalent of Photoshop yet.)
The downside of a single ecosystem and cloud-based storage and tools is, naturally, lock-in. But the efficiency, and delight, of working in one environment—plus robust import, export, and plug-in options—can lessen the discomfort of a tool’s perceived monopoly, especially as existing tools shore up their capabilities.
“In the old days—five years ago—you were doing wireframes in Balsamiq, then going from that [wireframe-like] prototyping tool to the next resolution, which would be Photoshop to create buttons,” says Paul Hanaoka, a UX design manager at Liferay, who wrote about his team’s experience moving from using disparate tools, including ones they quite liked, to relying primarily on one, Figma.
Despite the power of each individual tool, the design process was always a struggle, Hanaoka says, because every tool added increased complexity. Then there’s file management, tracking, version history, and more. A project can progress through stages or fork into multiple projects that all use the same assets.
Figma’s Kuwamoto says his firm’s product reflects existing changes in workflows, rather than encouraging them. Many people spend their entire day using web apps, seamlessly moving between mobile and desktop devices, he says. “Most software hasn’t caught up with the rest of the world.” A web-based workflow “is something we’re all used to for most of the domains of work we have today.”
“What tools like Figma allowed us to do is strip away layers of abstraction,” Liferay’s Hanaoka says. He sees other tools and systems, like Sketch for Teams, following suit. “We can present a mockup to a product or project manager and get their feedback, and then we can take that same file and change the view and now share that with an engineer.”
Kuwamoto notes, “The point of the design tool is to create this conversation between the designers and other stakeholders. With better fidelity, [you can more quickly] get to the right answer.”
Integrating design and development
The combined efforts of Figma and Sketch for Teams have cut a wake in the industry, the scale of which remains to be seen. Will other toolmakers be forced to offer competing products, or will they be swamped as the two companies leave them behind? While integration seems inevitable because of the efficiency and economy it offers, will these integrated approaches ultimately remain an alternative or become the default?
If design, prototyping, feedback, and iteration become a single workflow, integration could go a step further, pushing out code that, if not precisely production-quality, has all the hooks and components necessary to wire it into an existing system, hastening the transition from planning a design change to putting it into practice.
Several tools already offer code generation or are moving in that direction, including Alva, Framer X, Modulz, and Supernova. Some can produce React code, simplifying the workflow for companies or products that rely on React for frontend development. Instead of a conceptual hand-off to a programmer, the systems give them specifics they can modify or integrate into an approach they’re already familiar with. “You’re designing with code,” says Hanaoka.
Hanaoka’s group has been testing Framer X, and what he finds most exciting isn’t so much the particular bells and whistles as the fact that “we’re taking the next step in perfect communication,” relying less on hand-offs across environments, which introduce the equivalent of translation errors. Moving straight from design into at least the first stages of code ensures that the vision stakeholders agreed on is the vision that is actually realized.
But shifting that dividing line between design and development opens up a debate about the best time and place to hand off designs within or across workflows, ensuring the most efficient implementation and the least amount of duplicated work. The answer will vary from team to team. Hanaoka says what’s most important isn’t necessarily whether a prototyping system can write code, but how effectively the tool can create a shared workspace for designers and developers. “Because there’s more transparency, it’s easier for a developer to start to learn your tool and start to talk about it.”
Ultimately, integrated prototyping and collaboration allows design (and, increasingly, development) teams to speak the same language and work in the same place, and more efficient workplaces yield more reliable products. After all, every app has to sail under its own power.