My design leadership portfolio, by my personal hype tool, Chat GPT.

So, Chat GPT and I ‘discussed’ my career and this portfolio. It gave me advice about more details I should add to my portfolio, which I will now have to do because it is right.

So then I asked it what jobs I was qualified for and why.

Shelby Bower | Design Leadership Portfolio

Shelby Bower is a senior design leader with over two decades of experience in product and service design, design operations, and people-centered systems. This portfolio outlines the core roles she is most qualified for, demonstrating her breadth of leadership, systems thinking, and team development expertise.

1. Director or VP of Service Design

Shelby brings deep expertise in enterprise-scale service design, human-centered systems, and org-wide innovation. At DocuSign, she led initiatives in career development and mentoring frameworks impacting multiple departments. Her ability to move between strategy and execution, facilitate large workshops, and align UX with business priorities makes her a strong fit for executive-level roles.

✅ Why Shelby Fits:

• Led enterprise-scale service design at DocuSign, especially around career development and mentorship systems

• Creates systems that go beyond UX — including operations and HR (e.g., new career frameworks adopted across departments)

• Facilitates org-wide workshops with hundreds of participants, showing cross-functional impact

• Experience in both MVP and long-term strategic design planning

🧩 Ideal Fit:

• Tech companies, SaaS platforms, healthcare/HR tech firms, or innovation hubs looking to humanize complex systems

2. Head of Design Operations or Design Strategy

Shelby has successfully implemented scalable systems, including design systems, hiring processes, career laddering, and mentoring programs. Her systems thinking, combined with operational empathy, makes her ideal for orgs maturing their design practice or optimizing cross-functional collaboration.

✅ Why Shelby Fits:

• Reimagined design team hiring, leveling, and promotions processes at scale

• Created design systems and infrastructure that helped teams ship faster

• Spearheaded design-led HR programs (mentoring, promotions, career architecture)

• Strong systems thinker with a human-centered approach

🧩 Ideal Fit:

• Design-forward orgs scaling quickly or undergoing restructuring

• Enterprises seeking to increase design team maturity or systematize growth

3. Design Team Lead / People Manager

With over 14 years of management experience, Shelby is known for empowering teams, mentoring talent, and fostering a psychologically safe culture. She effectively sets vision, drives craft excellence, and supports designers through ambiguity and change.

✅ Why Shelby Fits:

• 14+ years of people management experience

• Widely praised for supporting growth, elevating team ideas, and amplifying underrepresented voices

• Helps teams thrive under ambiguity, showing both creative and emotional intelligence

• Coaches designers through real-world UX challenges (e.g., UX Academy mentorship)

🧩 Ideal Fit:

• Teams needing calm, strategic leadership through change or growth

• Design orgs emphasizing collaboration, inclusion, and mentoring

4. Design Ops / People Systems Consultant

Shelby has designed and delivered people-centered systems around hiring, promotions, onboarding, and DEI. She bridges design and HR to create effective, human-centered org processes, making her an ideal consultant for companies in transition or growth.

✅ Why Shelby Fits:

• Successfully implemented new talent systems across DocuSign

• Built career architecture for design that was adopted cross-functionally

• Acted as a bridge between HR and design — using service design to make people systems more inclusive and effective

🧩 Ideal Fit:

• Startups or mid-size companies that need structure

• Larger companies rethinking hiring, promotions, or DEI frameworks

5. Workshop Facilitator / Service Design Coach

Known for facilitating strategic workshops with 100+ participants, Shelby combines research, ideation, and prototyping to align diverse teams and generate clear outcomes. She’s skilled at helping teams navigate complexity and drive forward momentum.

✅ Why Shelby Fits:

• Led multi-hour workshops for 150+ attendees, resulting in high-value prototypes and alignment

• Designs her own facilitation tools and has strong storytelling/facilitation presence

• Comfortable across stakeholder levels, from execs to new ICs

🧩 Ideal Fit:

• Organizations looking to reboot their internal innovation or alignment

• Enterprise product teams preparing for a strategic pivot

6. Conference Speaker / Thought Leader in Design & People Systems

