A community website redesign starts with competing jobs

A community website can disappoint several audiences for different reasons. A newcomer needs a reason to try the framework, while an experienced user needs a route to information. Contributors need a way into the work, and funders need to understand what their support enables. A redesign should agree how those jobs share the site and who can deliver the changes before committing to a visual promise.

Django’s April 27, 2026 redesign announcement described discovery, design and incremental implementation. It also identified missing expertise and the need to combine volunteer continuity with paid work where finances allowed. That is evidence of a plan and its capacity constraints. It does not establish that the work has been completed or that a particular design has improved the site’s results.

Give each audience a destination

A homepage cannot explain everything at equal depth. It can, however, help visitors recognize their next destination. A newcomer deciding whether the framework fits a project needs different information from someone looking up a feature they already use. Trying to serve both with the same paragraph can make the explanation vague and the route to documentation harder to find.

Start by describing a task for each audience in terms a visitor would recognize. Then identify which part of the site owns that task. This is an editorial decision as much as a layout decision. The homepage can introduce a path without becoming the full destination. That separation gives the design room to help newcomers while preserving direct routes for regular visitors.

Contributors and funders require similar care. Joining a project is different from selecting it for a commercial application. Supporting maintenance is different from finding technical documentation. These paths may share context, but they ask for different decisions. Agreeing the destination prevents a redesign from treating every visitor as a potential downloader or placing every community responsibility into one crowded navigation item.

Discovery should resolve a decision

Research earns its place when it helps choose between competing priorities. A team should be able to name the uncertainty it wants to resolve and the decision that depends on it. For example, disagreement about a newcomer’s first destination needs evidence about that journey. It does not automatically justify replacing every template or delaying an unrelated correction to a broken link.

Existing information can narrow the work before new research begins. Feedback, navigation patterns and support questions may suggest where to investigate. Each has limits: a vocal contributor does not represent every newcomer, and a frequently visited page does not prove a task was completed. Use those observations to frame questions, then keep the distinction between an observation and an interpretation visible.

Success criteria should also reflect the audience’s task. A more attractive homepage can be a legitimate objective, but it cannot alone show that documentation is easier to find or that contribution instructions are clearer. Decide what evidence would answer each question before choosing the design. This keeps evaluation attached to the work the page is supposed to support.

Capacity constrains the promise

A volunteer project needs more than a list of desirable changes. Someone must be available to make decisions, maintain content and carry the implementation forward. Specialized design or research work may need focused professional time. Recognizing that need does not diminish volunteer expertise. It explains why a plan can depend on funding as well as willingness to contribute.

The April 28 PyCharm fundraising notice provides historical funding context. It extended the campaign to qualifying annual renewals and stated a May 1 end date. This is an expired campaign record, not a current discount or invitation to renew. It also does not establish money raised or a budget allocated to the website redesign.

Keep that distinction when discussing sustainability. A fundraising mechanism can support a foundation without guaranteeing staff time for a specific project. Before making a delivery promise, identify the available people and the work they can actually own. A design brief which assumes unspecified professional capacity can create obligations the implementation team has never accepted.

Roll out at the scale of the decision

Incremental implementation can preserve working routes while a wider design evolves. A section with a clear job may be easier to change than a homepage which balances several audiences. Shared components can help maintain coherence across those steps, provided someone owns the rules and the content. A pattern library is useful only to the extent that people can apply and maintain it.

There is a strong counterargument to a large discovery programme: a narrow, reversible homepage refresh may need much less process. Correcting hierarchy or clarifying a link can be justified by a specific problem and checked directly. Requiring extensive research for every such change can consume the same limited capacity that the programme is supposed to protect.

The boundary is the consequence of being wrong. A reversible adjustment with a clear owner can move quickly. A restructuring which changes important routes or makes new claims about the project needs a broader account of its effects. Scale the process to that decision. Neither a complete redesign nor a small refresh should become the automatic answer before the problem is understood.

For a custom software website project, agree the audience paths and available capacity before approving a visual direction. Make the first change small enough to finish and meaningful enough to evaluate. A credible redesign promise connects the visitor’s task to work that named people can deliver and maintain, while leaving room to adjust what the evidence does not yet settle.