But there are some challenges – surmountable, mind you – that stem from the very different types of work designers and developers do to deliver a software project. UX designers, non-technical as they are, are often seen as the black sheep of any team. That is because oftentimes designers work outside the scrum team and have their… eccentricities.
But usually way less than development does. However, it's hard to come up with a rule of thumb as to how much UX design effort is needed for any given project. It's not like estimating the QA effort, which usually is done by applying a percentage (such as 20%) to the estimated development time.
That's not the case with UX design because the effort required depends a lot on the type of project we're developing. It might be very little (if any) for back-end-intensive applications and quite a lot for B2C apps where user experience is paramount!
It all comes down to managing expectations. No, designers can't deliver anything meaningful for the initial kick-off meeting that's due in 2 days, but it won't take hundreds of hours to sketch the main user flows either. As always, through good communication, everybody knows what to expect.
If you plan according to a strict scrum framework, you will have designers and developers working on the same functionality in the same sprint. The problem is, front end developers can't properly do their job until designers deliver.
To avoid this issue, we found through trial and error that it's nough to de-synchronise design and development, i.e. letting designers be ahead of development with at least 1 sprint. In other words, in any given sprint, designers should work on functionalities that are to be developed in the following sprint at the earliest.
Designers can't work on individual user stories, but rather on screens and user flows. To be able to do that, they need to have the big picture in mind: the client's business, the problems the future software solution is supposed to solve, its target audience and in the end the functionalities it will feature. Once these things are known, they will try to cover the main flows with wireframes and finished designs.
As stated at #1, this process takes a fair amount of time, and there's always the risk of front end developers being stuck because they miss design deliverables.
Involve us as early as possible. The best time to start the design process is during sprint 0 (the foundation sprint) or even earlier. There were projects in which UI implementation was scheduled for later sprints so that designers could prepare and test their designs. In some other cases, designers were involved in the project weeks before the actual Scrum team.
Moreover, they can help the client define the product through a process called design thinking. Sometimes clients have no written documentation, but just an idea. In those cases, after a few interviews and Q&A sessions, designers can produce wireframes and prototypes that act as the basis for a detailed product backlog.
Always involve designers in functional analysis workshops. The sooner, the better. The more, the better. Oh, and avoid PO–team–design grapevine communication and facilitate direct communication instead. The last thing you want is the PO signalling a problem, the tech team suggesting a solution that's convenient from a technical point of view, and then them asking the designers to… "design" it. The proper way is to let designers weigh various solutions while having users' best interests in mind.
It's easy to fall into the trap of thinking that once the shiny designs are delivered, the designers' work is done. But it's far from being so. Designers have to make sure their shiny prototypes are (and can be) properly implemented by the technical team. They need to pay attention to microinteractions, various performance aspects, and how the app looks and behaves with production(-like) data. Very importantly, designers ought to gather user feedback and propose improvements based on it.
And finally, they need to ensure that all new features and changes are in-line with the overall design of the system.
After the main design phase ends, designers should still be involved in the project, with a limited ongoing allocation needed for periodical reviews, new features, users testing and so on. A good approach is to set a meeting every sprint in which the design implementation is demoed. If there are "bugs", they should be planned for the next sprint.
Also, sometimes designers might work with limited information and a limited scope – such as for an MVP – so expect that some design decisions might prove to not be ideal as the project advances. In this case, it's better to be agile and treat design changes as normal business.
It has ties with scientific fields such as engineering, psychology, sociology, art, ergonomics, language, and semiotics. It follows the "form follows function" mantra. What I want to say with this is that it's a lot less subjective than art. There are worse and better ways to design an interface, it's not just a matter of taste.
Being less prone to subjectivism than art, UX/UI tasks can be estimated quite accurately.
Remember #1? For everybody to have realistic expectations within the team, UX designers should always do their (high-level) estimations. But since UX design can represent a relatively small proportion of the total development effort, there's a tendency to assume it will be delivered quickly and with few timing risks. Except when it doesn't. A seemingly simple project could pose a significant design challenge. There might be availability issues… As stated at #2, the last thing you want is developers being held back by delayed design deliverables.