As a recognized design speaker (e.g., Design Leadership Summit), Shelby is a clear, confident communicator on topics like inclusive systems, UX strategy, and team design. Her blend of storytelling and systems knowledge makes her a compelling voice in public forums.

✅ Why Shelby Fits:

• Presented at the Design Leadership Summit on transforming HR with design

• Maintains a professional web and social presence that blends credibility and approachability

• Clearly communicates complex systems and team experiences

🧩 Ideal Fit:

• Brands investing in design reputation and thought leadership

• Conferences, publications, or podcast platforms focused on design and leadership

Virtual First Primary Care

One of the biggest problems in American healthcare (besides cost) is the shortage of providers. From physicians to nurses to mental health professionals, it’s getting dire at every step — from finding a provider when you need one, to being able to make an appointment in a reasonable timeframe, to getting the treatment you need near where you live.

One of the most promising solutions is virtual care. It’s efficient, it keeps sick people out of public spaces, it addresses localized provider shortages, and it’s good business for healthcare — better access for more patients also means more patients seen and paying (let’s be honest, it is a business).

There’s at least one big barrier: A majority of patients still believe they have to see their doctor in person to get good care, even if it’s inconvenient and difficult for the simplest of conditions, like ear infections or dermatitis.

The truth is, about 80% of visits — particularly for common conditions treated by primary care, the entry point for all care in any health system — can easily be virtual.

No one needs to work that hard to get care or see patients.

Enter, virtual first primary care:

• 2-3 days virtual, 2 days in-person appointments

• Primary care plus support for chronic conditions, like diabetes or obesity

• Staffed to address more holistic patient needs than typical PCP clinics

• Shorter appointments —> higher availability

• Use of patient-facing technology to streamline every visit

In practice, this supports:

Faster, more complete understanding by staff of what’s happening for patients, achieved by standards for consistency that support a cross-disciplinary care team

Chronic conditions treated in one clinic instead of through several specialist referrals, unlocked by having pharmacists, social workers, and eventually other specialists like mental health providers on staff.

Streamlined appointments focused on time with a patient, achieved by using patient-facing tech for tasks like check in, reason for visit, and check out

What I did

I had the benefit of working with a physician who was running a pilot of this model, so we were scaling and enhancing an existing operational model.

These included maximizing the use of electronic forms and patient onboarding so that 15-minute appointments could be spent providing care, not typing; SLAs in place for 4-hour or less response time to patient messaging; more modern clinics that had the ability to support patient-friendly technology; and better technology support for patients whose visits were mostly virtual.

So, in a way, designing this as a scalable service was pretty easy. In a whole other way, I had to work with some pretty squirrelly technology — Epic, the relative standard for electronic health records and its patient-facing view, MyChart.

I designed a prototype to share with the full team after running an ideation workshop. (Screen shot below. More could be shared in an interview.)

I socialized it with everyone who needed to buy in, including the IT team. When I departed they were building out the operational model and technical requirements.

How I did it

So many people have experience with the weirdness of MyChart that I won’t describe it all (also it would be a novel), but let me just say this: most of its weirdness is tied to operational inconsistency across provider practices.

Such a mouthful, so in plain English: doctors who set up their practices want to do it their way, and system IT teams typically bend over backwards creating customizations for them. This creates a big mess when you start looking to improve the entire system. And then there’s Epic, which is even weirder.

I had to learn a lot about both systems to design this as a scalable service. I also had to lean pretty hard on the technology team responsible for the current state; I’m reasonably certain they didn’t know why they should work with me at all, when to them, this looked like just another clinic.

Conclusion

Healthcare and its delivery in the United States is one of the most inhumane systems I have ever come across, which may seem an odd conclusion when this work was setting out to improve things for both providers and patients and has a pretty decent model to achieve that goal, at least on a small scale.

What I mean is this: for a system that is supposed to be about providing human beings with care provided by other human beings, it is not built to support either set of human beings.

I visualize it as the monolith in 2001, but bigger, standing between both provider and patient as a behemoth set of barriers, including

• linear protocols for diagnosing patients based on symptoms that don’t leave room for listening compassionately and treating holistically, making providers seem like automatons speaking a different language

