What don’t you know about UX designing of complex systems.
This text might as well apply to developers and describe problems in the implementation of a new IT system, so many common points there is between UX designing and writing code. Thus, you can safely use most of these observations at every stage of the project, which should help to avoid many problems and risks.
In Divante, we often designed and have been designing large, complex systems that support our clients’ business: B2C and B2B platforms, CRM and extensive CMS systems. Doing that, we’ve noticed several characteristic types of clients’ behavior and requirements that are repeated regularly, creating the so-called myths of a successful project. These myths relate to improving work efficiency in a project and are originally meant to serve meeting deadlines and budget. However, they can in turn lead to dilution of the final goal, extend deadlines and cause budget overruns. Here they are:
Myth 1: The more people on your side get involved in the project, the more likely it will be successful in the end
Yes and no. Undoubtedly, ensuring that voices of various project stakeholders are heard and included in the project helps its results to be successful in the company. At the same time, however, it will surely cause chaos and diffusion of responsibility: every department will try to achieve their own goals and there will be no one to check whether the final result is a consistent and beneficial for its users and the company.
What should you do? First of all, keep your side consistent: designate a Product Owner that will directly contact the sponsor of the project and give the person a decisive vote by making them responsible for the project direction.
Myth 2: If I make the design team twice as big, I will finish the project twice as fast.
Unfortunately, it doesn’t work like that, as proved by the old rule of project management cited in the title. The more people in the team, the more time it takes to communicate, so the project efficiency doesn’t grow linearly with its size. As a result, large groups tend to be even slower than the small ones, as they lose more time in agreeing who does, did and will do what.
So, should you increase the team or not? Do it, at the same time giving the team time for tasks associated with workshops, team meetings and work on the project consistency during each sprint/stage of work, not just specific functionalities. As a result, large teams will work like a well-tuned machine, and not a random collection of individuals.
Myth 3: In any design team everyone has equal status and perform the same amount of work
There’s a pitfall associated with agile methodologies and the idea of a self-managed teams with a Scrum Master that facilitates their work. In our experience, if such a team lacks a leader, its work won’t be effective and it will lead to a lot of inconsistence in the final product.
Keep in mind though that a team leader shouldn’t do any work – in the sense that they are not occupied with project work or spend only a (smaller!) part of their time doing it; the rest of the time is needed to review the effects of other team members’ work, corrections, setting design direction and communicating with PMs, POs and other stakeholders.
Myth 4: If I change the requirements at the end of a project, I should also update earlier artifacts to maintain consistency of documentation
This approach can get you into a spiral of continuous changes and improvements, extending the deadline and exceeding the budget. We often encountered our client’s expectations, who, after making changes to the graphics, asked us to update the mock-ups. Paradoxically, rather than improve, this approach often worsens the consistency and clarity of documentation, because at some point no one knows which item is current and correct.
Our advice: Don’t overdo it with consistency. Designing from the beginning should only concern really important functionalities or processes; other changes should be introduced on graphic or even in HTML, keeping only the accurate documentation of changes.