Exploring the Existing Form

Alright. Before we jump into redesigning anything, let’s take a moment to look at what we’re actually working with. Because we’re not starting from zero — we already have a form. And it has... character.

Let’s explore it, understand the rough edges, and figure out what needs to be fixed — before we start throwing sticky notes on the wall.

Observation #1

Documentation isn’t bad. But when half the interface is explaining the other half, you’ve probably taken a wrong turn somewhere. ☝️

That’s exactly what’s happening on the Posts Calendar page.

It’s filled with documentation — videos, hints, tutorials — almost like an educational portal living right next to your form.

And this raises a question.

Helpful documentation is great. But when it takes up this much space, it starts feeling like standalone documentation placed within the context — not like little hints here and there.

According to NNGroup, there are two types of help. Proactive help (shown before the user has a problem), and reactive help (shown after the user encounters one).

Proactive help splits even further into push revelations (when you actively show users something new) and pull revelations (when users choose to discover it themselves).

NNGroup defines the goal of proactive help as:

The goal of proactive help is to familiarize users with an interface.
Proactive help can be implemented through tutorials, instructional overlays, templates, contextual help, tooltips, and wizards.

Reactive help, on the other hand:

Reactive help is provided in response to the user encountering a problem.
The goal of reactive help is to answer questions, troubleshoot user problems, or provide detailed documentation and materials for people who want to become expert users.
Reactive help comes as frequently asked questions, technical documentation or tutorials, or training modules.

The thing is... Fedica's documentation here doesn’t really behave like either. It can’t be dismissed permanently, because it comes back after page refresh. And even if it could be dismissed, the little “Learn More” link will always be sitting there, staring at you.

So instead of a helpful assistant, it feels like this piece of documentation permanently rents half of your screen — whether you like it or not.

Observation #2

Let’s talk about buttons.

This form has three actions: Post Now, Save as Draft, and Schedule.

The problem? They’re scattered across the page like they were assigned by three different designers on three different planets.

This kind of layout isn’t just uncommon — it’s downright disorienting.

In most forms, actions follow simple patterns:

One primary button, usually on the right (or under the last input)
A primary + secondary button combo
A primary + ghost button combo, where the secondary action is styled more subtly
Or even a grouped layout: two buttons on the right, one on the left — but still cohesive.

And here? None of that. It looks like someone played UI Jenga and left halfway through the game.

Observation #3

Let’s zoom in on this tiny icon:

It’s a hashtag icon. It lives quietly inside the form, right next to where you write your post.

But... what does it actually do?

Click it, and surprise — it opens a whole modal.

There’s no tooltip, no label, no clear indication that it triggers a complex interaction. You’d expect something minor — maybe inserting a hashtag — but instead you get an interface.

And sure, users can learn over time. But that doesn’t excuse hiding a significant feature behind a mystery icon.

This is one of those situations where "intuitive design" quietly packs up and leaves. 😅

You can argue that users will figure it out eventually — but that’s not a justification. It’s a resignation.

At the very least, we should:

give it a tooltip,
explain its purpose with a label or visual hint,
or redesign it so it doesn’t feel like a hidden easter egg.

If a button triggers something substantial, it shouldn’t look like a quiet decoration.

Observation #4

Now this one is sneaky in a different way.

When you click the close button on the post form, the whole form disappears. Okay, not great, but fine.

But then... If you click compose, the form doesn’t come back where it was. Instead, it comes back as a modal.

At first, this feels like a small detail. Maybe even not worth mentioning.

But here’s what likely happened:

In one place, the form is implemented inline, directly on the page.
In another, it's built as a modal.
And somewhere along the way, these two implementations collided.
The result? Confusion. Consistency lost.

Unexpected transitions between inline UI and modals can feel jarring — even if both views are technically showing the same thing. Consistency in interaction patterns matters.

This probably wasn’t a conscious design decision. It looks more like a side effect of technical debt or simply overlapping logic from two different parts of the app.

And that’s the real problem: not that it’s modal or not, but that it’s inconsistent. Inconsistent behavior → confused users → support tickets → existential dread.

Observation #5

This one's small, but it messes with expectations.

Look at the list of connected social accounts. Where would you expect the add account button to be?

Answer: at the end of the list.

That’s what users see in 99% of interfaces.

