Collaboration between developers and product design specialists is essential
Developers hate change requests. When someone changes their mind, this means fresh coding, fresh QA testing, and extra work for everybody. This is inefficient and not terribly productive if you are building the same thing multiple times. Debbie Levitt explains why this can be mostly or wholly avoided when engineering collaborates with UX.
DevOps is often defined as the processes, operations, methodologies, tools, and culture surrounding a company’s software and systems development.
But engineering doesn’t operate in a vacuum. Blueprints, ideas, designs, and concepts come from product design specialists who decide layouts, flows, and interactivity. These are non-engineering individuals and teams who share DevOps’ goals and desired results. DevOps is truly about recognizing how many teams are involved in the software development process and finding better ways to break down silos and bring everybody to the table.
However, many engineering teams often find UX to be siloed, difficult to collaborate with, and not Lean. Many flavors of Agile exclude specifics on how to work with product designers, some even going as far as to suggest that UX specialists be removed from the process.
It’s tempting to circumvent UX when they seem like a department that eats up time and budget. However, UX research, design, testing, and iteration are invaluable aspects of the software development process. With DevOps focused on building the right product for customers, improving internal efficiency, and fostering corporate culture, your expert product designers are great and necessary collaboration partners for developers, QA, and Engineering leads.
What happens when we don’t correctly gauge customers’ needs?
Skype recently announced that its 2017 redesign, which aimed to make it more like Snapchat, was a failure. Users didn’t want, need, or like the new features. The backlash was large enough that Skype made a 2018 announcement that they would redesign Skype again.
It’s possible that Engineering and Product loved the idea to make Skype more like Snapchat to attract younger users and went straight into building it, racing to get it to market. However, research with target users could have quickly revealed that these features were unwanted. Killing the project or pivoting at this early point could have saved Skype millions of dollars plus bad press and customer alienation.
Efficiency, productivity, and getting to market quickly won’t matter if you are delivering a product that customers dislike or don’t want to use.
Collaboration between developers and UX
Remember Agile Manifesto Principles. Your highest priority is customer satisfaction by building valuable software. Give every team member the environment and support they need, trusting them to get the job done. Maximize the amount of work not done. Continuous attention to good design enhances agility.
The collaboration must begin when product or project managers are deciding features and prioritization. A project with no value to the user can be removed, saving untold time and money and maximizing the work not done. Projects that are moving forward need to give UX practitioners a huge runway so that appropriate research, design, and testing can start.
The best method for daily collaboration is to embed your UX Designer in the Agile team. Invite them to release planning, stand-up, retro, and every meeting where the functionality or interface might be discussed. Don’t make decisions without them. If your teammate missed the meeting, wait until you can find them in person, over chat, email, or any method your company uses.
Assign questions, ambiguities, or bugs to your UX teammate in JIRA or your preferred bug tracking system.
After the long runway, make sure that UX is two or more Sprints ahead of what the rest of the team is working on.
Research, design, testing, and iteration before developers write a line of code
It’ll save time, money, and sanity while increasing the ability to build a more valuable product that is right for target customers.
Developers hate change requests. When someone changes their mind, this means fresh coding, fresh QA testing, and extra work for everybody. This is inefficient and not terribly productive if you are building the same thing multiple times.
This can be mostly or wholly avoided when Engineering collaborates with UX. By using UX’s formalized process, a feature can be vetted before developers write a line of code. Any aspect of the feature that does poorly in UX testing can then be reworked and tested again. Developers then receive the tested and approved design, and only need to build once.
Valuable product > Timing and budget
Eric Ries, author of The Lean Startup, asks, “What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget?” Even if your organization isn’t using Lean methodologies, the warning still holds true. DevOps’ desired results echo this when we aim to build the right thing for the customer, improve customer satisfaction, and develop features with high customer value.
Knowing your customer, involving your customer in the process, and building for their true needs and preferences is ultimately more important than timelines, budgets, frameworks, and tools. Trust that if you build the right executions of the right ideas, the revenue will be there.