Image by You X Ventures from Unsplash
DESCRIPTION
Communication is key when planning new features, projects, products. But who should be involved in a conversation with clients, should there be any review of designs, how to find a balance between designs and implementation? All of these concerns can lead to chaos, let’s learn how to avoid it during product creation.
Problem - Chaos in planning
You can be at different stages in your project. MVPs usually have tight deadlines and overloaded sprints as it’s all about gaining traction and impressing clients with how quickly features can be delivered. Later in the project, there could be more maintenance and the atmosphere will stabilize. Commonly, there is more room for reflections by then.
But, chaos can happen at any time.
Sometimes, when there is a lot of time pressure, the Product Owner might try to do multitasking between designers and developers, forcing them to work at the same time on the same feature. Ambitious developers can push designers off and stay closer to the client. Designers will be confused and will question themselves if their work has any value if it’s all about delivering functionalities. This breaks the order of things and that’s when…
Chaos takes over.
Solutions
DESIGNERS - STAY CLOSE TO THE CLIENT
These folks are not only responsible for UI aesthetics, great UX, and making sure the application is consistent, but they also know how people are using websites, their behavior and possess some knowledge about the psychology behind their decisions. I haven’t met a single developer in my career who would elaborate on these topics, at least on daily basis, but they do 😀.
The above "stay close to the client” is all about early mockups, first interactive flows and shaping the fundaments of a prototype application based on the early client’s criteria, this is not a final design by any means.
Developers are important, as they need to evaluate the designs against technical limitations, potential pitfalls, edge cases and understand the business logic behind.
But that’s happening a bit later (at least it should).
Note: Usually, an Engineering Architect should be involved as well, just don’t invite all developers for these early discussions with the client.
DEVELOPERS - PARTICIPATE IN EARLY DESIGN REVIEW
When the application prototype is created after endless hours of conversation with clients and rapid change of requirements, designers can finally rest…
Well, not really. That’s when the worst starts and they need to confront mockups with developers 😱 . This phase is crucial, as I’ve had countless moments when proactive action, comment on early mockup could save dozens of time in later implementation, or just spot the gaps in edge cases, business criteria.
We are just humans, it’s good to take a look at things from a different perspective and have more people involved (at different stages) to shape up the final product. IT is all about communication, filling the gaps in expertise and co-operation between people.
Note: Under time pressure, the Product Owner, or other personas might try to push developers to start implementation without asking them for any review - this is a big no no, and someone needs to act at this point to prevent loss of time and costs - forcing an early prototype can be a huge mistake, the balance and at least minimum time for developers to review an early design is crucial there. Also, allowing developers to participate in design review will build their motivation.
DON’T DO BOTH AT THE SAME TIME
This one is my favorite. Developers are implementing a new feature based on early prototypes and deploy it to a staging/QA/prod environment. The Product Owner is super happy and shows it to the client. Designer comes in and points out 10+ differences between implementation and the final design (which was not available by the time developers coded the feature). Then, the next increments start, improve this, improve that, but also deliver the next features, and technical debt grows like crazy.
The above leads to a lot of confusion, panic, and chaos which is not easy to fix.
When designers are adjusting prototype based on the review they received, e.g. from Architect, Product Owner, or developers to shape final design, developers should be working on different features. It’s a golden rule that designers finish their work before developers do the implementation, but it’s a perfect world scenario.
When starting a new project, there is a lot of work needed to boilerplate the application, setup CI/CD, and think about overall architecture - this can be done without waiting for designers to finish the final design. On the other hand, sometimes it’s impossible to wait as the deadline is way too tight. This is where the Design System comes in handy and can unblock developers to deliver features, and save a lot of work for Designers.
Closing Notes
The next part will be about Lack of a Design System 🔥 which will be a complementary example to the „Don’t do both at the same time” solution.
Big thanks for reading the article, you're awesome! 🙇♂️
You can also find me on:
Thanks for all the support. ❤️