You scroll through items.
You reach the end.
There’s a button waiting for you: "+ Add something new."

But here it is on the left, before all the accounts. Unusual? A little bit.

New elements are usually added at the end of a list — that’s the common pattern users expect.

There’s another detail here.

This plus button actually has a label — "Networks". But do we even need that?

Most of the time, users understand a plus sign without any extra labels — especially in the context of adding social accounts.

And honestly? That label might even add a tiny bit of noise.

Recently, the form got updated: the + button moved to a more expected place — at the end of the list.

Great!

But... now the buttons sit too close together, which increases the chance of misclicks.

Always give UI elements enough breathing room — especially when they trigger important actions.

Observation #6

Now we get to the really weird stuff.

Take a look at this sidebar:

What’s going on here?

The "Customize Post" label is written vertically.
The navigation feels like some kind of submenu.
Switching between states feels... odd.

Technically, this section lets you customize content for different social networks.

But:

Vertical text is hard to read.
Jumping between sections this way feels pretty unnatural.

Vertical labels work well for tabs or categories — but not when users need to constantly switch views or edit content.

This is probably the most confusing part of the whole post form.

Why? Because the entire UX changes here.

One minute you're writing a universal post. The next — you're deep inside a multi-platform customization labyrinth, with no clear way back.

It’s not necessarily a design crime. But it is unusual. And unusual patterns create friction — unless they’re introduced really carefully.

We’ll come back to this later when designing a better version.

For now, just remember:

If users need a map to get out of your form — maybe your form has gone a little too far.

Different Networks, Different Forms

Here’s the fun part.

Every social network has its own rules for content.

Some platforms love long posts.
Some limit you to 280 characters.
Some let you upload PDFs, others barely handle videos.

The conclusion?

There’s no such thing as a “universal” post form.

If your app supports multiple networks — sooner or later, you’ll need to handle all their little differences.

Which means:

Different validation rules.
Different input options.
Different UX flows.

And probably... different forms.

A scalable publishing system should be ready to support N different forms — each tailored for a specific platform.

This doesn’t mean you have to build them all at once.

But it does mean your design should expect things to get more complicated over time.

Prepare now. Cry less later.

A Real Preview is a Must

There’s one thing we can all agree on:

If your app lets users publish content — it should also let them preview that content.

Simple as that.

Because let’s be honest: nobody trusts a post form that hides its final result like it’s a lottery ticket.

Especially when we’re talking about multiple social networks — each with their own formatting rules, limitations, and quirks.

Preview isn’t just a nice-to-have here.

It’s survival.

Every social platform has its own rules. The more networks you support — the more your users need a clear, accurate preview of their content.

This also raises a couple of important questions:

How do we show the form and the preview at the same time?
How do we handle previews for multiple networks?
Should users switch between them, or see them all at once?
And what happens when they customize posts per platform?

All of that will affect our future layout decisions.

Let’s imagine the simplest case: the user writes one post and wants to publish it across all connected platforms.

Great. That’s the common scenario. But here’s the problem.

Even for this “universal” case, platforms can have different rules.

Different media types
Different file size limits
Different support for polls, hashtags, links, previews…

So what happens if the post is valid for some platforms but not others?

Your app should clearly show which platforms will publish the post — and which ones won’t.

There are a few ways to communicate this:

Gray out the avatar of platforms with errors
Show tooltips or inline messages
Highlight the preview area for platforms with issues
Provide clear, actionable error messages — not vague warnings

The important thing:

Don’t wait until the user hits Post to reveal that something’s wrong.
Warn them early. Show them what’s broken. And help them fix it.

So... How Does It All Work Together?

We’ve looked at a lot of small things:

Misplaced buttons
Clunky navigation
Too much documentation
Weird customization flow
Platform-specific quirks

But there’s a bigger question here: how does the whole publishing flow actually work? 🤔

Where does it start? Where does it end? And how many ways can users get lost in between?

Well... let's map it out.

User Flow

There are a lot of definitions of what a user flow is. Most of them convey the same idea.

User flows are diagrams that depict the path a user can take to complete a task while interacting with a product. A user flow focuses on the user's needs and the most efficient way to meet them.
Interaction Design Foundation

Here’s the flow I mapped after the first iteration of exploring the post form:

Next Lesson