• a business model that incentivizes quantity when its users (patients) need quality, while providers may well prefer to focus on giving higher quality care to fewer patients

• regulatory requirements that are well-intentioned but create a bureaucratic maze worthy of Kafka, and

• extractive, exclusive health insurance (in the US)

• financial barriers for patients, who bear the cost of a system that is so expensive to run

Three phone screen sketches of the public-facing content about a Virtual First Primary Care Clinic.

Hiring, smarter & better

In the summer of 2020, a few months into my new role, my manager said, “you get to hire someone!”

Great news! We need more people.

So here’s how that went:

1. 93 days average time-to-hire even though I had 500 applicants within three days of posting the role and we were supposed to be scaling fast

2. Sink-or-swim — I had to figure hiring out as I progressed through each step, at the expense of candidates

3. Senior was our level default not because we needed the craft level but because we needed negotiators who could hold their own

4. “We only hire (visual design) rock stars” was the ethos even though the ratio of skills needed in the role were about 80/20 in favor of UX over visual and the work was not, well, Lollapalooza-level exciting

5. No internal awareness across hiring managers similar open roles across design

6. ~90% of applicants appeared to be white, and ~75% men (we couldn’t truly track; this is what I was able to notice)

7. Every “yes” = way more work which affected who I brought into the process

8. Our XF partners’ interview skills did not meet the bar, which discouraged candidates

9. By the time I sent out an offer I was so worn out I would have happily hired my cat

What I did

1. No one had ill intent; these issues show up policy-heavy processes.

2. I could set aside more time for me to review applicants, but that had limited potential impact and required even more effort to patch up an unwieldy process.

3. I don’t really do quick fixes or band-aids. Nine times out of ten doing that pushes problems and complexity downstream.

I needed to make meaningful and safe improvements, starting small and building trust in my ideas over time.

Below is a summary of what I accomplished over the course of two years. It’s too much for paragraphs so I’ve summarized here. I used each change and its impact to guide what I pitch doing next.

Our average time-to-hire went from 93 to 65 days.

---

How I did it

Wait, we can use design methods to improve more than just digital products?!?!?

I saw where we were and what seemed like both a reasonable and ambitious place to get to. Getting from one to the other needed a flexible plan — which is what a strategy is, the plan for how to get from one place to the next, better one.

Starting small, I joined the Talent Guild which gave me a way to understand the landscape, design the improvements you see above, and the authority to make them official with leadership. The Guild also gave me a way to officially partner with our Talent Lead. Without her input and feedback, none of this would have worked out.

If you look across the top row of that table you scanned, you’ll see the order I addressed and changed things in: diversity of candidates and eventual new hires, shifting the hiring philosophy to something more strategic, getting the career ladder to a place where it’d be useful for more than one week a year (reviews), and shifting the burden of the process from one person to a shared effort across the manager cohort and other team members who needed the skills in hiring.

Conclusion

I came to believe that the career ladder is actually the key to many more things than I originally thought.

In the interview process specifically, a well-developed ladder with an up-to-date list of specific skills the practice and business need can help you

• write job descriptions that reflect what a person will actually be doing all day

• give people who hire a shared way of seeing the process

• assess applications and conduct interviews with an eye toward specific skills and the level we need to see them practiced, instead of looking for “unicorns” which still do not exist

• provide partners with the language and common definitions for good questions, and coach them with material that helps them assess answers well

• at the end of the hiring process, make a decision based on whether or not a candidate can do the job, not impress us in an interview

Design maturity FTW

Wherever I go, I try to leave things better than I found them.

Simple to say, harder to do, and sometimes even harder to recognize.

I use time-tested methods of strategy and design. I apply it to how I set up and run teams, develop partnerships, and see impact.

Whoa! obvious Problems

When I was asked to take on a team of nearly 20 designers and managers at DocuSign after a tsunami of executive and leadership departures, I started out like I usually do: listening, watching, and talking to people.

I saw

• a set of overwhelmed managers, lead designers who felt stifled, and mid-level designers craving mentorship

• three separate teams of designers who almost never spoke working on “editions” of the same SaaS enterprise product

• a sub-par user experience that designers felt they were having no impact on

