8

I'm looking for published case studies or research on how a UX team can approach a full site redesign with an Agile dev team.

Specifically, I'm looking for examples that go through what foundational work the UX and UI team might do before a line of code is written in the first sprint.

I've been in Agile projects on both sides of the Aisle (both UX and Dev) but these were mostly all in your typical 'enhance over time' situations where the initial site was already there to work upon.

What I'm thinking needs to happen is that UX needs to have some time to work on a foundation of visual design, UI patterns, interactions, along with all the usual work (flows, personas, etc.) before it makes sense to have dev begin sprint 1. Is that a fair assumption? Does anyone know of any documented examples of such a process?

A simple example of a concern I have is dev may split up site features on a sprint-by-sprint basis. But all site features will need to share a common UI layer of HTMl, CSS and JS that likely needs to have some foundational work done prior, as you wouldn't want to end up with entirely separate HTML and CSS for each individual component.

I realize that not all UX teams are also UI teams, so, alternatively, I'd also be interested in any documented process that includes the UI construction process separate from UX.

|improve this question
  • 1
    Documented, no. Anecdotally, yes it's a waste of time to let devs start coding piecemeal, Agile or otherwise. Currently working on UI/UX ideation & mockups for redesign of an educational site w/tons of legacy content. Programming is begging for individual lesson template mockups to start coding so they don't fall behind on production/performance standards. Many common components & interactions haven't yet been designed or tested, but they're worried about their deadlines. Devs' time would be better spent learning/refining techniques to implement designs efficiently. Saves time in the end. – mc01 Feb 3 '15 at 21:51
  • @mc01 Can you clarify what you mean by devs' time would be better spent learning/refining techniques? Our team is starting to embark on this journey and the team's new to agile. – nightning Feb 3 '15 at 22:31
  • 1
    I meant that their skills are only as good as their last project & may be fading fast. If they're new to agile, they can use time while UI/UX is laying groundwork to figure out what their new workflow & testing practices ought to be. By learning/refining I meant they can use that early time to experiment with new code frameworks, update to best practices, and decide which tools are best for the job - it might not be what they're used to. Along those lines, building a pattern library is an example of a way to efficiently implement designs that can be done at this stage. – mc01 Feb 4 '15 at 17:22
7

I have done this several times and am currently in the process of doing this for several related enterprise products. We are going about it in phases. For large projects, you don't really want to scrap what exists and build fresh. There have been studies about how frequently those fail. If this is for a small scale project, then the answer would be different.

  1. Button up the UX framework. If the site is not already using a pattern library, start using one. Some call it a "pattern library", some a "functional pattern library", others "style guide" (though what I'm talking about is much more than that, and others "experience language.". I personally go with experience language as I look at it like a visual language + interaction design. Here's an example: http://www.bbc.co.uk/gel

You want the front-end framework in a state where it's easy to globally manipulate. For me, right now that means implementing Twitter's Bootstrap and styling it in a way that works with the current design. Then when we overhaul, we can much more easily restyle all of the building block elements into what we want. The devs can be working on that while you complete the next stuff.

  1. Conduct UX research and design wireframes that meet the needs of your end goal.

  2. Hone the experience language and build in any desired interaction nuances and other elements you might need.

  3. Create style tiles or similar to get a good idea what the visual design will look like.

  4. Prototype your designs in actual code in a sandbox environment. With a good team, building prototypes and iterating in code is the fastest process, will give you more actionable designs, and be a lot easier to test with users and gather accurate insights.

  5. Refine the style, the experience language and the prototype until you're at a releasable state.

|improve this answer
  • I agree with all of this! Have you found any published papers that state as much? – DA01 Feb 3 '15 at 22:41
  • 1
    @user1337 This seems sound to me as I am currently dealing with a similar situation. I would also be very much interested in any publications or references on this. – Okavango Feb 4 '15 at 7:40
  • Although the name is a misnomer, "style guide driven development" is a term some use to describe this. Here's one presentation speakerdeck.com/mattfordham/styleguide-driven-development There was an article out a few months back about overhauling vs building new, but I can't remember the name. It cited a lot of sources. I should probably be writing my own stuff on this :) – user1337 Feb 4 '15 at 22:20
2

For your MVP (min viable product), UX has to be done first. Once your MVP is ready then you can do your both UX and Dev agile. Otherwise, it will be a waste of time for your Dev team to code and re-code based on the UX changes..

Sorry I don't have a documented white paper on this, but have plenty of personal experience.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.