Concept

Kick-off

The first meeting where those involved in the project come to the same table (nowadays also gladly and without "losses" in a video phone call). We get to know each other and give the project a firm framework. In addition, we determine the tasks and goals with the clients in order to have the entire project process clearly in mind. We clarify who the actors are and what resources are available to us. Based on the results, concrete tasks can be defined and assignments/offers formulated.

For a long time now, the topic of agility has not only been driven through all agency villages. We also interpret it a little more freely than simply: fast-fast. Flexibility does not need to be emphasised for us. Because at every moment of a project, it naturally changes. The art is to find the right balance of freedom and rigour. Not to miss the moment when adaptability turns into indiscriminateness. Therefore, agile thinking and acting also needs a framework: Deadlines and coordination, decisions and reliable milestones - which, by the way, customers must respect just as much as the creation. Always on the lookout for better, better, better. Because that's what we want too. At least.

In other words, larger website projects in particular are complex undertakings that cannot be planned completely in advance. Needs can change, and we have to react to this together during the course of the project. Therefore, the following applies in our projects: 

• We work cooperatively with the client's project team on an ongoing basis. 
• The most important issues are worked on first. 
• The implementation takes place in delimited sub-packages. 
• Changes during the course of the project are incorporated at short notice.
• We always point out all possible pitfalls as far-sightedly as possible.

... so that the project can fly. (So much wordplay must be allowed.)

The aim is to gain the deepest possible insight into the company, its culture, the working relationships and the world of products, solutions and services.

The requirements from the briefing are compared with your own understanding and recorded in writing. The document is used for coordination and is binding. Both sides agree on the exact task and the result of the project.

Yes, we know that such a beginning is not possible in every project. But we will still be able to dream - and we speak from experience. 

User stories describe the multitude of requirements for a (digital) product by asking WHO, WHAT and WHY. 

WHO = User

If the focus is to be on the user, we need to know as much as possible about him/her. That's why we develop personas, i.e. ideal-typical descriptions of users. However, we do not do this abstractly, but always in relation to the concrete product. That means we are interested in the role in which a user visits a website, for example. 

WHAT = Function

At this point in the user story, assumptions are formulated about which function/feature users expect.

WHY = Value

Here we ask about the goals and motivation of the users in the situation. This question allows us to understand the context and also to make decisions about how to prioritise the function.

User stories are therefore an excellent tool, especially in cases where there is a large and diverse potential user community and there are correspondingly many requirements. User stories make it very easy to break down these requirements and translate them into functionalities to be developed. This ensures that nothing is forgotten - from the higher-level information architecture to accessibility. 

To develop user stories, we do collaborative workshops. The composition can always be different, depending on which user group is involved. 

We like to use Atlassian tools to document user stories. The ticket system »Jira« and the Kanban board »Trello« can be used to optimally manage the tasks and coordinate them between the trades involved (concept, design, programming). See also. 

Brainstorming

Proper brainstorming must be allowed at the beginning of the conception process.

Basic idea

Here it is important to bring the idea of a project to the point in a way that is comprehensible to everyone involved. For example, who is the website intended for, what does it do, what makes it special? Example: uncubemagazine.com combines the ease of the internet with the sensibility of print.

Basic concept

Once the contents and functions have been defined, work begins on the basic concept. It brings the contents into a structure and lays the foundations for user guidance or communication tasks. This is presented, for example, in the form of a sitemap. 

Detailed concept 

All components and contents/functions are described in the detailed concept. If the project allows this. The challenge here is that it must be formulated so specifically that designers, editors and programmers, for example, know exactly what needs to be done - and do not have to make their own conceptual decisions during implementation. And it must be generally comprehensible, because the detailed concept is often the basis of the contract and is accepted.

Technical concept 

If we again take the complex case of a website, no project is possible without a technical concept. It describes all requirements and implementation decisions regarding server architecture, editorial system, data structure, administration of user rights, browser compatibility and accessibility. In the case of a website relaunch, the procedure for migrating the content from the old to the new site is also described. 

Editorial concept 

Many of us at Henkelhiedl have an editorial background and know: A badly configured content management system or a half-baked communication strategy can make editors very angry – every day and for many years. That's why we always try to think about how the content can be structured in the backend so that the website is easy to use later on. This saves nerves, time and money. 

Sprints 

The (design) sprint is about quickly and pragmatically creating a product prototype and testing it with users. The idea behind this is that upstream research and abstract analyses are of little use, but that insights into what works and what doesn't are only possible on the basis of a concrete product. This approach can save a lot of time, but often you get bogged down in details only to find out that the end product is not accepted by the user according to your own ideas. Design sprints are not suitable for every project. Where it makes sense to apply it can be found out here, among other things.  

Design sprints generally consist of five phases:

Day 1: Understanding

On the first day, it is important to identify the problem or the task as clearly as possible for all participants. If necessary, the findings from the strategy phase can be used here.

Day 2: Finding solutions

Many different approaches to solving the problem are sought. At first, everyone works for themselves.

Day 3: Decide

Now the best ideas have to be determined by voting in the team and a user story has to be worked out. 

Day 4: Prototypes

On the fourth day, prototypes of the product are created, which can later be demonstrated to users. The best tool for this is Keynote.

Day 5: Check

On the fifth day, the prototype is demonstrated to »real« users to find out which of the ideas actually work and which do not.

As written in the Strategy section, of course:

Tools, mechanics, workshops, interviews, ... the list of things it takes to come up with good ideas aka concepts »neat and tidy« is long. All components have their justification and the flight altitude of the project often determines the start-up. But with all the craftsmanship and necessary objectivity, we can also do one thing above all: jump from a standing start (quite high). 

»Hello, what is the request? (...) All right, here's how it's done.«

Whoever gets involved with us allows many paths, but in the end they always lead to Rome. (In other words, the path is the goal, and we determine the path together with our customers. 

Let's go!