Which camp do you were fall into
Do you believe that timelines and process kill creativity or do you believe that a predefined rigid process is the only way to get something done?
At the far end of this spectrum, extremely dangerous business practices can be found.
So with this I'm going to preach flexibility
I think we can all agree that the integration of user-centered thinking and product development requires structure. But it also requires creativity around user engagement, design and utility.
Also we should to be wary of the need to make money. This means the product needs to be in the hands of the end user.
These words (I’ve deliberately avoided calling them “approaches”)
It’s currently a popular trend to come up with new ways to work through the same problems to deliver the same end result. One month, documentation of any type is dead. And the next month, wireframes are outdated in favour of whiteboard and paper sketch delivery.
A more realistic and humanistic approach is to simply be flexible. Some projects require more detailed documentation than others. For some, you may be able to partner with a developer and draw your wireframes on a napkin over a beer, and for others offshore teams may need overly complex functional specifications, annotated wireframes and interactive prototypes to appropriately deliver your product. Flexibility allows teams to collaboratively define the approach for each project. The best laid plan is specific to the product at hand, the money and time available, and the resources working on the project.
The flexible approach to delivery shouldn’t be misconstrued as being disorganised, and it certainly doesn’t equate to being a pushover.
You must be firm in your rationale for required deliverables and your approach to each project.
Timelines and Process
In order to be successful with a UX strategy or even elements of a UX practice, you need to be able to discuss timelines. As project plans grow they will organically include UX. Until that time, here are some barriers and outlines of typical situations that are likely to occur.
Barrier
Time allotment will have no relevance to the actual items required to be delivered.
Project plans and timelines will likely be created in a vacuum, and UX and UI won’t have a voice. To this I say speak to the people who are doing the work. Have them agree how much time something will take and have them take ownership of this time allocation (if you work with the same people on multiple projects you'll get an understanding of how individuals quote time and you can adjust project plans accordingly).
Supportive/Advocate
Once you have all your resources agreed to and how much time individual deliverables will take, then you own those resources for those allocated times. No other project should infringe on your allocated workflow and on the flipside you need to meet the deadlines set out by your project plan or meet your deliverables when they are due. The flexibility comes here by tracking your burn rate on a daily basis and having your project plans with sufficient detail to know every deliverable element and the exact number of minutes required to achieve each item. You should know long before a deadline that you are not going to achieve it, allowing you to adjust expectations and due dates accordingly.
Work-in-progress
Underlying all of this is the need to proactively share work with all involved throughout the process. Work-in-progress sharing allows teams to better understand the process and approach from beginning to end.
UX and creative teams, especially agencies, are known for intaking a project and going behind the scenes for weeks at a time before the grand reveal.
At this point, the timeline is exhausted. And if there’s objection, the timeline suffers—and, ultimately, so does the end user.
Prototyping and co-designing of product development creates a greater sense of ownership with all parties and delivers a stronger product to the end user.
Business Requirements
Central to software product development is the creation of business requirements. It’s common for UX to react to requirements and create deliverables in response to hundreds of detailed orders. We must change this.
User-centered product development represents this change. Insight user research drives project goals, requirements, and success. All requirements and engineering approaches should be derived from listening to your users at the outset of the project. Ideally, this includes an equal amount of qualitative and quantitative research.
“Tell UX what needs to go on the screen. Don’t tell UX how it goes on the screen.”
Think ofbusiness requirements as a list of goals, how they appear on the screen is up to the UX strategist.
Pushback
“Foster positive collaboration instead of a takeover mentality.”
This pushback will likely cause initial friction because business analysts, project managers and producers, who are responsible for creating requirements, tend to fill the UX vacuum when there are no UX professionals engaged in the project. They may view this as a takeover of their work.
But this isn’t the case—their role is extremely valuable, and they can be great partners in helping the UX movement. Foster positive collaboration instead of a takeover mentality—it’ll build a bridge to future work.
Okay, I realise I may have just stated a bunch of things that you probably think about everyday. What is important to remember here is that being flexible throughout in tire project process is the most important step in the creation of an amazing product.
This is an excerpt from Principles of UX Design, an InVision e-course by Timothy Embretson.