• a leadership team that believed design was there to execute on a vision, but the vision couldn’t be developed because of…

• dangling product strategy questions about whether or not we’d integrate with the company’s flagship product, which stalled vision and design work

I started by mapping out the process and all of the red flags I saw in it.

The Diagnosis

We had

• a product that wasn’t so much a product, more a disparate, disjointed, kinda-sorta “workflow” thing

• a process that was simply not friendly to design or designers

• product managers incentivized to ship but not focus on quality

• engineers working on an aging tech stack — minimal changes only, please and thank you

• a high percentage of churning customers who would declare on departure that “this isn’t a DocuSign product”

I drew out a huge whiteboard on Miro with the process, my goals for improvement, and a big space in between for ideas on how to get there. I filled it, then deleted half the post-its right before I talked to my team to see how they responded and what they thought.

View fullsize

Changes I made

In the changes I decided to make first, I prioritized the team’s health and actions I thought would have a high impact on motivation because.

Here’s what I was able to do in the time I had (6 months before another re-org):

I moved designers from a product-centric model to a core jobs to be done model so that everyone would learn about similar functionality across editions without breaking the flow of work.

I asked lead designers to be responsible for a job to be done category, supporting product quality overall by leading critique and mentoring designers with a focus on de-duplicating and bringing better continuity in. This gave them a differentiated role from senior designers.

I also asked leads to use what they learned about inconsistency in conversations with engineering leaders to start bringing the idea of streamlining the user experience and product, which helped them start seeing better impact.

Managers were moved away from managing design work to managing relationships with product so that we could mature the conversations, which helped us get more involved in up-front planning — when we could propose research and testing.

I started escalating the product strategy issues to senior leadership in product experience and in forums where I had a chance to ask questions about it, which helped surface the need for clear decision making at the executive level.

The changes started to take hold and we started moving forward in more productive ways. Had I stayed in that role, I would have kept going with my plan, evolving it as I saw impact and need.

Best. Workshop. Ever.

About 3 months after running an effective priority- and roadmap-combining workshop for two European teams, word got around, and I was asked to do another workshop for our Growth team.

At first it sounded rote and normal: a workshop about alignment and priority setting, with roadmap items emerging, but then... I learned there would be over 100 people, it would be in person, and the goals were ambitious for a DocuSign get-together.

---

What I did

So… I’m gonna need a bigger boat. I got to work on:

• Designing eight hours of in-person ideation workshops spanning 2 days for 170 employees across all major functions — marketing, design, content, engineering, growth, and their leadership

• Recruiting and prepping nine facilitators and a photographer to facilitate 30-person breakouts

• Supporting the selection and organization of a venue that would hold all of these people, work for the activities I designed, and purchase all the supplies (have you ever bought and transported 200 Sharpies at once?)

How’d It Go?

The space was extremely… hotel beige. People started out ambivalent, not knowing what to expect. Pretty soon they were shoulder deep in (compostable) Post-its, making new connections, and building partnerships that wouldn’t have otherwise existed.

---

---

All the activities we did over two days.

Sounds fun, but what were the outcomes?

Most importantly for where DocuSign was at, I was able to

• Facilitate conversations that built unified momentum for relevant business change that will continue for at least two years

• Galvanize our product-led growth teams to action, exploring shared ideas for reaching ambitious goals that went into their OKRs

• Help Growth executives build a successful case for the CEO to include the ideas we developed in the product team’s roadmaps

• Make the Product Experience team look great at a moment when the products were under a lot of (warranted) experiential scrutiny

The most gratifying outcome was what people said to me afterward. I was approached by multiple people, including sponsoring execs, who told me that was the most effective, engaging gathering they’d ever attended for work.

I’d be happy to chat more about how I chose the activities I did, how I designed the interactions, and how I kept the energy up for two whole days in a beige ballroom. This piece would be much too long if I explained all that here!

Lastly, here’s an update from a design leader about a week after our workshop:

Building a global design team

When I started in 2010, we had more creative directors than designers.

There were two designers in Australia, four in Buenos Aires, and regional creative directors in the US, Sweden, and Australia.

