Integrating Outside Design Firm
First off, to anyone responding to this: thanks for taking the time!
I'm in a mid-sized, if unconventional, scrum team working on an internal software development project. We're working on rebuilding a few systems that our organization already uses, but which are not ideal; this new project will merge all three systems into one, with different points of entry. We have already hired an outside firm to do UX research on the pre-existing systems in order to determine what is and is not working for our users.
Now, we are looking to move forward with some UX/ UI design for the new product. We are still a ways off from being finished, but are starting to work on the front-end framework that we will be using in the final product. As such, we'd like the visual design to reflect the direction we end up taking as soon as possible. More to the point, we would like for our software and UI design to reflect the kind of interactions that will be ideal for our users.
As we don't have a full design team in-house, we're considering three options: hiring an outside firm to work with us in an agile fashion, hiring a contractor to join the team for a period of time (either full-time or at least 3 days/ week), or a hybrid of the two approaches.
Has anyone worked on a large-scale project with a 3rd party design partner like this and, if so, how was the work tied to the development process? How would folks suggest moving forward and what pitfalls could you advise us against?
Some of the problems we can anticipate include:
Slowing down the pace of development we've already established
Missing key user experience issues and opportunities due to only working within the limited set of features of each sprint
Having the expense of this work run away from us (due to lots of iterations and refactoring)
Communication issues between the designer/s and the development team
> ...we are looking to move forward with some UX/ UI
> design for the new product. We are still a ways off from
> being finished, but are starting to work on the front-end
> framework that we will be using in the final product
How can you move forward by designing one layer? Regardless of how designers are resourced, how do you intend to deliver built, tested, integrated, and release-ready increments each Sprint?
That's exactly the question, Ian.
If we had someone embedded in the team, they would be better able to be integrated into our development process and, perhaps, work on mockups for the following sprint during each sprint (or something).
We were thinking of having a firm or contractor work on some of the work that has been done, as well as general guidelines (colors, general element styling [form fields, buttons, etc.], typography, etc.) which could then be applied on sprints down the road. That said, this does seem to hit a pitfall of not considering the whole of the user experience and user flows as they progress through the software.
To be clear, this would not just involve "designing one layer," but figuring out how to integrate either a firm or a contractor into our process. I'm just not sure how this works with scrum. It was a lot easier to sort this out with a waterfall-type project.
We already are delivering built and tested increments each sprint, but we're trying to figure out how to integrate a more polished design process without continuing to kick the can down the road. Even more critically, considering that UX is a lot more than just look and feel, we're concerned that our current process of test-driven development is leaving the experience of a real human user out of the process until way too late in the game, which is why we'd like to involve UI/ UX experts or an expert as soon as we can.
Does that make any more sense?
> If we had someone embedded in the team, they would
> be better able to be integrated into our development process
> and, perhaps, work on mockups for the following sprint during
> each sprint (or something).
What about adding value to the current Sprint increment, as opposed to mockups for use in the next Sprint or guidelines "which could then be applied on sprints down the road"?
Granted, there may well be a UI/UX input into Product Backlog Refinement, but you won't embed or integrate skills in the team if they aren't also contributing to the Sprint Goal.
As long as the essential skills for creating the increment are present in the team, and being used for that purpose, you can resource them how you like.