Collaboration and Expectation Management
Collaboration and Expectation Management
Designing or redesigning a website is always like a new and exciting journey to me (like with most of things in life in general). Of course there are patterns and routines – but there is always a different constellation, new requirements, different problems to solve. And I like having new challenges.
But there is one constant I would like to have in projects: good and honest communication. And interestingly enough, most problems that occur during a project are caused by a lack of communication – or by sending out wrong messages.
Just recently I was working for a project where we had to redesign a not very complex website. As it wasn’t a very big project, the developer the designer and me as the interaction designer tried to work very close together and to be “agile”. We had fun and we thought we came up with a good solution. Even though the budget wasn’t that big we still tried to add some small but innovative features for the customer.
We also tried to involve the customer from the beginning on, started by showing him first scribbles that turned into wireframes until we showed the final design. And we made decisions with the customer together on our way to the final result.
But even though I had the feeling that we were working close together, there was still a lack. We were constantly sharing our ideas with the front-end developer – but we didn’t talk enough to the backend-developer. And when the designer finally handed off his design file there were a lot of issues that couldn’t be handled with the tight budget we had.
At that point the customer had already “bought” the new design and he was convinced that this is what he will get.
So we set expectations that we couldn’t quite fulfill. Which is the dilemma I have to deal with:
As an interaction designer and problem solver I want to bring creative and innovative ideas to projects; I want to look at things differently to come up with solutions that are actual improvements of the current status. This attitude is important in the beginning of a product development project.
After shaping the idea and adding form to visions it’s time to get back to the ground. This is when we need to get realistic again and talk about feasibility.
What I learned from that project is:
- there are 2 phases in a project, the dreaming phase and the implementation phase
- don’t give up on innovations; start with dreaming big in the beginning
- set the expectations right: communicate to your client and other project members that you are playing around with ideas and trying to shape it; that all visualisations are still not reality yet
- as soon as your ideas start to become more visual talk to the “realistic ones”, to the developers and get their point of view
- draw the border: figure out which parts of our ideas is feasible within theĀ given timeline and budget
- visualize the trade-offs and come up with alternative solutions if needed
- show your client the comparison of both phases, the ideas of the dreaming phase and the possibilities of the realistic one; explain the differences and help him to get a solution that fits best to his problem.
What are your experiences with collaborative work with designers and developers? How do you deal with expectation management?