Integrating UI / UX into agile with developers?


#1

Hey all!

My company just created a role for UI/UX so there aren’t any real processes in place. Any advice with how to integrate a concrete process with developers? Right now, I feel like I’m very much separate from their processes which makes it difficult since I’m a team of one. It’s also very loose on how and when I need to create wireframes, setup review meetings, and conduct user testing.

I’d like to get strict requirements in place for each step of the way, but I’m not really sure where to start. Any help would be appreciated.


#2

Hey

I was a team of one up until a few months ago and I found that following quite a strict process really helped. The key is keeping the developers involved at all stages, communicate really well with them, and also keep stakeholders in the loop from the word go.

The process we follow is:

  1. Review requirements - we work with BAs and a PO so we will ask lots of questions here, make sure the requirements are correct and are understood by all of us etc
  2. Research (if required) - if there are outstanding questions on the requirements, we are unsure about how to approach the task, we will look at how other people have approached similar problems, or go to users to ask more questions
  3. Sketch - (most important task!) we sketch out our ideas, do some brainstorming, and ask even more questions!
  4. Review - we then review the sketches with BAs and PO (sometimes even stakeholders), we may even perform some loose usability testing using our QA team, or some people from support
  5. Technical feasibility check - we show the sketches to the developers, explain our ideas and make sure that a. it isn’t going to take them too long to develop, and b. that it actually can be developed. We will also ask for their input so that they start to feel ownership for the project
  6. Create prototype - we then put the sketch into a computer, sometimes just photoshop, sometimes interactive (we use Axure)
  7. Review - the prototype then gets reviewed by BAs and PO, we may also show this to devs again, especially if the design has changed significantly
  8. Usability testing - we then do more formal usability testing with real users
  9. Amendments to prototype - any changes requested, or if it fails usability testing we do a full rethink
  10. Stakeholder review - hopefully this is the point it gets approved, although sometimes there are small changes
  11. Handover to devs and QA - we hold a meeting to go over the prototype in detail, discuss exactly how this is going to be implemented and make sure everyone is happy

We also stay closely involved during the development, there may be some changes made, if there are any problems, these will be replicated in the prototype so that the prototype stays up to date.

Hope this helps :slight_smile:


#3

Thanks for all of the detail - this really helps a lot!

Have you ever had a scenario with a large project where portions of the project are segmented? ie. Sketches, prototypes, etc. are completed for a portion of functionality then handed off to devs so they start working when you are starting sketches for another? This tends to happen with a lot of our bigger projects so the meetings for each section tend to get a little muddled which I obviously want to avoid.

Also - do you handle smaller changes with the same process or do you skip any steps?


#4

In regards to large projects we will break it down into chunks that can be developed. For example, we are creating a piece of software that allows a user to design a trip and view trips they’ve created. So we broke it down into a set of stories:

  1. Create a trip wizard
  2. View current trips
  3. Edit a trip
  4. View reporting for trips

And even those can be broken down further I.e page 1 of wizard, 2 of wizard etc, that way the devs can work on part of it.

For smaller projects e.g adding a new piece of functionality into the create trip wizard, we can tweak the process to skip sketches and instead amend the prototype directly, but this would only be for individual input fields rather than a whole new page. We will still review requirements and review the changes with stakeholders before dev starts. We also usability test small changes as best as possible.

We try to stay 2 sprints ahead of devs so they have time to plan their stories before doing the work.


#5

Great input from @jacquidow
Agree 100% with the process. Large projects can definitely be broken down into user stories. And I’d also suggest learning as much as you can about your team’s development process and the way sprints are organized. This should give you a better idea of how you can hand over deliverables like sketches and prototypes with the best possible timing. For example, some dev teams will break down their sprints into daily work with focus on a particular feature/screen. So to have a better impact you’ll want to make sure the UI/UX is aligned with that workflow. If you’re interested, here are some templates with some best practices: https://blog.caravel.design/introducing-caravel-templates-5b5f59abc2a0


#6

Thanks!