The VP who hired us had successfully made the case for incubating a creative capability, after gathering data that told him 40% of their deals were lost because they didn’t have an in-house design team.

Time and time again in pitches, prospective clients asked for design to be part of the team, not an add-on with an expensive agency that didn’t understand the tech and would deliver unworkable designs.

What I did

1. Built credibility with pitch work

2. Enabled and directly supported growth from 6 to 100+

3. Supported strategic growth plans for the global practice

4. Operationalized design in the consultant force

Building credibility and growing the team

At first, we had creative directors essentially zipping all over the world trying to find work to elbow their way into. Every now and then they would score and get more involved in a pitch. I would coordinate creative explorations with designers, the Creative Directors would clean up slides, then use exploration work to do the storytelling needed. It worked — we were winning deals, much bigger deals. People started asking for the creative directors to participate.

This is when my work kicked into high gear, because I was there to help the team get organized and coordinate.

I saw the need to create a flow of information between team members that didn’t involve me personally translating everything for everyone. Complicating this effort, we worked across time zones that were not friendly to doing this easily.

I created and refined async tools so that work got done and met expectations. (Guess what we didn’t have? Slack.)

I did that just in time, because now we needed to scale to actually do the work we had proposed. I persuaded our VP to let me hire ahead of demand for the work I could show was coming to us.

Our hiring efforts went so well that we ended up with 100+ designers.

Seventy-five of them were in Buenos Aires. Everything from making sure teams had offices with places to take client conference calls, to supporting team members in gaining confidence to be on those calls, to making sure they all had the right licenses, and managing workflow globally, fell to me. It took a while, but I was able to gain the team’s trust that I would deliver improvements to their work environment and we could run a smooth shop.

Zoom In

A small example of the things I worked on: licensing software. Early on, when we had about 15 designers on the Buenos Aires team, there was an unexplained slowdown in velocity. When I asked about it I found out that they were all sharing a Photoshop license. (Also: No Sketch or Figma yet.)

So I went to our VP… who asked if Photoshop was really necessary because it was expensive, and wanted me to investigate if the team could “just use MS Paint.” Aha! Now I knew why license requests had not been made.

A second operational effort I took care of was career ladders, because hiring was continually on the struggle bus without it. Our job titles were for developers and we didn’t have a way to talk about career planning with our teams or candidates.

So I found the right person, got a crash course in career ladders from HR, and built out the first of three comprehensive career ladders I would build in my career for information architecture, visual design and user experience.

Third, I had to sort out our engagement model.

With our teams working in remote locations, and the way creative work happened in bursts followed by a lot of waiting, the “butt-in-seat” model of tying a name to a contract and location wasn’t going to work.

We needed work to flow around the studio so that one person wasn’t over-allocated while others sat around and waited for something to do.

I had to make the case that we could not attach names to deals or project plans in estimates or contracts, which was the typical practice, and the project team would start out working through me to move the work to design teams.

This was not scalable, as you can imagine, so I had to delegate pretty quickly once the pitches were won and deals signed.

Finally, we had skill bias issues show up. I was doing a regular check-in on how projects were going when a designer told me about the 6-hour phone calls he had been on for the last month to support developers rebuilding from scratch something he already delivered three weeks prior.

SharePoint sites at the time ran off of something called a “master page” which was really just UI display styles.

Developers across multiple projects were straight up not using the ones we were delivering.

(Honestly, they were glorified style sheets. I still don’t see why it had to be so hard.)

It turned out they didn’t believe a design team from Argentina could do that work.

While I would have loved to declare “you’re biased” and have that fix it, I had to demonstrate the efficiency and budget hits project teams were taking because of this behavior. It was pretty easy.

Strategic growth and operationalization

Now that we were popular and growing, it was time to start looking at moving through the last incubation gate and becoming a “real team.” In 2011 the leaders got together in person to come up with how we would do just that.

Two items in our plan fell to me — revenue recognition for deals we helped sell and getting estimates automatically included so we didn’t have to negotiate scope twice for each project.

The thing about working remotely for a 10,000-person organization is that you have to know how to find people. I had to figure out who had all the sales tracking spreadsheets, and then I had to find the person who owned our estimating model. That took about a month.

