UX CASE STUDY
Product Initiation Kickoff & Socialization System (PIKS)
CHARM
CASE STUDY HIGHLIGHTS
-
ORG & SECTOR: Fulton Bank, Consumer Banking & Strategy
MY ROLE: UX Strategy, Research & Design; Brand Identity; Product Design; Project Management of Beta release; and development assist.
TEAM: Consumer Strategy Business Sponsor, BA intern, App Dev & me
PIKS: Product Initiation Kickoff & Socialization
-
Getting others to understand the actual request of the Business Sponsor (many false assumptions that this was something “simple”).
Working with a shared & temporary business analyst intern assigned this “simple request” to handle on her own.
Exposing true breadth of this work effort.
Squeezing this into SharePoint rather than an app reusing foundation created for 3PAC.
Getting appropriate development help for a project this magnitude.
-
I modeled appropriate & patient handling of discovery, user empathy, clarifying questions, workflow, and proper scoping for the BA intern.
Instead of making up our own rules, we closely listened to the sponsor.
I connected all of the cumbersome pieces that often prevented any forward movement on business strategy ideation.
I brought project back on track from being an afterthought to something we could realistically complete.
I reused step-by-step approach created for 3PAC, to make development simpler.
I explored game-changing potential with Consumer Strategy senior leaders.
After BA intern left, my SharePoint dev and I painstakingly persevered.
-
Consumer Strategy Business sponsors were thrilled that we delivered beyond their expectations.
Potential exists for this system to inform the organization’s decision makers — potentially saving incredible amounts of resources.
-
Building the RIGHT thing, versus building yet another thing
User testing
High-fidelity prototyping simulations
Contextual interviews of Business Sponsors
Time-savings, Idea progression, Socialization of ideas, Inclusion
KEY TAKEAWAY
Explore possibilities in prototypes where it’s cheaper than developed code.
Understand the problem space. Be prepared to challenge assumptions.
Oftentimes I’ve noticed projects slide completely under the radar and then come out of the woodworks with a READY FOR DEVELOPMENT sticker. When, in reality, the project is NOT ready for development nor for anyone. Design Thinking specialists call this a Challenging Assumptions exercise. In my experience, it must be handled with tact and patience.
This project started out that way, from a source that didn’t know any better — a temporary, shared, departmental business analyst intern who had been asked to detail the flow of an unknown process never before discussed. Turns out, this was the VERY END of that unknown process.
Submits Form - what form? What information is in the form? Just this snippet alone triggered more questions with no answers when the intern presented this “simple request” to the development team.
Back to discovery. Back to the original request’s source.
This project required some reverse engineering — starting with an ideal final state and working backwards exposing all of the unknowns. With the intern, I modeled taking proper inventory of everything available to us at the moment (Everything on the Table), highlighting what we needed to confirm or get answered directly by the business sponsor. With answers rather than assumptions, we looked at ideal solutions, the bigger picture and what the entire workflow should ideally contain (rough sketches shown).
Then we zoomed in, taking inventory of all mentioned dated and manual documents the Business would inconsistently use during their early stages of ideation, sponsorship, and approval — searching for them from various archives, printing them out to review the details and translate acronyms, comparing and combining them to form a master listing while removing redundancies (not pictured).
Define a new product with an understandable theme.
As I explored an appropriate identity around which to center product design ideas, I recalled a series of books that had always intrigued me in later elementary school years — the Choose Your Own Adventure books that put the reader in control of the storyline that unfolded.
It felt appropriate, as the steps that would unfold for the user of this system-becoming would be determined by the path they took at any point along the journey. It also felt like a way to infuse creativity and enjoyment in a process that should be full of innovative energy, rather than stifled under the weight of a mountain of governance before it even has a chance to inspire beneficial change.
It also felt like it captured the innovation that the Consumer Strategy leaders — newer to the company — were attempting to embody. It was a solid and well-supported approach that could grow exponentially in the right conditions.
Break complexity down to its simplest step-by-step roots.
To keep with the theme of a journey that unfolds, the very first step was designed to be a blank slate until the first few choices are made (left side). This sets into motion the next questions that should be asked in the preceding steps (right side). I intentionally explored all options within my prototypes; therefore, one set is completely aspirational, no holds barred.
If you’ve seen my 3PAC case study, this layout should look somewhat familiar, as I combined an intentional reuse of the wizard-like step-by-step progress tracker at the top, meant to function as we’d already created. The content utilized Material Design form standards and progressive disclosure for answers toggled to “yes.”
“In the midst of chaos, there is also opportunity… Opportunities multiply as they are seized.”
— Sun Tzu, Chinese military strategist, quote from “The Art of War” from about 2,500 years ago
Detailed prototypes tell the entire story & workflow.
No guesswork needed.
TALL PICTURE ON RIGHT shows a snippet of some of the innovative magic I’d envisioned with this system — the ability to connect it directly to a smart database of products.
BOTTOM PICTURE shows my full exploration of connecting PIKS to a product database (customer-facing products and employee-facing applications). Mind you, though, a product database that was in its infancy within IT’s technology stack. Intentionally aspirational, these flows previewed a visionary future state for Business Strategy and IT Leadership teams, showing potential of a smart system that connected desired work efforts from Business to, once approved by senior committees, the eventual planning, resourcing and creation on the IT side — greatly benefiting organizational strategy, unity, project management, ROI, and better defining KPIs of work undertaken.
After prototyping each of the steps with no technical constraints, I knew I had GOLD IN THE GROUND that must be shared, and although this wouldn’t be our first targeted build, if I could share the potential with senior leadership teams it just might get them talking. After all, they had already started to build a collective knowledge base around employee-facing applications on the IT side, with joint efforts from the Enterprise Architecture, Project Management Office, and Change Management teams. This seemed like the perfect opportunity to marry Business Strategy’s perspectives and values with IT’s initiatives.
Always advocate for the humans affected.
My goal has always been to be an advocate for the people who are trying to accomplish a goal through the interaction with digital design. Being able to see the bigger picture of the deeper connections that can carry through with intelligently designed systems is the feather in my hat.
One of the steps I was most passionate about was Step 3: Potential Human Impact. This section was a rework of a previous scoring system I’d revamped with the Enterprise Architect who was also brand new to the org. The potential to impact the customer experience was also briefly mentioned in the outdated business product ideation documentation I’d reviewed early in Discovery, enough to know it was an important consideration.
I took this as an opportunity to define Human Impact on a weighted scale that all stakeholders could consider to inform the decisions they’d have to make.
Ensure a new product can be found and accessed from a logical place.
How do your users find the new product you’ve created? How is it accessed? How do you give it appropriate context and understanding? How does it coexist with other resources?
These are some of the questions I consider for the environment in which the new product will live. If the new product is hard to find, or accessed through a blind link or a random bookmark that you’re expecting people to create, it might not be findable and usable in the long term. New people should be able to find it on their own. Colleagues should be able to understand the context of the product and in which world it lives and functions. It should make sense.
It should be marketed within its organization.
It’s not enough just to be.
Keep calm and persevere.
One of the largest hurdles I experienced was not having appropriate development support to build any version of this prototyped system. This was the result of the project request not coming through the standard channel of prioritization by the middle layer of management — and instead coming directly from the upper layer of management. Which left me caught in the middle, having strategized, conceptualized and detailed all prototyped flows, but now needing to have developmental resources committed to building an MVP version.
Following my manager’s suggestion, she suggested I might have a small window with 1 developer’s help to make it come to life in SharePoint IF I could get everyone aligned. I devised a plan to bring all key stakeholders back together again to share the discovery and design work that had taken place since the original initial request. To light a fire under getting this going by aligning those above me.
It wasn’t ideal, but I could make it work.
Everyone either loves or hates SharePoint.
SharePoint is a tool that can help others to get things done and collaborate with others. It definitely wasn’t the ideal tool to build the innovative and game-changing solution I’d envisioned. But having it come to life in some form was preferable to only ever having Adobe XD prototypes alone.
The movement to being built in SharePoint required a simplified workflow to be planned, designed and specified for SP development. A simplified and achievable MVP, PIKS Beta, was born. I had to come up to speed with SP architecture, Nintex form design & development, and a whole new level of patience.
“This is the bar to which we should hold everything we do.”
— Andrew F., Consumer Strategy Director, in support of PIKS
Strike while the iron is hot. Repeatedly.
If the iron isn’t hot enough, find additional sources of heat. Give it everything you have. Find as much help as you can. And, if you’ve exhausted your options, take a breath and find a way to make good on commitments you’ve made. Heroics may be necessary.
To get this through release, I stepped into an additional Project Management role. I mentored and guided the SharePoint developer, keeping him engaged and on track. Once my spring-summer UX intern started, I immediately tasked him with as much front-end development as he could handle. I started working closer with my collaborator and ally in Change Management to help me include other senior leaders in the company (to prevent possible derailment) and to help with revised final content.
I made achievable yet aggressive project plans and saw to it that we met them. When it became obvious we needed more development help, I stepped in to tackle Nintex and get us through the finish line. Overall, the experience provided numerous learning opportunities I’d apply moving forward.