In the consulting world, UX and engineering have a tendency to be delineated. I often see companies hire a UX specialist or “design only” firm that offers UX consulting services to support their efforts and relay their consultation, essentially, to another group of consultants. In this era of hyperspecialization, there is a strong business model to establish focus and productize the best and brightest experts. Because of the uniqueness of the code, personalities, training, best practices, recruitment pools, etc. — consultants can operate in a UX-only world, providing high quality and affordability.
The challenge arises after the completed UX design schematics are delivered, approved, and accepted. That is when a “traditional” UX team’s involvement ends. This can even happen when a consulting firm offers both UX and software engineering, as frequently they are considered separate services.
Business transformation requires a better model
Specializing in business-critical projects escalates the importance of my projects and intensifies the seriousness of my efforts. My team is often charged with designing an internal or customer-facing solution that is very unique and with specific goals. Frequently, inputs to our process are limited to references to their brand and client feedback on their legacy applications.
In addition, at Headspring, we operate our projects on a fixed-cost basis. This means it’s very important to get design milestones done right and early in the process. It’s important to solicit as much client feedback as possible in order to utilize that input into other aspects of the UX and UI design schematics.
What this means is that operating as independent consultants to assist application consultants is the wrong model. We cannot design in a vacuum and deliver to a specific spec, only to wash our hands when our part is done. Both client interaction and holistic project success prohibits this.
The benefits of embedded UX and UI
The best practice of embedding a designer or design team into the project team seems more expensive on the surface; as do most fixed-bid projects. That is until the product ships on time and on budget with incredibly happy users (then it’s best ROI the client “has ever seen!”).
I am an evangelist and here’s the three main reasons why.
- Good design is worthless if it never sees the light. When a UX designer or a UX team comes up with requirements completely disconnected from the development team that is to implement those requirements, there is a very high chance that a big number of those requirements are not feasible or viable. It may be a great design, but it’s critical that the development team is on-board with implementing it.I’ve seen, when I have been the liaison of personal and client input to the developers, that when the UX is embraced and accepted earlier the assumptions that impact the tool are better defined.
- Collective buy-in and team commitment is more important than most realize. The engineering team and any designers must all buy into the look and feel of the product. Collectively, they are responsible and will not be happy to have others judge their work without knowing the context and history behind their decisions. This affects morale, commitment and efficiencies.Making the designer(s) a part of the team — a team that scrums, talks in hallways, is introduced to the stakeholder — ensures they are part of an agile process. This supports frequent and deliberate changes while also keeping everyone on the same page, and without skipping a beat.
- Shared best practices. Sometimes the design isn’t only about design. There are ingredients to a successful project that include external and internal stakeholder management. Utilizing agile methodologies alongside solid project management tools ensure I am always learning and I am not operating in a silo. This has made me and my team better designers.
“Proof is in the Pudding”
At Headspring, UX and engineers are part of the same team, working together side by side throughout the duration of the project. All of our designers work on client projects where they have ownership of the UX effort; they can always count on review and validation steps that include both the client and developers. We take our user-advocate role seriously, but we are also very aware that viability and feasibility are crucial for a successful delivery.
A good example of how this works for us is demonstrated in a case study of one of our energy client’s database rewrite projects. This one part of the very large endeavor was specifically about a new UX/UI. Because all business data is tracked inside the tool that is utilized by dozens of employees across multiple offices, the rewrite was relevant to how the whole project was architected.
It became the charter, therefore, to not only improve the system, but also improve all business-critical processes. The legacy app was the only source to provide functional reference. Therefore, to stay aligned to the project charter the project was no longer about how to make the software better, scalable, safer; it became about how we could make the company more efficient.
If we had not been a complete team, the designers would not have learned about the opportunity to revisit the processes. If we were not able to maneuver with collective agility, we would not be able to focus on the charter and win on that goal. Not only did the client get an updated, web-based system of record (which is what they initially asked for), they also got a uniformly more productive organization.
In a nutshell, this is how Headspring excites our clients: We do the unexpected that ultimately leads to a better product. In this case, the unexpected is for a client to meet a UX designer as part of the project team.
If you are in UX, I urge you to stop handing off pretty comps and start embedding yourself into the team. The rewards of being fully embedded in an agile organization, doing hands-on work throughout the development cycle, and being treated like every other member of the team is something to strive for because it’s achievable… and rewarding.