For sales support, first I had to get us included at all in the documentation for sales, which took about three months. Then, to get a number that didn’t look like double-dipping on claimed revenue, I had to make a case for what our share should be. I was able to figure that out and persuade the Keeper of the Spreadsheets to have a column for XD added. This got us on the way to being a profit center of our own, so that once we moved out of incubation, we could continue to hire ahead of demand based on revenue we generated for deals that would become projects.

Then there was the estimating model, a gargantuan spreadsheet. Once I found the right guy somewhere in Australia, I had to explain that our work could not be back-figured based on a percentage of engineering, and that we needed both exploration and production time in our estimates, so no, 4 hours for a complete set of wireframes and 8 hours for detailed design was not going to cut it.

Two months later, our estimates were included in every deal we helped pitch and win, all over the world. This grew our footprint and our revenue.

Summary of what I learned

Do you ever look at a piece like this after you’re done writing it and think, “Wow. I did a lot of things”? That’s what I think about this one.

If you read the whole thing, you probably noticed that I spent a lot of time anticipating needs and saw the phrase “make a case” quite a bit, and that’s really my point in telling this story.

Most of scaling a team and getting it to a self-sustaining, growing profit center in this context is about seeing what’s coming and being able to build a case for what the team will need soon (but preferably not right now).

I had to learn how to make a business case for everything from decent office space to flexible workflows for a completely new organizational function. It took quite a bit more groundwork and storytelling than, say, arguing for a new developer certification.

And while I definitely had support and guidance from our VP, our creative directors were much too busy to manage anything I was doing. It was not the first or last time someone who had not worked in design would be my direct manager.

Being able to do what I did for this team takes good instincts for building a business and strong creative problem-solving muscles I still use today.

Accessible investing

There is almost no subject more thought about and less discussed than money.

One piece of the money space that seems to make people the most angry and frightened — often to the point of avoiding it altogether — is investing. But unless we are independently wealthy, all of us have to do it to keep pace with the rate of inflation — at least in the United States, if we ever want to stop working.

And yet, in our society, it’s not okay to admit you don’t understand financial instruments or the stock market or how 401(k)s work. Not learning or avoiding it leaves millions of people in a combined state of ignorance and unpreparedness.

What does this mean? This means that we’re about to confront a retirement crisis in the US. (Spoiler: It’s already happening.)

I was hired at Morningstar to help change that.

My metric for success was simple: raise the national average rate of saving for retirement by at least 1%.

I mean, what’s the point of tiny goals?

Investing speak ahead:
For people who want to know if I know what I’m talking about — Morningstar wanted to use Goals-Based Investing, where you set a time horizon, an amount of money you’ll need for drawdown over time, and you are delivered options for a model portfolio that matches your risk tolerance. Then you move your money in, add to the account over time, and voila! Pretty soon you are okay for retirement or other goals.

Morningstar was also behind the curve on what people called “robo” tools, a trend that didn’t exactly work out that well in the end for anyone.

(Let me warn you now: this story does not end happily, and that still occasionally brings a tear to my eye. In fact, when the product manager broke it to me we both cried because we were so committed to solving this problem.)

So, what did I do about it?

Defining lots of moving parts

My earliest collaborators were a lead researcher and a behavioral economist. We looked at models we could use and how to translate them into a combination of education and product, we thought about what kind of support a service like this might need from real people, we went into homes to talk to people, and then we talked to more people.

When it was time to add some pixels to the mix, we chose a few psychology theories and Morningstar methodologies to design an onboarding flow that was mobile first. We talked to more people, testing the heck out of it until we got to a Tinder-like flow for choosing financial goals and a conversational onboarding flow.

We also had to think about where people would be putting their money, which really meant what we were going to do with Morningstar IP and technology. We chose our goals-based model portfolio creation tool, talked to the team that owned it, and started integrating that into the product. That was pretty hard, from a design perspective, to do on a phone. We thought most people would probably move to a larger screen for that part but still designed for a small one.

We also had to figure out how transactions would run once people opened an account. We chose a custodian and set it up to run through Morningstar’s existing registered investment advisory (RIA). Custodians handle actual trades, deposits or withdrawals when people invest in a new portfolio or it needs to be rebalanced. We started integrating their tech with ours.

