What a turbulent year it has been so far. In March Corona put us completely into the home office and the uncertainty about what was in store for us was very great. Fortunately, we made it through the special time well, which puts us in a positive mood for the times ahead of us. That’s why it was time to get together outside of everyday work and celebrate the year and summer. So we went up to lofty heights.
Friday, August 28th, 2020 at 9 a.m. in Dresden: it is pouring rain. Nevertheless, we find ourselves at 10 a.m. at the Waldseilpark in Bühlau – hope dies last.
After the seat belts have been put on and the instruction is done, the sky suddenly tears open and the sun shines: what luck! Our team event and summer party can take place as planned. Together we slowly feel our way into the spheres of the climbing paths: first the easy level of difficulty, then the medium and then the Mega Fox – a zip line that has it all. If you dare, you have a wild ride through the climbing forest in front of you. Everyone is fully committed, we motivate each other and give each other tips on how to best master the course. Now that the sun is shining, it is quite exhausting! At the end of the day, some colleagues try their hand at the highest level of difficulty and mostly master it successfully. Only the shaky ladder is the undoing of one or the other – but a joint rescue operation also welds together.
After the climbing action, we stop in the Hubertusgarten and enjoy lunch. A toast will be given to our working student Minh, who is having his last day with us today. Our beloved colleague will finish his studies in another city and we will review the time we spent together.
In the afternoon, family and friends are invited to the Saloppe to toast the summer. It is important to us that our family and friends can experience who we work with. We use the time and play table tennis or Viking chess together, get to know each other from other sides and have dinner together. Friends, siblings and parents, but also our project partners can exchange ideas and get an insight into how we work together.
Punctually from 7 p.m. the rain starts again and reminds us of the sunny and wonderful day we enjoyed together. Shared experiences weld and allow us to continue to grow as a team. Because for us, work means a lifetime that should be fun!
Dark mode for digital interfaces is a pretty hot topic. Microsoft Office recently switched its suite to dark mode compatibility. Even a separate trailer was produced for it. With the new operating system iOS and iPad OS versions from Apple, dark mode is also finding its way into the mobile devices of Apple users. Android has offered the dark mode a bit longer. However, it will give new impetus to the spread of the feature.
As it becomes more widespread, it is time to think about adapting your website and webapps.
Do not flood website users with light in dark mode
From my own experience, you get used to dark mode in Mac OS very fast. I am using One Switch – Fireball Studio, an app that activates dark mode with sunset. This makes working in less light-poor surroundings easier for the eyes.
Many native programs such as mail, calendar and code editors already fully support dark mode. On the web, however, the picture is different. As soon as you switch to the browser, users are overwhelmed with bright sites again relatively quickly. The experience can then quickly become exhausting. There are already some browser plugins that try to generate a dark mode for all websites. However, companies do not influence the color schemes and corporate design. It would therefore be better to incorporate the support of the dark mode to have full control of the display.
Current browser versions such as Chrome, Safari and Firefox already support Dark Mode and can also pass on information about switching off the light to websites. However, the support must also be implemented within the website.
We have implemented the dark mode with PHMU.de and hope that this will make surfing more pleasant for users and protecting the eyes.
You have successfully started a Vue project (we have written how it works here) and now you want to use TailwindCSS as a utility framework for development? Then in the following article, we will show you how you can do this relatively easily.
First, you have to install the necessary packages:
Once that’s done, we can check that everything works. It’s best to add a Tailwind CSS class like bg-red-500 to a div in App.vue and see if you can see the change after the live reload. Does everything fit? Perfect, then you have successfully added TailwindCSS to your project.
Optimize bundle size
Tailwind increases your CSS immensely. So if you run npm run build you should see the change. The CSS is now over 679 KiB. However, we can reduce that relatively easily.
There are different ways to start a new VueJS project. The easiest and most convenient way is the setup using the Vue CLI. To be able to use the CLI, the necessary NPM modules must first be installed globally. The following command can be executed in the terminal for this purpose:
npm install -g @vue/cli
yarn global add @vue/cli
If the installation is successful, a new command is then available in the terminal. With vue -v, for example, you can check which version of the Vue CLI is now installed.
The project setup via the CLI
To start a project setup, you can start the setup process via the terminal with the help of vue create + the desired project name.
vue create vue-setup
After the command, a small wizard starts that guides you through the setup. First, you are asked whether you want to carry out the configuration manually or use the standard setup, which only includes Babel and ESLint. We first select manually with the arrow keys and then the space bar to see which options are offered.
In manual mode, all options and packages that can be used now appear. For example, I can add the Vue Router to my project relatively quickly and easily. But the setup for unit and end-to-end testing can also be selected.
After the desired selection has been made, the installation of the project and the necessary packages can be started.
A visual project setup using the CLI UI
If you are not one of the terminal enthusiasts, a project setup can also be carried out using a modern interface. To do this, start the UI in the terminal with:
This opens the Vue UI interface on port 8000. Project Create starts the process that is already familiar with the CLI when initializing a new project.
First, you can choose the storage location and specify the project name. You can also choose between npm or yarn as the standard package manager. However, a specification is not a must. Once the setting has been made, the wizard process is also started here.
A manual setup can also be carried out via the UI if, for example, the Vue router or Vuex should be added during the setup.
After the successful setup, you are ready to go and can further develop your Vue project.
“We have to prototype it!”, “Let’s build it.”, “We should test it beforehand.” – At some point there comes a point at which you want to transfer your ideas from a pure paper concept into a tangible product. The sooner that moment comes, the better. A well-thought-out prototype can provoke real reactions from testers. The goal of a prototype is to clarify the feasibility of an idea on three levels:
Is the idea technologically feasible?
Is it economically viable?
Does the idea create any real benefit?
I think the main goal of the prototype should be to make the idea tangible and perceptible. You offer the user a gift, so to speak, and watch him use it.
To be able to carry out prototyping well, it is often advisable to question your mindset. We should get away from wanting to develop the perfect solution and prefer one that is good enough. Also, the prototype should not be seen as a long-term solution, but rather as a temporary solution that can and should trigger further change loops.
Save time and gain insights faster
Unfortunately, we all too often experience that prototypes are thought of as the perfect long-term solution, which means that all the power of the actual approach is lost.
We can imagine two virtual lines in product development. The first milestone is reached when the product contains the basic function that is to be tested. As soon as this point is reached, users should be included in the first tests. Our idea has thus been converted into a real and concrete product that is good enough for testing. We save valuable time and also get initial insights into what users understand by the offer and how they use it for themselves.
Avoid the risk of falling in love with your idea
We all know how convinced you can be of your idea and how painful it becomes when it meets reality. With the right speed in the development process, you can protect yourself from this emotional low. If you test your idea as a prototype as early as possible, you accept user reactions with a high willingness to change. You will understand that your original idea passed the user by and that you will have to readjust. The longer you work on your idea in secret, the lower your will to change will become and you will tend to assume that the users are simply too incompetent to understand and use your product.
If we start prototyping with the development of ideas, we avoid this dilemma and are open to changes during the process.
Types of prototypes
As soon as it is clear that it is advantageous to test your idea and hypotheses at an early stage, the question of how exactly a prototype can look like arises. Unfortunately, there is no general answer to the question of what exactly the perfect prototype is. It is always helpful to start with the assumptions about your idea that are most critical to its success. That means, if the chosen assumption does not come true, your idea is useless or does not provide enough value for the user.
In the design area, a distinction is made between low-fidelity prototypes such as mockups or storyboards and high-fidelity types such as clickable interfaces with the most important basic features. Storyboards in particular are suitable for testing the flow of information and for identifying termination criteria for users. I use low-fidelity prototypes more in the design of products, but not in user tests.
High-fidelity prototypes such as a landing page with a real purchase (however, the selected payment method of the user is not charged) make real actions and reactions from users clear. If the customer is ready to make a purchase that they perceive to be real, there is a good chance that the idea presented will be of great benefit to the user.
When you are clear about what you want to test and what type of prototype you want to carry out the test with, you are ready for implementation.
Build your western setting
When you start to implement a prototype, it generally helps to think about which western backdrop you want to build.
I think the metaphor with the western backdrop is quite suitable for the procedure (I got the idea from here), since this approach exactly shows how the prototype should be thought of. The main street is shown in full detail and can be experienced in real life.
As soon as one of the side streets is entered, the prototype is visible.
You should ask yourself the question: how does my main street look like for the user? Which functions should you design and which doesn’t have to be functional? If you manage to get the user to walk down the main street in your product, your real idea and not notice that it is a prototype, they will react in the same way as they would react to the final product.
With these insights, you can successfully iterate your product and create real added value for your users.
A good challenge can have a positive influence on the start and progress of an innovation project. In the same way, a challenge that is too general or too openly formulated can also influence the project and procedure. To find the right challenge, you should take your time and pay attention to the correct formulation of the question. In this post, we introduce the Why-How-Laddering method.
What is needed:
Flipchart marker or whiteboard pen
A large sheet of paper (A1 or even better A0) or a whiteboard
In Why-How-Laddering, the question of the challenge should be adapted. Questions are always asked upwards with “Why …” and downwards with “How …”. Like climbing up or down in the laddering like on a ladder.
For example, we received the question “How do I become a pop star” for revision. The challenge is an example of a rather unsuitable initial question for a design thinking project. She does not name a specific problem and the target group “I” is very limited.
To revise the question, write it in the middle and then start the process. For example with the question: “Why do I want to become a pop star?”. Answers such as fame, recognition, or attention seem obvious.
To be able to derive a new question from these, it makes sense to include these new terms in the laddering. For example, the question can now be: “How do I get fame?”. On this basis, new fields open up that were not considered by the initial question.
Now the clear solution no longer seems so simple. A reformulation of the challenge could be, for example, “What do I have to do to acquire an extraordinary talent?”. So the very explicit solution has already been opened up a bit. The laddering can be expanded as required.
The method should be carried out until the questions are naturally saturated. Then a new question can be searched for.
What does it take to have a great challenge?
To be able to successfully process a design challenge, it is important from our point of view that three essential basic requirements are met.
Does the Design Challenge identify a clear problem? Caution: Symptoms or possible solutions are not the problems in and of themselves: A problem that is too narrowly defined does not offer enough leeway because a possible solution may already be included. On the other hand, a concept that is too broad offers little traction and makes concrete solutions difficult.
Has the problem been described from the user’s point of view? Such a change of perspective usually helps enormously in the development and validation of meaningful solutions.
Is the situation in which the problem is noticeable to the user clearly described? A good definition of the situation gives important clues as to what the team should experience during the understanding phase through observation and interviews.
At the start of an innovation project or design thinking process, it makes sense to critically deal with the given question or challenge and to reformulate it if necessary. Why-how-laddering can be a good way to shift the level and focus of the initial question.
In product development, in particular, numerous ideas and improvements arise during the development process that should be carefully considered and prioritized. Not infrequently, if the ideas are not classified, a blurred picture of the final product arises, which incorrectly ties up important development resources. In this text, we show how a simple but very effective classification of the projects can be achieved with the help of the Impact-Effort-Matrix.
What is needed:
Rectangular post-its, we like yellow
Sharpies (for insiders the term for suitable pens for writing on post-its) or, to put it simply, thick pens for writing
A large sheet of paper (A1 or even better A0) or a whiteboard
Create the matrix and prepare items
The Impact Effort Matrix is exciting and, at the same time, a simple instrument for prioritizing tasks, development tickets, or milestones during product development. As the name suggests, it is a 2 by 2 matrix with the axes of effort and influence. To be able to start, you should draw the basic grid of the matrix on a large sheet of paper or whiteboard and indicate the quarter division by central axes.
In the meantime, all items to be prioritized should be written on individual post-its so that the solution ideas can then be evaluated individually.
Evaluate the items in a team
Ideally, the features are arranged in a joint team within this matrix. This should be discussed but within the framework of the given categories. A team member should take an item and first move it on the horizontal axis until the team has unanimously decided on the effort. Now it’s the turn of the vertical axis and thus the influence of the respective item. Here, too, the team member moves the map until the correct position for the item is reached. This whole procedure is carried out with all available cards.
We look for high impact and little effort
As soon as all items are arranged in the matrix, a certain picture emerges within the matrix. It is obvious and expedient to take a closer look at the area of high influence, low effort relatively quickly. All items that are located here should be given a high priority and quickly implemented or validated.
Finally, all solution ideas in the area of high influence, the low effort can be marked with a point so that they can be quickly recognized when used later.
The impact-effort matrix is a good method to quickly and easily derive a prioritization of the upcoming product features. The approach helps especially in a team to build a common understanding of the coming development steps.