RAPID RESEARCH
Establishing a rapid research program at Cisco to cut down study timelines from months to days, and setting global date & time formatting standards.
RAPID RESEARCH
Establishing a rapid research program at Cisco to cut down study timelines from months to days, and setting global date & time formatting standards.
Role: Lead Researcher, Program Manager
Company: Cisco
Timeline: ~1 month for model creation, <2 weeks for execution thereafter
Research Method: Varies
Research Type: Rapid
CONTEXT
The Experience Management and Insights (EMI) research team focused on the customer and partner experiences on Cisco.com and Cisco Community forum (~5M monthly visitors), collaborating with stakeholders to unify the troublehsooting, licensing, and eCommerce experiences across our many products and services.
Up to 2023, the EMI research team was conducting only broad, large-scale research projects taking a month or more each, covering the entirety of a complex topic (e.g., "Software Updates"). There was no method to accommodate time-sensitive research questions that needed fast answers, and/or smaller topics that did not justify months of work.
For example, what if we were building a product this week for launch next week, and needed a single question answered by customers before then?
GOALS
Define a rapid research model that can turn out insights as fast as possible.
Implement the rapid research model into existing workflows.
Train stakeholders and researchers on the model to ensure seamless implementation.
APPROACH
First I defined what would be appropriate for the rapid research approach:
Time-sensitive questions.
Bite-sized topics.
Lower-impact efforts.
Early, exploratory work to provide direction for a larger-scale study.
Follow-up work to provide clarity on questions raised in previous projects.
Based on this, I determined we could use the rapid research model for both generative and evaluative work, so long as it was small in scale.
Then I evaluated our existing research timeline and identified multiple areas that could cut down on time, including:
Recruitment: we spent a lot of time recruiting in our own channels, which could be saved if we utilized a third-party recruitment platform like UserTesting.
Scale: smaller-scale studies would mean less time spent writing plans, building tests, analyzing results, and presenting findings.
Execution: restricting rapid research to mostly unmoderated formats (e.g., unmoderated tests or surveys) meant less time spent sitting in sessions.
Templatizing: we were spending a lot of time each study rewriting screeners, demographic questions, introductions, and recruitment standards, all of which could be standardized and built into UserTesting and Qualtrics as plug-and-play templates.
Generative AI: Cisco's internal, GPT-powered generative AI tool empowered us to create study guides and recruitment copy at a faster pace than ever. Given its closed-system design, it is secure enough to take in confidential data, so can also assist in trend-spotting during analysis and writing copy for the report.
Next, I defined the timeline (see left) for a single rapid study, estimating <10 working days from discovery to handoff, depending on project scope.
I validated the model and timeline through a proof-of-concept pilot, then documented the entire process in our team knowledgebase and led a training session so that all our researchers could execute rapid research.
I also presented the rapid research model and proof-of-concept to our entire department, so most key stakeholders would understand the new research approach and knew it was a tool they could utilize to inform their work.
RAPID RESEARCH PROGRAM IMPACT
The rapid research model compressed a months-long process into 10 business days or less, becoming one our team's core research approaches. Since launching, this model has worked for unmoderated tests, surveys, and even moderated usability testing.
Since its inception, I owned our rapid research program and have led 12+ studies, which have impacted decisions* like:
the definition of global date, time, and time zone formatting standards (continue below for full case study).
the cancellation of two potential projects, saving valuable resources and time by halting initiatives that lacked customer demand and were deemed to have insufficient impact to justify the effort (see left for stakeholder feedback).
the naming of a new type of product documentation.
*Note: Cisco has strict confidentiality terms for customer data, so this case study is intentionally vague with respect to results and impact to ensure I meet those guidelines.
RAPID RESEARCH CASE STUDY: GLOBAL DATE & TIME FORMATTING
After observing inconsistencies with how dates, times, and time zones were formatted across Cisco.com and Cisco Community, I connected with multiple Design and Brand teams across Cisco to learn whether we had a company standard on the matter: we didn't.
Month/date/year fully written out, time zones "Pacific" and "Los Angeles".
Month abbreviated to three letters, "Apr", time zone abbreviated to three letters, "PDT".
Month/day/year written numerically.
RESEARCH DESIGN PROCESS:
First, I worked with past researchers, brand experts, and Cisco design leaders to define research goals:
Evaluate the impact of date, time, and time zone formatting inconsistencies.
How might these inconsistencies impact our users?
Evaluate the clarity of different date, time, & time zone formats.
What is the best way, across regions, to format dates and times? Accounting for space limitations, which month and time zone shorthands are the best understood?
Based on these research goals, I designed 30-minute, moderated interview sessions covering:
2- and 3- letter month abbreviations: What do you think these letters represent? (for all 12 months)
JUN, JN
Do you prefer the 2- or 3-letter month abbreviation format? Why?
Rank these time formats by their understandability.
05:00, 5:00 p.m., 17:00
Rank these time zone formats by their understandability.
Eastern, EST, ET, New York, GMT+4, UTC+4
Can you think of a time when the format of dates or times impacted you in your professional role? Tell me about it.
Based on the research goals and timeline, I recruited participants via UserTesting:
N= 16 participants
Screened for:
Representation in all regions we do business (AMER, EMEA, APJC, minimum 5/region).
Range of organization sizes.
Range of roles within organizations.
Actual Cisco customers and partners:
Which of the following companies’ products or services have you used in your job in the last year?
[Cisco quiz question to validate they really have used Cisco]
KEY LEARNINGS
Complex systems require consistent character counts.
Technical users rely on consistency in date and time formatting for dates within their environments (e.g., for things like security patches and software updates), so consistent character counts are a must.
Unclear formatting has caused confusion for users.
While none recalled a specific time when inconsistency specifically caused issues for them, I heard many stories about confusion regarding some date & time formats, consistent with our past research.
Across regions, participants were more accurate at identifying 3-letter month abbreviations over 2-letter abbreviations.
JUN, SEP > JN, SP
Participants confused some abbreviations with industry terms, like:
JUN/JN → Juniper Networks (a competitor)
SEP/SP → Secure Endpoint Protection (a Cisco product)
Once they got one month abbreviation correct, they got all the rest correct.
The 12-hour time format was the most clear across regions.
5:00 PM > 17:00
Time zones that don’t account for daylight savings time lead to confusion.
Not every region observes daylight savings time in the same way, or at all, so when time zones don't call out whether a region is or is not in daylight savings time, it can be confusing.
PST, Pacific Standard Time > PT, Pacific, Los Angeles
RESEARCH IMPACT
Based on my reconnemdations and collaboration with key design stakeholders, we set Cisco-wide standards for formatting dates, times, and timezones across assets.
I shared these standards with the brand team, and distributed them widely in Cisco internal channels to reach a broad audience of relevant stakeholders, including more designers, marketers, communications leads, etc.
These standards left me with a bigger question: What do we do as researchers with these kinds of "best practices" insights?
The Cisco User Experience Design Guide
Inspired by this research, I drafted the first-ever Cisco UX Design Guide, covering research-backed UX best practices regarding things like:
formatting standards,
terminlology standards,
iconography standards,
and general, known user preferences.