This is an excerpt from Principles of UX Design, an InVision e-course by Timothy Embretson.
I know what you might be thinking: process and creativity don’t mix.
You’ve either heard this from UX and design folks, or you’re one of those people who has stated that in objection to timelines and process discussions.
The extreme ends of the spectrum are dangerous: businesses tend to be overly tied to process and the fatal “We’ve always done it this way” mentality, and creative and other folks tend to push for endless time to create the perfect solution.
Everyone needs to wake up.
The integration of user-centered thinking and product development requires structure.
Software, in order to make money, needs to be in the hands of the end user. The ends of the spectrum need to move more closely to understanding each other.
And all parties need to understand something: your paychecks come from selling something.
“Your paychecks come from selling something.”
Flexibility
If you’re involved in any sort of software product development, you’ve undoubtedly heard of terms like waterfall, agile, lean, and iterative.
These words—I’ve deliberately avoided calling them “approaches”—are largely myths. It’s currently a popular trend to come up with new ways to work through the same UX problems to deliver the same end result. One month, documentation of any type is dead. And the next month, wireframes are outdated in favor of whiteboard and paper sketch delivery. At the latest conference, the entire visual design career is discounted in favor of in-browser designing.
Image from Inside Design: Trunk Club.
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 UDIDs and red lines 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.
This is important: the flexible approach to delivering software shouldn’t be misconstrued as Pollyannaism, 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 successfully install a UX practice, or even elements of a UX practice, you need to be able to discuss timelines. As a UX practice matures, global project plans will evolve organically to include UX. Until that time, we’ll work through each barrier and outline some typical situations likely to occur.
Image from Inside Design: SoundCloud.
Barrier
Almost no time will be allotted towards UX deliverables. Project plans and timelines will likely be created in a vacuum, and UX won’t have a voice. As incremental UX deliverables are integrated into projects, keep track of time to know how long it took to work through. Use this as a base—and double it—as when project plans start be more inclusive of UX.
“UX is either at the table when project timelines are being created, or driving them.”
Apprehensive
As sporadic supporters are identified, leverage those relationships to build more ideal timelines. Deliverable creation duration will start to expand from hours or days to allow more time to work through ideas. In the same vein, the UX problems should be more complex, so more time is needed.
Supportive/advocate
The experience for these 2 personas will mostly be inline. UX is either at the table when project timelines are being created, or driving them. Either way, inclusion isn’t an issue except in rare circumstances when all teams are crunched. The biggest things to watch out for: suffering from too much time and over-engineering.
Work-in-progress
Underlying all of this is the need to proactively share work with all impacted project teams throughout the process. Work-in-progress sharing allows teams to understand the process and approach from beginning to end.
Image from Inside Design: Wix.
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.
The grand reveal needs to cease to exist. Collaborative co-designing of software product development creates a greater sense of ownership in all parties and delivers a stronger product to the end user.
“The grand reveal needs to cease to exist.”
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 marching 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 will derive from listening to your users at the outset of the project. Ideally, this includes an equal amount of qualitative and quantitative research.
If your organization doesn’t currently invest in insight user research, it’s vital to push back on overly-directive business requirements and design the experience via written words.
The Golden Rule regarding requirements: Tell UX what needs to go on the screen. Don’t tell UX how it goes on the screen.
“Tell UX what needs to go on the screen. Don’t tell UX how it goes on the screen.”
This pushback will likely cause initial friction because business analysts, who are responsible for creating requirements, tend to fill the UX vacuum when there are no UX professionals responsible or 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.
“Foster positive collaboration instead of a takeover mentality.”
Requirements need not be final before UX work begins. In fact, as they’re being developed it’s beneficial to quickly work through potential approaches via whiteboard or paper sketching. This allows teams to collectively vision the end product and potentially move away from overly directive or poor decisions. It’s a fatal move to develop requirements without UX involved to direct resources away from making decisions based on end-user needs.
Process is vital to UX work. It doesn’t need to be overly defined, and it certainly won’t stifle creativity.
The most important element to remember: be flexible and open during the creation process.
Timothy Embretson grew up on a small Iowa farm where he learned to appreciate solving problems with simple ideas. Armed with a degree in graphic design and a passion to advocate for users above all else, he has helped businesses of all sizes solve complex problems. He is currently challenging traditional retail at Best Buy in Minneapolis, Minnesota.
