The adoption of Agile software development approaches are on the rise across our industry, which means UX professionals are more likely than ever to support Agile projects. Many UX professionals seem stymied by the challenge of effectively integrating UX within an Agile development framework–but there are others in our field who have encountered the same problems yet are finding effective solutions.
I first encountered Agile Development in 2005, when a team I supported was chosen to help pilot Scrum development methodology at Yahoo! Inc. There are variety of Agile development approaches in use, but Scrum is currently the most popular: over 70% of software professionals using Agile methodologies employ some variant of the Scrum methodology.
When I left the company three years later, more than 150 teams at that company were using Scrum for developing both infrastructure and product features. In 2009, I moved on to Salesforce.com, where Agile methods (including Scrum) were implemented across their entire research and development organization.
In my experience, when product development is managed with an Agile development approach, user experience professionals are expected to find a way to work within the Agile framework to succeed. But, while team members may be offered training or even certification on Agile development practices, the training rarely discusses best practices for integrating UX design into the development process. And though internal surveys posted by my employers indicated that most employees were satisfied with Agile development practices, some of my UX colleagues privately expressed frustrations with the challenge of delivering a high quality user experience in Agile’s incremental release framework.
So, I decided to interview my UX colleagues for their perspective: What Agile practices were working well for them, and what specific pain points had they identified in the Scrum development process?
I reached out to seventy colleagues and received detailed responses from twenty UX professionals (including interaction designers, user researchers, and visual designers) who were actively supporting Scrum development teams. Many of the problems they reported indicated that both UX professionals and technical staff lacked a shared understanding of each others’ team roles and responsibilities. And other problems stemmed from UX practitioners feeling disconnected from the daily life of the development teams they supported.
Fortunately, for nearly every specific issue an informant raised as a pain point, some other colleague independently described an approach they had used to successfully resolve it with their team. By reading their responses, I learned that effective relationships between UX and technical staff could be created and sustained by actively involving scrum teams in the UX process, by active participation by UX professionals in team activities, and by frequent communication with team members about UX issues.
Here’s a summary of what what worked well for UX professionals supporting Agile development teams, as well as some of their common pain points. At the end are recommendations for individual UX contributors, UX managers, Scrum Masters and product owners, based on my colleagues’ responses and my own experiences with Agile development.
Opinions on what’s working
Informants were asked: “Thinking about how you and your UX colleagues are working with your scrum teams, what’s going well?” Their answers included the following themes.
Trust and earned respect
Both designers and user researchers shared techniques for keeping product owners and developers informed and aware of their progress. Their practices included presenting information about their roles to teams, inviting teams to observe user research sessions, and sharing documents to track progress on usability issues.
Being transparent about the UX process helped some respondents foster trust between themselves, their product managers, and the technical staff on their scrum teams.
“I have a close relationship with the product managers I am working with, the dev manager for the scrum team and the developers themselves… I am transparent about my progress and share design iterations to get their feedback and opinions. In return, they trust me and accept the value of my expertise as a designer.”
Respondents also reported creating successful relationships with their product teams by involving their scrum teams in the UX process–especially by collaborating on UX issues with technical staff. Giving all ideas and contributions equal consideration regardless of the role of the originator, inviting all team members to give feedback on designs, and inviting them to participate in user research all helped promote developers’ ownership of design decisions.
“One of my teams has a lot of ideas and contributes a lot to the UX of the product. Sometimes they come up with ideas that I didn’t think of and it greatly improves the product’s usability.”
Be present in the life of the scrum team
Several respondents credited active team participation (beyond UX-specific activities) with their success in building relationships and fostering trust, and with achieving more of their user experience goals. Due to conflicting schedules across multiple teams, some UX professionals were often unable to attend all scrum meetings, but one called out the value of attending scrum meetings at least once a week.
“Being a constant voice in the development lifecycle helps keep the UX vision in line.”
“Partaking in blitzes & logging bugs helps the team know you’re there and trying to help.”
Co-location was preferred, but those serving remote teams cited use of tools like Skype and IRC to maintain close connections.
“Being available and in the aisle to be a part of the conversations that happen spontaneously.”
“I’m on skype and talk to them all day long”
Being present also made it possible to take advantage of opportunities to educate scrum teams in the moment when they raised relevant questions:
“Gaining interest to discuss UI topics can often go well when the scrum team has a particular question or is unsure on a particular thing.”
Frequent communication outside of standard agile interactions
In addition to participation in regular scrum meetings, UX colleagues shared that adding meetings specifically devoted to coordinating UX activities with the team were successful in increasing ownership and a shared vision of the design direction.
“Regular design review meetings are helpful in keeping both the scrum teams and researchers in the loop with decisions that seem to change every 2 minutes. Regular check-ins with product owners are also helpful in knowing priorities.”
Types of meetings called out as particularly effective included regular check-ins with product owners for both user research and design, regular design review, or design initiative meetings with scrum teams, and weekly meetings with those working specifically on front end development (or even more frequently when preparing for usability tests).
Opinions on what wasn’t working
Informants were also asked to answer the question: “Thinking about how you and your UX colleagues are working with your scrum teams, what’s NOT working so well?” Answers included the following themes.
Conflicting expectations around quality, fit, and finish
Most of the concerns raised were related in some way to delivering a quality user experience–a key concern for everyone in UX regardless of role. Some people raised issues related to these conflicting expectations, specifically around a perceived lack of commitment to quality by developers and product owners. Perhaps because our view of the product is through the lens of the user experience, UX professionals pay more attention to fit and finish than product owners or other members of a scrum team when judging whether a release is ready for launch. Some informants felt that developers ignored specifications and resisted improvements, or that insufficient team resources were devoted to executing specifications aimed at improving product quality.
“The greatest obstacle is convincing the team to go the final mile to deliver a great experience.”
“The opinion that ‘This is good enough.’ Design implementation always goes to the bottom of the priority for the sake of MVP… Pushed to the next release and stay in the UX bug list forever.”
Lack of holistic planning and prioritization for the user experience
Informants raised concerns about designs being bolted onto existing products incrementally without concern for the overall product experience. Design managers who responded complained that too often they were brought in too late to the process, were left out of the loop on strategic planning, or were not adequately exposed to the product roadmap.
“No time is considered for design of the overall framework. Scrum teams jump into feature releases. They’re building inside out instead of outside in or holistically.”
Unclear expectations about the role of UX on the team
Many frustrations expressed by informants were due to a lack of clarity around the role of UX members on the scrum team. In some cases, people felt as though product owners and technical staff members did not have a clear understanding about the skills of UX practitioners, their overall role in the development process, or that they were a shared resource dividing their attention between multiple scrum teams. In other cases, the expectations held by different members of the scrum team about the timing and relationships between design and development activities appeared to be out of alignment.
Some informants raised concerns about product owners or developers thinking of design only in very tactical terms and not recognizing the value that UX brings to the product ideation process. UX team members expected to be included in developing product strategy, but some reported that they weren’t brought into the process until after requirements were set and coding had started, leading to problems with the overall user experience delivered:
“…when it comes to designing a new product or larger holistic experience, design doesn’t get looped in until after the idea is sold and a launch date is picked and devs start working. Design needs to align earlier and sooner with the business owners to ideate and come up with a great design.”
UX team members may expect ownership of the design of the user interface, including decisions about overall information architecture and interaction models–but this expectation will not necessarily be shared by members of the technical staff on Agile teams, who may perceive the role of the designer as simply “skinning” the user interface. This creates difficulties when developers code elements of the user interface ahead of, or at odds with, UX work and specifications still in progress.
“UX was seen as pixel pushers who made things look nice after the developers built their features”
“Developers build whatever UI they think is appropriate while a designer is working on design iteration or testing.”
Perception of UX as less valued than development
Some informants raised concerns about how UX was valued as part of product development. In particular, one respondent perceived his organization as having a “developer-centric culture” that often dismissed UX input, resulting in usability and utility deficits in the product.
“They valued developers over everyone else, to the expense of everyone else being productive. PMs and Dev managers had an exclusive relationship with a few key developers and worked on product direction and user experience direction without any involvement from the UX team… Needless to say, the product they deliver has a lot of usability problems.”
Perception that technical staff is disinterested in users’ needs
In addition to dismissing of the value of UX team members’ contributions, some informants characterized technical team members as lacking empathy with the needs of their end users:
“Sometimes engineers are thinking of the solution without understanding the need. This is understandable, but it is taking a lot of education to get the idea of understanding the need and then building a solution to fulfill that need in the minds of our engineers.”
Being disconnected from the regular activities of the scrum team
Being separated from other team members either by distance or by allocation had a negative impact on UX team members. This included difficulties navigating time differences and exclusion from remote meetings as well as missed opportunities to bond with their scrum teams.
“Difficulty in being aligned with the engineering team which is mostly in India. Timing is difficult. Stand ups are near impossible to join as they are late evening for us in the US.”
Informants who served multiple teams reported difficulties with managing time and workload, and also were concerned about managing their teammates’ expectations about their availability. User researchers, who were often supporting three or more teams, were most likely to report problems with time management and team integration, but this problem could impact any UX team member with responsibilities for more than one scrum team.
“The challenge is that supporting two teams that are both on nearly identical timelines creates a time crunch. Some of that ideal process gets cramped and I end up just getting the basics done, just in time.”
Recommendations
A few of the respondents were generally unhappy with the Agile approach to development and expressed nostalgia for waterfall development. But when I looked closely at their responses, it seemed their dissatisfaction with Agile related to uncertainty about how to integrate UX into their scrum teams’ development processes or their discomfort with discussing technical topics.
Helping new UX team members with time management skills, with improving their estimation of UX work, and with understanding the roles and responsibilities of everyone on the project team may help improve their satisfaction and effectiveness with Agile teamwork.
Although UX managers can begin improving relationships between technical and design staff by offering more training in Agile techniques to UX team members, real change will require participation from product owners, scrum masters, and technical leadership. As one participant wrote:
“The culture and attitudes really have an impact whether UX-scrum team relationships can be successful. It’s a two way effort and it doesn’t work when one of the parties is unwilling.”
The suggestions below are targeted at specific roles in Scrum and on the UX team (product owners, scrum masters, UX managers, interaction designers, and user researchers) as well as at those responsible for the employee on-boarding process (including Agile trainers and coaches). Some recommendations are relevant to more than one role, so they may appear in multiple sections.
Employee onboarding (development as well as UX)
To encourage an atmosphere of trust and understanding between UX and development staff, and clarify the role of UX for everyone on the team, consider:
-
Explicitly training people to recognize that including specialists on teams may be necessary for some projects or sprints, and to reject the old Agile dogma that openly denigrated specialization.
-
Including training about UX practices and process in organizational training for developers, scrum masters, and product owners (including the relevant recommendations below).
-
Setting clear expectations for involving UX in team activities.
-
Setting expectations early that developers and product owners participate regularly in customer contact opportunities and ideation sessions around user needs (such as design studios).
Scrum masters
To encourage an atmosphere of trust and understanding between UX and development staff and clarify the role of UX for everyone on the team, consider:
-
Team intros at project kickoff. At the beginning of each project, give each team member a brief chance to introduce themselves and explain what they will be doing and how they need to integrate with other team members. Allow team members to ask questions and clarify answers as needed. If there are serious disconnects between the expectations of different team members, use this time to achieve consensus about the role of everyone on the team.
-
More in-depth definitions of each role on the team. Give a member of each discipline a chance to deliver a presentation or talk to the larger team about their skills, their background, their experience, and the tools or techniques they use in their role. This will help developers understand what UX team members do plus help UX team members understand the roles of different members of the technical staff.
-
Including UX team in synchronous and asynchronous communication channels (such as Skype, IRC or other chat systems.)
-
Including UX goals and needs in sprint retrospectives.
To create shared team ownership of expectations for fit and finish, consider clarifying the definition of ‘done’ to include UX criteria.
To enhance project planning and prioritization, consider improving estimation for UX efforts by:
-
Adding knowledge acquisition activities and design exploration work to the product backlog.
-
Separating design effort on each story from implementation effort in product backlogs.
-
Experimenting with tools and practices that have been used elsewhere to improve estimation and tracking of UX work across the feature lifecycle or within the context of a particular release, such as story mapping, design spikes, and UX matrices.
To foster understanding and empathy for the needs of users, consider hanging appropriate persona posters in the team’s work area or scrum room.
Product owners
To improve holistic planning outcomes, consider:
-
Drawing on the expertise of design managers and leads. Invite them to participate in early strategy and product ideation sessions.
-
Identifying and validating core needs of target users before initiating development (and capturing that information in product personas.)
-
Using prioritized personas to groom the backlog.
To foster understanding and empathy for the needs of users across the team, consider:
-
Associating user stories with specific personas.
-
Scheduling and participating in a persona development process if appropriate personas aren’t available.
-
Encouraging team participation or observation in user research activities. Consider making this participation explicit in the backlog so it doesn’t negatively impact velocity estimations. Opportunities may include joining site visits, speaking to users at events and observing usability studies.
To clarify expectations for fit and finish, consider:
-
Including UX criteria in the definition of done.
-
Setting clear UX goals for each sprint.
UX managers
To enable more holistic planning, set expectations with product management and executives for UX participation in product strategy meetings at all levels.
To increase team communication across business areas or large projects, create and support mechanisms for communication about priorities, design themes and patterns, and design efforts in progress.
To enable stronger relationships to form between designers and scrum teams: consider:
-
Limiting the number of teams each designer supports during any one release.
-
Improving estimation for UX efforts across business areas by tracking velocities for UX across each area with a UX matrix, or maintaining a master backlog of all UX activities in conjunction with scrum masters. This data will eventually help support your requests for additional headcount.
To clarify the role of UX for everyone on the team, provide regular Agile UX training for new hires. This training should cover:
-
Known effective tools and practices, including design studios, story mapping, design spikes, RITE studies, and unmoderated usability tests (including click tests, cardsorts and tree testing.)
-
Techniques for estimating and tracking design work.
-
Explicit training about the role of UX within the Agile development process and expectations for how UX team members interact with technical staff.
Interaction designers and user researchers
To improve involvement of scrum teams in the UX process, consider:
-
Inviting all team members to give feedback on design directions and listening to design ideas from everyone on the team, regardless of role. Design studios, product walkthroughs, usability test debriefs and user research data interpretation sessions are all effective ways of soliciting this input.
-
Inviting teams to participate in user research activities such as joining site visits, speaking to users at events and observing usability studies.
-
Leveraging opportunities to provide more information about your role and about UX in general whenever a team member asks questions about your work.
To improve relationships and trust with stakeholders and team members, consider:
-
Increasing your visibility in the life of the scrum team.
-
Calling meetings outside of the standard agile interactions when necessary.
-
Providing access to works in progress in a collaborative workspace.
-
Listing UX issues and tracking their status in a shared document.
To foster understanding and empathy for the needs of users, consider:
-
Reviewing appropriate design personas with the product owner and scrum team at the start of each release, and assign priorities to each.
-
Hanging persona posters in the Scrum room as reminders.
-
Associating user stories with specific personas.
-
Including the product owner and scrum team in the persona development process if appropriate personas aren’t available or complete.
Conclusion
The Agile Manifesto was written to promote better ways of developing software–but the twelve principles behind it are relevant to everyone involved in the process of software delivery, not just those who code. Better integration of UX specialists will result in better outcomes for the business and for developers who work with UX.
In the words of Scrum Alliance founder Mike Cohn, “Agile does not at all require individuals to be generalists, but individuals are expected to work together as a team.”
For Scrum and Agile to live up to its full potential, it must address the needs of all team contributors, not just software developers. Giving support and trust to UX contributors will help motivate them to do their best work and leverage more of their skills in the pursuit of excellence.
many of these challenges and techniquest are also appropriate for tech writers. we often have similar problems with being a specialist working on multiple scrum teams simultaneously. thank you for the insights!
Do you include UX work in the backlog for your scrum team? I’m very interested in learning more about how UX folks are estimating their work, and what kinds of UX related stories they’ve included in scrum team backlogs. If you have tried this, and have tips for things to try or things to avoid, please comment here or get in touch directly. Thanks!
We have had our UX resources embedded in the scrum teams for the past 4 years. They are as much accountable for forward development work as a java developer or a DBA or a BA or a test engineer. UX related tasks are are added to user stories accordingly, we don’t have separate stories for UX. IMO, keeping UX away from normal development sprints is risky and probably not agile. Same with technical documentation, a story isn’t “done” if it still needs UX work (or documentation work) at the end of a sprint. Seek to minimize hand-offs and the pain points will ease.
Thanks for a thoughtful and well-written article. I recently came to many of the same conclusions (albeit after less rigorous research!) I agree that Agile can, and should be helpful to UX design. However the conclusion I reached is that in practice many development projects are merely ‘pseudo-Agile’ environments with only lip service paid to key practices like co-location and review. The argument here is not so much UX versus Agile, so much as GOOD Agile versus BAD Agile!
http://www.foolproof.co.uk/making-agile-the-friend-of-experience-design/
I am in 3 – 5 teams at anyone time, most use scrum. It’s interesting to compare the different approaches I employ for ux stories in each. For example, in one my tasks are clearly defined as I did a comprehensive ux scope up front ready to validate as we go. Also there is one client and a clear proposition. On another project my stories are initially “chores” with no estimations as they mess with the velocity… I am ok with it at times when there is no clarity yet with the story. Then as it becomes cleaner, I add effort estimations.
The UX work on all of them ebbs and flows, and at times I feel left behind only to be suddenly riding the front of the wave. It’s taken some time to understand the rhythm of it but its definitely there and I’ve learned to trust that my efforts around communication, transparency and coaching to take root in time.
I also had to understand that UX isn’t always separate activity and tasks belong to stories owned by developers or BA’s. I have always worked collaboratively so it’s was a bit confronting to realise I was still trying to control those conversations by making them a ux concern rather than a team one. That level of professional reflection is a wonderful side affect of using scrum.
I full agree with the suggestions in the article, really well collected and outlined. As a side, I too learned agile first at Yahoo! There and since, I’ve had a few years experimenting and fortunately working with good (and bad) teams using it.
@Aviva Rosenstein. I’ve only been working on scrum teams for nine months now, but can sympathise with many of the concerns here. In general our UX work runs in parallel with the team, solving UX concerns within current and upcoming sprints. But we also ‘work ahead’ on more strategic projects and try to define the overall UX vision for a feature well in advance of the devs getting involved.
I’m interested in people’s opinion regarding involving all scrum team members in iterative discussions on design. I took this approach once and found it very helpful not just from improving relationships but it also helped to create solutions quicker. However I did receive comments from UX colleagues who felt that devs should be kept in the dark and only told what they need to finish each sprint. Any thoughts?
@Aviva Rosenstein – Early in the article you point out that one of the pain points for UX is the conflicting expectations around quality, fit, and finish. How is this overcome? (Short of the designers letting go and being ok delivering mediocre experiences).
@Aviva — I’d like to see how you address what Daniel mentions above. I’d also like to find out your thoughts on how you can build a top-shelf Design without upfront planning? “Sprint 0” is off the table, and is a falsehood in Scrum – Sprint 0 is just another name for a small waterfall process in front of agile development. So how, without upfront planning can you create a non “bolted-on” design strategy and framework.
I’m speaking not of workflows, but consumer product-driven sites and apps where experience and emotion is paramount. For example, do you know how R/GA works with Agile? or any other big front-end agency?
I’m familiar with Lean UX which is great, but Lean UX is essentially a module – a tactical look at the theme of “design”. That theme then plugs into Scrum – but…where?
I’m trying to know how to deliver the best design in an agile environment without having upfront planning? I’m thinking that you could look at the backlog and rather than delivering “value” for the first 1 or 2 sprints, instead deliver stripped functionality until UX and UI can “meet up” to the functionality, aka – build the nuts and bolts and all the pieces that are design agnostic, while the design and strategy is being crafted,and then begin to use and wrap the design around those pieces of functionality once design has been solidified. This would give the amount of time needed for design and yet, keep the functional development moving forward. This however doesn’t seem to mesh with Lean UX.
I’m struggling with Design in scrum without upfront planning.
Ryan —
I can’t speak to how big agencies do Agile; my experience is mostly in large enterprise. But I don’t recommend building products without at least some up-front planning. And I don’t believe Scrum requires that you do– after all, you need a backlog just to get started, and some upfront planning is required to create it. Scrum is about delivering things faster, but if you don’t have a clear idea about what you’re delivering and who you’re delivering it for, you’re just building the wrong product faster.
The problem is getting specific about what you mean by “design.” I personally don’t think that Sprint 0 is a code word for a “small waterfall process” but it’s probably the wrong term for UX to use– the idea is to be making the big design strategy decisions before development kicks off, not within the sprint framework. There are some things that the leadership team needs to articulate for itself before creating the backlog, or they’re wasting the organization’s time and resources.
Elsewhere I’ve used the term “hothousing” to describe a timeboxed kickoff process where product owners, together with leads from design, engineering and operations, create a shared understanding of the vision of the product, the characteristics of target users, and a measurable definition of success. Those target outcomes must be articulated and shared with the rest of the development team before their sprints can start.
My colleagues at EvolveBeyond offer workshops in the HotHousing method, if you’re interested. http://www.hothousing.com/outline/
I’m with Ryan, I am worried about the UX work and not having it done before the design work. It feels like waterfall.
On one hand, it makes me thing UX should be part of the PO function, spitting out wireframes etc, but is that just legitimising the work ahead? On the other hand if you have it within the team, then the time required to do the search and “design thinking” is too long and will not allow for a story to be worked in a sprint. Or is the UX story just too big, in the same way teams new to scrum struggle to break down their stories to fit in to a sprint.
Great article, and great comments. I’d like to suggest a lateral perspective to add to the topic.
Looking at the “what was working/what wasn’t” list, it seems to me that these – and 90+% of the proposed mitigations – applied in waterfall development as well. The backlog-specific suggestions are among the few that drive down to things that feel Agile-specific.
The “what wasn’t” items pretty much all relate to an eternal issue of cross-disciplinary communication and operational challenges, in which we all tend to view a product or process through the lens of our own specialty. (Ironically, a lot of discussions on the LinkedIn UX board suggest that we are as prone to this as any other stakeholder group, though our practice purports to own the charter of understanding stakeholders’ ethnography first, shoot second.)
In waterfall, the long iteration cycles between intent/design/execution supported cultural siloing in the extreme, exacerbating this natural tendency. By reducing those iterations, Agile forces various specialties into more frequent and interactive contact, which is of course how we learn appreciation for the roles and value of those outside our tribes. That the article so well outlines how we still fall short in this respect, feels to me like evidence that Agile is both increasing the awareness (or at least articulation) of these issues, and also that we still have a long way to go.
Agile is just one of a number of methodologies that have been forwarded to mitigate the long-cycle problems of waterfall; It happens that the development community has been successful in pushing it to the fore. Because it arose from the development sector, it brings with the rapid iteration advantages some developer-centric mental framework limitations.
But Agile as practiced has already evolved from its Extreme Programming roots, and as several point out here, is far from carved in stone as a methodology. As UX practitioners, we have an opportunity to shape its evolution. The way that happens is to bring something to the table that works – gets to a better product insight, faster. We should feel entirely at liberty to imagine an Agile that is defined by it’s intent rather than the specific way it’s practiced.
The better Agile teams I’ve worked with have appreciated this and permit the UX team some license in conducting some ad hoc guerrilla research along the way. The weaker ones adhere to a near-religious belief that putting a build into user’s hands is the *only* way to get insights about user preferences.
I’d bet we all have success stories in which we managed that in some way large or small. Because of the “small chunk” nature of Agile, most would probably be small, like mine. But I’d love to read a collection of success stories of UX guerrilla work in Agile teams to look for patterns of things that worked.
PS:
• Sincere apologies that my comment was so long; I didn’t have time to write a short one that said the same thing. (Don’t ask why I think you have time to read a long one.)
• @Hilary: Great comment about how variable teams are, and how we can learn to ride the wave effectively.
• @Ryan: I like your parallel process thought, I’ve seen it work.
Great article!
I joined a UX team about half a year ago. At that time, we were not at all integrated into the development cycle. The fit and finish was indeed sacrificed for the sake of a functioning MVP. Since then, we’ve clawed our way through the lack of transparency we got from the Dev and PM and are now a part of their daily scrums. I think for dev teams that are less responsive and sensitive to fit and finish, it’s good to keep a hawk eye on the daily builds and personally report any bugs you see. For dev teams more keen on fit and finish, once or twice a week on the standup should be fine.
@David
As for asking the dev team’s opinion on the design, they often have great insight especially around any technological limitation and effort estimates. It’s important to make sure you don’t let those insights impair your good sense of design. Knowing limitations can stunt creativity. The way we’ve been able to work around this is to design what we want first, then take it to engineering for a review of what is and is not possible, and repeat until the design is solid enough to start implementation. For small changes, it usually goes through quickly. For new features or improving something very broken, you may go through at least 3 iterations before you work out all of the issues. Over time, I’ve learned about the reasons for technical limitations. I’ve found that my technical background allowed me to foresee which points were actually limitations and which points were just boundaries that could be pushed. We don’t have to be programmers to understand engineering pain points. We just need to know enough.
I believe that keeping engineers in the dark about what they will be building is generally a bad idea. I’ve been on that side of the fence, and it’s extremely demoralizing when all the decisions have been made for you. It feels as though you have no control, or worse, that your opinion is not important. The least you could do is keep them involved and get their feedback (some programmers secretly wish they could design because they think it’s cool).
I also think that keeping engineers in the dark is a weak approach that can possibly mask other larger issues the team may be having. Don’t hide. If your design is strong, then you’ll be able to support it with unshakeable reasoning. You’ll be able to point out flaws in their suggestions and explain why your design is still better. This is even a good chance for design to show that they are indeed needed in the process. If someone can say something that renders a part of the design incomprehensible or less intuitive than originally thought, then the design could be improved. Good for them for catching an error, it’s what teammates are for. And good for you for taking criticism, it’s how we can piece together a great design. And good for the team for working together.