What to expect
Four most common requests that look small from the outside and hide larger monsters.
It’s JUST as important: How to make sure that these requests do not end up in limbo.
Behind the Scenes: What the Storkers were up to this week.
Polar Stork Flock, Leipzig - Summer 2019
Hi there,
Last time, we talked about the cost of poor development choices. Today, we're focusing on some requests that can lead to friction with your development team without the right background information.
My goal is to help you get what you want from your product, while understanding the complexity behind it so you can rethink your approach for greater success.
The problem lies in the disconnect between the person asking (the client) and the person executing (engineering or design), and if not addressed early on, will lead to unexpected delays, subpar delivery and friction on both ends.
I will focus on just the ones that I encountered the most. If you’ve seen another kind, please reply back and tell me!
Let’s go.
We do not own exclusivity on “Just”
Just about every profession has its own example of “just this little thing”. They are all different but they share the same results.
The person delivering expects the person asking to know what they are talking about, and feel blindsided by these major changes hidden under the umbrella of “just”.
The person asking doesn’t understand why this has taken so long and cost so much if they just did “this little thing”.
"Before you judge a man, walk a mile in his shoes”.
The 4 icebergs that risk sinking your ship
The beauty of running a product studio is the sheer diversity of people and projects I get to work on.
Here are the four common situations I encountered with a lot of founders:
1. You just need to use their API
API is probably the most misused three-letters term in tech. You expect that if there is an API, then it’s a plug and play integration. The larger integrations have a more comprehensive Open API, and usually pretty well documented, but it’s not the case with every 3rd party.
An API is a tool, a function that takes a specific input and returns a specific output. The developer of the API decides what you get access to, what they need from you, and what they return to you.
There might not be an API for the exact capability you require. Unlike direct database access, where you have full control, it might only give you the customers based on their ID not their name, or the last 5 transactions, not all of them.
You need to format the data to input as well as the data to output. If the API needs a phone number to retrieve the balance, you need to fetch the phone number of your user, format it the right way and give it to the API to return your balance.
You might need to use multiple APIs to achieve the functionality you had in mind.
You need to authenticate with that API.
You need to test your full flow because you’re responsible for all the steps around that API.
You need to stay updated with the changes that this developer has made on their API. You’re dependent on the way they built their data.
What you’re probably thinking about
An SDK (Software Development Kit) is a client library that wraps an API to make it easier to call. That’s already a better starting point for your development team
Zapier is probably the reason why everyone thinks an API is all you need. Their visual interface allows you to integrate multiple preset tools together, with preset scenarios. This ease of use comes with its own limitations of capabilities, of course.
2. Make this blue slightly lighter and move it 5 px to the left
Congratulations - you just triggered your developer and your designer in one go. To establish consistency and scalability in a product, the design team defines a “design system” at the beginning of the project. The various tones of colors and when to use them, the grid on which all elements will stick, the borders and margins, the font, the buttons, the dropdowns and so much more.
The design system is what allows your product to be consistent across multiple screen sizes, across pages, it allows the builders (both designers and developers) to reuse components that they have validated to work well together.
We had one client who wanted the hue of the blue on the button to change based on the background color. It is doable, but it adds a lot of complexity (i.e. cost and time) for something that might not be mission critical for you.
Clients who ask for a small change in spacing, end up making more and more changes to the screens to "reestablish the equilibrium” and end up with an unmanageable and unmaintainable product. The number of pixels are also based on the number of columns, so messing up with that will guarantee discrepancies when you move to different screen sizes.
My advice: Review the design system, ask the questions that bug you, and trust your implementation partner. There are commonly used design systems like Google Material Design that you can use as a foundation, and tweak with your brand details.
If you insist on making a change, make it at the design system level - change all blues to a new blue - not on a specific element.
3. I just want to replace a field on this form, only for new users
The “only” is misleading. You think that by applying the change only to a subset, you’re making it easier. As if it was updating 5 rows on a table instead of the whole table.
Instead, it’s more like 14 steps of hope-and-pray:
1) This field’s value is being retrieved through an API,
2) pushed through another API, 3) stored in a database and
4-10) used in a bunch of other functionalities. It was a number used in calculations and now it has become a text that
11)has to be converted to numbers, so we
12) need to modify all the old data. If that wasn’t bad enough, if the product is in use by real users, we want to make sure that
13) this will not impact anyone, and
14) if it impacts a few use cases, that we have a solution for them.
My advice: Plan, mock and simulate as much as needed before building the first line of code. But the best wy to handl business changes is to do a proper assesment and mapping in the beginning, to keep these changes as minimal as possible.
4. We just want an AI feature
This would not be complete without the most famous 2 letter words (that is worth 2 points in Scrabble, except for Dutch). We will focus on AI in separate issues soon.
AI is a means to an end: you have to define what you want to do, and if AI can help you achieve it faster, better, or cheaper, it's worth assessing.
AI prototypes are very easy to build, too easy. The challenge comes with the scale, the volume of data, the lack of accuracy, the security, the bloating and evidently the price.
For example, when building AccessLens, a majority of our assessments on accessibility are made using old school deterministic programming. The token cost of using AI would have been incredibly high.
On Movana, we’ve used AI to detect the pieces of furniture in an image. You can drop the image in Gemini and it will return a list of items. The real challenge lies in processing multiple images, processing jobs, multithread cropping, memory management to prevent bloating, managing network, managing failure, keep the UI fully responsive, handle background processing and so …much … more…
My advice: Don’t start the sentence with “I will use AI to” but rather “I will build a feature that does this impact for these users. There might be a part of it that is best solved using AI”. AI is an expensive buzzword.
I still need “just this change”
The purpose of this post was to give you context about what you’re asking for. An app is a living product, and we rarely start the project with the exact requirements because every feature you build inspires a new one. As long as we have our north star, the KPI that we aim to reach, we can modify, pivot and change along the way to find the best path to achieve it within scope.
Forcing a change within the timeline and the budget will usually end up with one of 3 outcomes:
A half-baked feature
A delay in delivery
A change that was not actually needed.
We recommend a conversation, to challenge every new change to make sure it’s not a rushed impulsive decision, and then instead of moving the delivery date or the budget, swapping out the lowest impactful feature on the roadmap.
As Lavoisier's law puts it “Nothing is lost, nothing is created, everything is transformed.”
That law still stands.
Thinking about a build right now, or unsure whether a quote you've been given holds up?
Just reply to this email. I read every one, and I'm happy to give you an honest second opinion, no pitch.
News from the Nest (Design team)
At Polar Stork, we believe the best digital experiences are the ones everyone can use. Over the years, we've helped startups, nonprofits, and growing organizations transform their websites through better UX, accessibility, and inclusive design.
That's why we're excited to launch our very first free webinar on Accessiblity next week:
Wednesday July 29, 4pm EST.
Reply to this email with “I’m in” and I’ll follow up with you.
Join Maleh and Deisy as they share a simple framework to evaluate your website, uncover opportunities to improve user experience, accessibility, and conversions, and review real websites live. You'll leave with practical ideas you can apply right away, whether you're planning a redesign or simply looking to create a better experience for your users.
Join us and discover practical ways to create better digital experiences!
