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:
- A Product Owner and/or business analyst to speak on behalf of the business functionality the design should address.
- A designer who can offer suggestions about ways to visually represent that functionality, or the various workflows around it.
- 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.