R.A.D.A.R. — UX Design Wrapped with Architecture & Research
What is RADAR?
TL;DR
UX RADAR is a process of wrapping design with architecture & research, including: Formative User Research, UX & Product Architecture, Design, Architecture Validation, and User Research Testing.
First, what problem is RADAR solving?
As our UX organization and demand grew, Product Managers began to go around our existing UX process and go directly to Designers to request work. While this was great for collaboration, important steps in our design process were skipped and several issues arose:
- Designs were created without the proper research
- Designers didn’t have import architectural implication knowledge when designing
- Designs were handed to Engineering without proper Design System adherence and UI Platform compatibility checks
- Features were implemented without proper customer usability testing and validation and issues weren’t caught until it was too late
We had the skills on our UX team, but we needed to formalize a process that was easy for our cohorts to understand.
UX R.A.D.A.R.
RADAR was conceived to ensure the proper order of operations for a UX request had been properly researched with real users, architected with proper connective tissues, usability tested, and benchmarked for continuous improvements.
In a larger UX organization, RADAR is broken out for several UX sub-teams and individual team members. In a smaller UX team, RADAR represents the many hats and tasks team members will interchangeably conduct.
Research
Input: PM request or new concept
Output: Synthesized research
When a request comes in (via UX intake form), the Researchers would work with stakeholders to put together a learning plan and interview customers to ensure the viability and desirability of the concept. Since many requests come in, we’d collect related subject matter areas before talking to customers.
Dovetail is a great tool to capture the voice-of-the-customer (VOC) with video & audio records which are transcribed, tagged, and turned into insights.
Architecture
Input: Synthesized Research
Output: Information Architecture (IA) & Journey Maps
UX Architects work closely with Product Architects to ensure the feasibility of the concept in this phase. Platform and API Architects should also be consulted for potential implications. UX Design Producers play quarterback with Product Managers to ensure all stakeholders are on the same page before moving into design.
A tool like Miro is typically very helpful to convey mindmaps, journey maps, and all types of architecture.
Design
Input: Research, IA & Journey Maps
Output: Mock-ups & Prototypes
By the time the task moves to Designers, the concept has been fully validated for viability, desirability, and feasibility. The research package also comes with proper information architecture, journey mapping, and product feature integration mapping.
Whimsical, Figma, Adobe XD, and Sketch (with Invision) are all great options here. When possible, I personally still love a coded prototype.
Architecture
Input: Proposed design
Output: Design feedback & best practices
UX Architects, the keepers of the Design System and UI Platform, review all outgoing mockups and prototypes to ensure:
a. The overall design adheres to the Design System (Figma, Sketch, or similar)
b. All components will easily convert to coded UIs (React, Angular, or similar)
c. API features are considered and feasible
Research
Input: Prototype reading for testing
Output: Actionable test results & UX score
UX Researchers validate the final designs with real customers & users by conducting usability tests. Typically at least one round of revisions to the design will be necessary, so allow for this in your planning!
Most importantly, in this round of research make sure to capture KPIs and metrics to benchmark your UX score including behavioral and attitudinal performance. It’s important to gather several types of data points to track usability (SUS or similar), task completion, effort (CES), satisfaction (CSAT), promotion (NPS), etc. There are many options here.
Is RADAR some new type of Agile alternative?
RADAR isn’t meant to replace your current process. It’s meant to augment it with best practices and enforce the proper order of (UX) operations. Conceptually, RADAR builds on principals and lessons learned from Design Thinking, Design Sprints, and Lean UX.
While RADAR shares similarities to Design Sprints, it isn’t time-boxed into one or two weeks. Each task can occur in parallel for different projects.
RADAR is a Design Marathon that is an ongoing, sustainable process that is much less prone to burnout than a Design Sprint.
RADAR lends itself to a Kanban process nicely, but can certainly work within SCRUM Sprints with the proper acceptance criteria and definition of done.
Regardless of which approach you take, the RADAR model will help ensure those UX inputs and UX outputs (listed above) are always validated, and that important steps aren’t skipped.
Credits & Collaborations
RADAR is a concept that was conceived in joint collaboration with my brilliant peers and team; Jenn Medellin, Scott Robinson, and Mike Erickson.
