A temptation exists in tech work environments to do your job and only that job without thinking about the entire landscape of the project, or the end-users.
It’s usually not your fault, lot’s of projects get planned from above but the projects vision isn’t communicated well. In fact in most environment it’s not communicated at all.

In most environments web work is task based. Each person is given a piece of the vision puzzle to work on and once your task is complete it gets tossed over the wall to the next team member who takes your piece of the vision puzzle and runs with it.

So what happens when that piece of the puzzle is confusing to the next person? Worse, what if the piece was confusing or communicated poorly to you? It’s like the old game of telephone but the final product here isn’t a badly mangled phrase it’s a product that needs to ship.

If teams don’t communicate well at the outset of a new project the whole program is at risk of failing or falling behind due to the lack of membership.

This is how we run a lean UX process for small “as built” features at Nova Southeastern University where I work.

This is a basic sketch of how we employ a User Centered Design by working one or two sprints ahead of the development team in a “Sprint Zero” approach.

1. Meet with end-users and build user profiles based on the info gathered.
2. Have a stakeholders meeting with the whole team to look at the old “as built” feature. The whole team at Nova includes User Experience User Interface Team, Business Analyst, Project Management, The Developers and anyone else I’ve forgotten. Just invite everyone okay.
3. After the Kickoff we have a post-mortem and sketch out ideas, later I mockup the best of them into clickable wireframes.
4. Test the wireframes with users and make any changes aka iterations.
5. Test the wireframes again, make final iterations.
6. Polish the wireframes into high fidelity mockups (also clickable).
7. Deliver the final assets to a development team and shepherd them through their process.
8. Attend weekly sprint demos making sure the product or feature is being developed as intended.

Working with a strong Business Analyst to build and refine the Business Requirements Document is key to the success of this approach. Yes, the BRD will change as we build and test. Yes, that’s what I said, the BRD is not static. Sorry BA’s, I’m a heretic I know but unless you make updates when you uncover things you didn’t think of in the beginning the process won’t be as successful.

Did I mention invite everyone? You get the picture.