Design is often viewed from the creative perspective of classic, creative design, but recently I have been considering an area of UX/UI design that falls within technical and business requirements. Commonly, an product idea will be born — be it a widget or a new database — and the excitement around all the bells and whistles of the new product, let’s call it, New Shiny (NS) will overpower a studied consideration of what the end product will actually embody for the targeted user.
In short, the excitement of technology can overpower the needs of a user.
To shift this paradigm, let’s consider designing from the “work backwards” approach. Though this idea has footing within the world of curriculum development and is embraced by a little company you may have heard of called Amazon, it is not a broadly wielded tool. I believe this tool holds incredible value and should be adopted at will. Through the “work backwards” approach the product manager and associated teams are tasked with envisioning the NS as a fully developed product — to the point of writing a press release and user manual. Through this fully developed visualization the classic “Five Ws” (who, what, where, when, why) of investigation are applied, thereby allowing the NS to be described and explained in detail.
When you manage business requirements analysis from the perspective of UX/UI design, combined with the “work backwards” approach, the process shifts into a proactive engagement that allows a visualization the advantages and pain points of the final design. This shift to a visual assessment will reduce the need for requirements discussions to reopened later in the development lifecycle. Now a few tips to get started with this UX/UI :: work backwards approach to product design:
- Invite all the players into the design process. When ideas are approached from all sides many areas of expertise can be leveraged, therefore adding value to the design process.
- What is the goal of the product? What is being created? Pinpoint the vision as complete, work out how it got there, then create it, but better than first envisioned.
- Initially, do not edit. Simply, let all the players get ideas out fast and dirty — provide loads of pens & markers, whiteboards, post-it easel pads, tables covered in butcher paper and let the ideas pour forth.
- Begin terraforming the raw ideas into a focused plan.
- Connect the dots, eliminate excesses. Begin asking the first round of focused questions such as:
What are the opportunities?
What are the roadblocks?
Identify pain points and added value propositions.
What development tools will be used?
How will teams be connected?
What will prototype deliverables look like?
How will success be measured?
This process could take several weeks or substantially more depending on the company, product, budget, and team size (to name a few constraints). However, in the end – which will be the beginning of development – your team will have a very clear idea of what is expected and a detailed roadmap of how to get to the finish line. It is true that the actual development could become derailed at some point, regardless of how well you have planned, but this “work backwards” effort greatly reduces miscommunication, impractical expectations, while improving the life of the product development team.