44
loading...
Designers, know your API
As a follow-up to zero-1-2-1000-error and at the risk of being perceived as the lazy programmer who can't be bothered with "pretty pictures" (I'm not, I love building product experiences as much as you do designing them), I have another suggestion for designers that I think will help us work better together: know your API.
I love it when I work with a designer who knows the API (i.e. the services and the content/data those services provide). They come across as smart and more prepared.
The problem is when a designer is unfamiliar with the API they often incorporate content into the design that is not available. This results in broken expectations among stakeholders as a design that was understood to be ready for implementation is discovered to not be possible because part of the content is nonexistent or inaccessible to a developer.
These kinds of misses put a drag on the product development process as developers have to rush to reprioritize API work to support last-minute needs or designers have to go back and rework the design without this data.
Being agile rarely helps here in my experience because this situation doesn't really allow for forward momentum as other non-blocking changes do. The problem can be avoided by getting to know your API. Here's how to do that:
How odd would it be if an automobile designer didn't know that tires come from a 3rd-party supplier and no, they don't make them in red? The designer doesn't need to know anything about rubber compounds or the science behind water evacuation, but they should know tires come from Pirelli and they're only available in black. The same is true here.
Virtually every app depends on one or more services for its content. Find them. If you're lucky, engineering will have a service directory or other documentation. Otherwise you may have to piece together tribal knowledge yourself.
API documentation is for consumers of the API. Like Product Managers, designers are indirect consumers of APIs. What is available to them (and developers) is available for you to get familiar with as well.
This might mean getting out of your comfort zone. You don't have to know REST or GraphQL or gRPC or SOAP or the underlying tech stack or how to code, but you should know what content these services have and don't have. Content truly is king and getting to know the king is how you show your loyalty!
For example, when designing a user profile page you should already know if age is or isn't available before designing for that content. Let's call it the API research stage. API research needs to become part of every designer's existing research process. Don't just "spray and pray" expecting others to tell you if you're hitting the target. Design is too late in the overall product development process for that.
If you don't know for sure that a piece of content is available and you can't find an answer from the docs, just ask an engineer. We want to help! Finding out during implementation that you were expecting to have something in the design that we can't get sets off a series of events that suck up a lot of resources. Everyone wants to avoid that situation, so ask early and often.
Everywhere I've worked we've had a support channel for our services that folks could go to for help. Find those, join them, and ask questions. Good technical teams will welcome questions from design because it's a good sign their service is adding value to the product!
Some readers are already here at #4 in their mind. This one is the most high-impact of the four.
When you're familiar with the APIs then you're able to anticipate what can and can't be designed at this time. This means you can help stakeholders understand your needs and get the ball rolling on new and exciting features not yet possible. Front-end engineers don't usually know what designers know about evolving product ideas, so you are better situated to initiate these conversations, but you can't if you don't know the API.
I think this last one is the primary distinguisher of design leaders. All designers can push pixels, most can design intuitive experiences, but few have the depth of knowledge needed to lead in this way.
Knowing the API and designing for zero-1-2-1000-error are two simple, but very beneficial practices designers can do to make implementing their designs more predictable and complete as well as improving the design-build relationship overall.
Next time you sync up with a dev on a new design, drop some API knowledge on them. Even this guy will be impressed!
44