5 Myths About the Analyst-Designer Relationship
Myth # 1.
Myth: Analysts are the sole subject matter experts when it comes to understanding the business needs and leading process engineering. Designers are responsible for the design and user experience, irrespective of the business…
Myth # 1.
Myth: Analysts are the sole subject matter experts when it comes to understanding the business needs and leading process engineering. Designers are responsible for the design and user experience, irrespective of the business functionality.
No way! There is no design in the world that is divorced from the business process associated with it. The way a design is intended to work feeds directly into how it looks and feels. Analysts, who have valuable knowledge about requirements and what it is that a design needs to accomplish, are incredible design resources. They should be involved in collaborating with designers to create meaningful solutions for design challenges.
This goes both ways – business processes need redesigning too sometimes, and designers are especially good at looking at processes from the lens of the user and working with analysts to transform and reengineer them to make them more effective.
Analysts and designers together create a balance of skill and capability that drive the success of the product.
Myth # 2.
Myth: Analysts and designers should communicate via scheduled meetings and formal channels. These regularly scheduled meetings ensure designs are handed off in a timely manner.
Wrong! Design is nebulous – it is constantly evolving to meet the needs of both the user and the business. Analysts are uniquely equipped with the tools to provide insight into the requirements, policies, and restraints that drive design. As such, they should be a part of the design process from beginning to end – from discovery to wire-framing, the process should be one of constant conversation and collaboration. Analysts and designers together shape the design and, by the end of the process, should both be able to speak to the design and what it accomplishes with complete confidence. And because both groups have been a part of this process from the very beginning, there should be no hand-off meeting – when collaboration is done correctly, “handing off” doesn’t exist, so there is no formal meeting necessary.
Myth # 3.
Myth: Once the design is done and the user story is written, the requirements are locked and there is no going back. This sense of accomplishment – and better yet, of certainty – at finally landing on the right solution is hard to beat.
Look out – this mentality is dangerous because it can create a false sense of certainty! One integral aspect of Agile is the concept of feedback loops and constant iteration, which can only be possible if both designers and analysts are comfortable with the ideas of flexibility and responding to change where it is necessary. Ultimately, the analyst and the designer serve a larger purpose than just seeing stories and designs to completion – it is both of their goal to build the best product possible that balances both end user and business needs. And to do so, they need to be open to feedback and open to owning changes, even late in the process. As such, even after a feature is done, there should be room to go back to a design and iterate on it if needed. There is no finality to the process that should prevent either one from going back to ensure the best possible solution is being developed.
Myth # 4.
Myth: Developers become a part of this process once the stories are ready to be worked on.
No! Developers are absolutely essential to the software development process and as such, should be involved as early as possible. Getting a developer involved early on in the design process prevents designers from designing solutions that are not technically feasible or overly complicated. It allows for developers to have input into the screens and flows they are building, increasing not only the designer’s understanding of what the team is capable of but also developer investment in the design itself.
Analysts and developers should be collaborating early on too, working together to write effective user stories that will be as clear as possible to the team and product owner. They also work together to create estimates of stories and map out timelines, scope, and technical architecture.
Myth # 5.
Myth: Analysts and designers do their best work when collaborating with people who have the same skills as them. Bringing in an analyst would only hinder sketching sessions. And to think of including a designer in a process reengineering session would be a total waste of time.
Not true! All together, designers, analysts, and developers work together to create a cohesive team that builds on each other’s strengths to ensure optimal workflow and collaboration. Each role brings its own strengths, and as such contributes to the software development process in a unique way.
What this means is you will always be more productive if you work with people with diverse skill sets. As a designer, limiting yourself to working only with fellow designers will ultimately lead to a design that will inevitably not be as good as it could have been. The same goes for analysts and developers.
If you walk away with one thing from this article – it is that you can’t do this alone. No one can. The more you collaborate, share, and grow – the better your product will be!
You Might Also Like
Meet Mindy Bohannon, Agile Analyst and Xpert on our Innovation team. Mindy sat down with...
At the recent AgileDC conference, Ricardo Abella and I co-facilitated a session entitled “The Value...
Offshore development remains a popular choice for businesses to offset expensive technology costs. According to...