What should a UI designer know and how to deliver this knowledge to him?

Question

I manage a few development teams at the moment. Each team develops different projects for different clients.

Right now I'm trying to let team leads work with clients directly without me, but the problem is that none of them has good experience designing UI. I do. We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she is neither into business nor into development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.

So, what do I do with designs? It consumes a significant portion of my time each week...

Let's summarize:

1. The designer creates interfaces that are difficult to develop. Okay, I've handled to her my own sketch design system and introduced to main UI frameworks that we use. She is getting better at this.
2. The designer isn't into business. She doesn't know when it makes sense to spend money on more complex things and when we should just make it simple and improve when needed. Okay, I may be able to put this responsibility on the Product Owner.
3. The designer doesn't know all the intricacies of a product, PO's vision and user feedback. What do I do about it? If I'll ask her to consume all this information, then she'll be spending more time learning the product, than actually designing it.

Answer 1

To be blunt about the answer, it sounds like the designer has a lot of crutches. If you want them to step own design (I'll assume you do or you wouldn't have hired a designer), you need to take those away. Now, before I get into the ones I see in your description, I should add that if you take them all away at once, you may just overwhelm them - you have to use your judgement on how quickly they can be self-sufficient or, better yet, discuss it with them and let them tell you.

First, it is not ok for a designer to not understand how those designs are implemented in an application. Painters have to understand the intricacies of paint and canvas, the graphic designer has to understand how to design for applications. You mention PO, so I'm guessing your teams are practicing Scrum. If so, the designer is contributing to the product and is therefor a development team member. They should be in there each day making the product happen. There are many ways for people to share knowledge, but I've never seen one as good as pairing or group programming. This will not only let the designer feel when the designs are hard to implement, but will also help them learn the medium they are working in.

Second, the team is solving a need for the business. No member of the Scrum team should be apathetic as to the needs of the business. They are only making an application to solve those needs. I don't know to what degree your team (including the designer) directly interact with the users and business, but I know when I was on a development team, having to own that solution when interacting with customers really changed my perspective and made me consider the business much more.

With the designer, there's an extra thing that can really drive this home - rapid prototyping. In rapid prototyping (which can be as easy as building paper mock-ups), the team quickly puts designs in front of real users to start interacting with. This can let them get honest feedback before they get too attached to their chosen implementation.

Thirdly, you may need to look at your own actions and try to see if you are accidentally introducing a crutch. When we make decisions or own a piece of the work for the team, they have a safety net. If they don't do it, they know you will. For this, I often point people to David Marquet's Ladder of Leadership. Working your way up this is a great way to shift ownership over to them and get those hours of your week back.

Answer 2

Analysis

We have a designer, who I'm trying to teach how to create UI the way I do. The problem is that she isn't into business neither in development, so her designs are quite typical: as beautiful as useless and/or difficult to implement.

The problem here is actually quite simple: you are creating a single point of failure, and loading up a single person (your designer) with cross-domain responsibilities that properly belong to a team of people. This is exactly why agile frameworks like Scrum involve the entire team in planning and estimating work.

What to Do Next

Instead of expecting your designer to be an expert in UI design, engineering, and business, a more pragmatic approach is to ensure that designs are created collaboratively. Planning a new interface element should include:

1. A Product Owner and/or business analyst to speak on behalf of the business functionality the design should address.
2. A designer who can offer suggestions about ways to visually represent that functionality, or the various workflows around it.
3. The engineering team, who can ask clarifying questions and ensure that ideas that are impractical or difficult to implement are redesigned or refined until they fit within the team's capabilities.

In short, design should be a ping-pong exercise between the visual/workflow people and the engineers who are expected to do the actual implementation. Furthermore, the Product Owner must participate so that he or she can make sensible decisions about what features are most important to focus on, and which work items make the most economic sense to allocate resources towards.

No matter how cross-functional your team members are—and it certainly sounds like they are not fully cross-functional—the entire team must work together to contribute their individual expertise towards building the product collaboratively. Treating design, engineering, and resource management as independent steps or activities is a recipe for failure.

Rules of Engagement

In order to collaborate, the entire team must contribute their collective knowledge and experience to each step in the development lifecycle. Most agile frameworks lay out some variation of the following rules of engagement to help with this:

• The entire team takes part in the estimation or planning process.
• Work is never generated somewhere upstream of the whole-team process, and then "tossed over the wall" to become someone else's problem to deliver.
• Only the engineering team can estimate how much effort a proposed feature will require to product.
• Only the Product Owner can prioritize the Product Backlog, and thereby control the amount of available project resources to allocate to a given feature.

In short, stop treating UI design as an independent, upstream process. Treat UI design as a whole-team effort where there is ongoing collaboration rather than hand-offs.

And finally, if you're the Product Owner, understand that while you can delegate role-related tasks, the responsibility and accountability of the Product Owner role still remains with you. Scrum is particularly adamant about the fact that the Product Owner is a unitary role, and while that role collaborates with the team it cannot distribute the Product Owner role across multiple people.

Inspect and Adapt

Even if you aren't following Scrum or some other agile framework, these rules of engagement address the pain points you're experiencing. If you choose not to follow these widely-accepted best practices, at least take the time to carefully inspect your current process, make changes to continuously improve that process, and be sure to measure your expected outcomes so that you can continue the inspect-and-adapt cycle until you achieve the results you want.

An organizational culture of teamwork, and a process for continuous improvement, it is essential for solving most project-related problems. Put aside the inclination to "hold individuals accountable" and focus on systems-thinking to achieve the best results.