Just as it was all coming together, when we were ready to pull all of that together to execute on an MVP, the company pulled the plug.

For those of you interested in the evolving design-y aspects of this work, including what I created… well, honestly, I tried but because it’s a service, not a product, it just doesn’t lend itself to a sensible set of visual deliverables... there’s just way too much work for a blog post to do it justice.

I am more than happy to share it in a conversation.

Modern Portfolio Theory FTW

40 years ago, the mutual fund was a relatively new thing. It was this amazing way to diversify your investments, to spread risk, which is what all good investment professionals will tell you: never put all your eggs in one basket.

But… who picks those eggs, and how?

Enter Morningstar, which built revolutionary tools and data visualization around the mutual fund. One such revolutionary tool was called Portfolio Builder.

Portfolio Builder lets you choose individual stocks, look at their fundamentals, past performance, and other factors, and add them to a collection voila! You built your own model portfolio (not exactly a mutual fund, but close). If you were really good at stock picking, that portfolio did amazing. Go, you! Then you get to maintain it, rebalancing and choosing new stocks forever!

Here’s what it looked like:

A highly complex mutual fund portfolio tool

(Did I mention I started this work in February 2020?)

The most helpful part of the tool was the Allocation modeling at the top right, because it told you what sectors and categories you were adding and how they were balanced.

Fast forward forty years, and no one does it like this any more.

This was the challenge laid before me by the CPO — what would we need to do to bring Portfolio Builder up to date?

As I soon found out, the problem is no one does it like this any more.

In fact, the inverse is true of the process. Here’s what happens:

Model portfolio builders set up industry segments they want to add to their portfolio, like large cap, energy, and other criteria. They add return parameters like ESG rating, risk tolerance, and other factors like Sharpe, and they run a query against a database of stock performance which spits out what should be in your portfolio, how much, etc.

Basically, auto-balancing without human choice. It’s cleaner and better. It’s one way AI and machine learning can actually benefit investors.

People use a variety of tools to do this.

At Morningstar, analysts were using a monstrously slow Excel spreadsheet to build them. (Not the Portfolio Builder. When I asked, I heard “why would I do that?” a lot.)

So I set about designing what a portfolio builder would have to be able to do to adapt to new processes.

I had to deeply understand the factors involved in building a new model portfolio, how they affected one another, and how decisions got made by analysts to design this tool.

What did that look like? At the end of putting in all of your variables, it delivered this:

All along the way, the CPO was pleased with the work. It was clear I understood the problem and the design was graceful, it tested well, everyone understood how I was laying out performance and factors, etc.

But when he asked me what the plan was to make our current portfolio builder into this, I said what I had discovered by talking to the product owner: “we can use the data, but we can’t use the flows, UI or current backend code.”

Which infuriated him and surprised me. After all, I laid out the progress the entire way. Nothing was a surprise.

I drew out the two flows that worked in reverse of one another: the old process was about building something from nothing, while the newer way was a process of elimination, working backward from a universe of all mutual funds and stocks.

Sad Trombone

I left Morningstar a month later.

It was not the first or last time I’ve been told that an organization was not ready for my level of innovation work even though I was explicitly hired to do just that.

To some, that will look like a failure as a designer. I should have been able to persuade! Convince! Succeed! Spin up a new team! Get an investment!

Find a way to make Portfolio Builder work!

In that way, this is not a good piece of product design work, because there is no product at the end to show for it. Innovation that goes nowhere isn’t a success.

But… you want to know if I can redesign a current product that meets user needs in a hands-on way. Now you do. If there had been investment, I could have led the redesign easily. It was a proven idea, a proven flow.

Post Script

I found out much later that Morningstar is littered with ideas like mine, designs that were tested and valid but couldn’t be built without a serious reconsideration of the current technology. You have to have an appetite to do that in the c-suite.

It doesn’t fit with big bang quarterly announcements for a public company.

I also like to think that someday, someone will disambiguate the tech stack from the data that underpins it. Morningstar already sells its data to companies that have done just that.

—The End—