Photo by Dan Hodgkins on Unsplash

Strategy work

Strategic thinking has come to the forefront of necessity at times for me, in various workplaces over the years in the following ways:

  • Immediate and long term audience behavior
  • Migration work
  • Revenue models
  • Workflow transition

While this has not traditionally been indended for the roles I was hired for, it was something I had to develop early on in my career when co-founding a design firm. I needed to do it for my own business at the time so it’s become part of who I am.

This was a lot of my focus when working at a cosmetic reviews company. The web site has a very large daily audience with a lot of potential actions they could take. Which actions they can find easily from the array pages they land on are very important for the ongoing value of the site. A lot of goals the company previously had for the site had changed and many teams were working to change the site to reflect those new goals. One area that hadn’t changed was the top level or “global” navigation.

When I started looking at what could be improved in global navigation, there wasn’t much internal ambition for anything like the significant changes I could tell were going to be necessary for the future. From previous user testing, I knew that there were major issues preventing most of our audience from using the global nav. I started a new round of tests to gather insights directly about the navigation and variations to it and I found that the experience gaps only grew in number and width.

For example, this is what the navigation was: Hidden on mobile, desktop-first, complex, and focused on joining, searching, creating content

and this is what it needed to be: Mobile first, simple, visible, informative, trustworthy, and focused on guidance

With such a dramatic shift in what it should be, this became more about strategy than most projects. I needed to re-think this from the ground up, so that’s what I did.

Each one of those touch points (mobile, simple, visible, etc.) I took and explored with design and user testing. From tree tests, to wireframes, to mockups, and prototypes — I narrowed down to what each of those touch points means for the audience and composed them into best candidates for A/B tests.

What I came up with turned out to be a fundimental shift in both interaction as well as intended action. I needed to identify and optimize the new actions our audience should to take in order to accomplish their goals. I needed to inform and assure our audience that the actions exist and that RealSelf is the most appropriate place for them. An awareness and mindset strategy.

Revenue models

At the same company I was asked to start testing the waters with landing pages for paid traffic from Google and Facebook advertising. After a few page types and audience targets were tried out, 2 consultants were brought in at around the same time to share their expertese in selling leads and using paid traffic. The leads specialist showed us what I guided experience could do for completion metrics and what I designed from his advice proved to have an exceedingly high conversion rate. So with that, we had a good pillar to use for something.

The paid traffic specialist spoke about many things but when he found out that we had no direct correlation between money we spend on traffic and money we earn from our customers — he grew visibily uncomfortable. The people at his company always made sure to do that. Otherwise, what reason could you really have for spending more or less on paid traffic if it isn’t directly creating revenue? You could easily throw all your money into ads and gain nothing. This to me was clearly the most important take-away for this project effort.

In a final meeting with this specialist and all the team leads, I brought up this topic again so it might gain some traction from all the company stakeholders. I said there could be no serious way forward for paid traffic without a new product offering with this kind of transaction model. I spurred the consultant to reiterate what he’d advised and we got enough buy-in from that discussion to get everyone on board.

The consultant and I agreed it would be best to start it small and cheap to work out the kinks; then scale up whatever is working best. It wasn’t quite implemented that way but it was, when launched, a new product that began generating a new revenue stream averaging $180k-$250k per month between treatment types being run. It wouldn’t have happened without me stringing those peices together.

Product migration

I was primarily brought in to a cloud backup company to create a completely new version of the web app created for their customers. As I explored new designs and got better acquainted with the legacy web app, I realized we needed to come up with a solid migration plan to swap old for new. The potential for development time to become completely bogged down between maintaining legacy while building new was very high.

No one really had a plan but several people were really not looking forward to that kind of logjam. So I as a designer of features felt it was up to me to come up with a migration strategy that wouldn’t result in such a quagmire.

For this I needed an audit and some usage data. With some test accounts I went through the complete customer experience and noted every feature. The usage data was a difficult thing to obtain but I eventually got enough to give me an idea of what parts of the site were getting used. I then mapped out features old to new and noted their expected usage. I took all that information and verified it with people providing Customer Support.

Through my assessment I found that most of the features of the legacy site were getting very low to no usage and most features of the new site had no similar legacy feature. Most of the core logic would be the same, some of which was already contained in an API. This gave me what I needed to form a plan:

  1. Shrink the legacy web app, removing extranious features
  2. Build remaining core logic into the API
  3. Build the new web app just up to the reduced feature set of the legacy
  4. Drop the legacy entirely
  5. Build up new API and web app features

With reduced legacy code, there would be a lot less to maintain and re-build for v2. By moving remaining core logic into the API, that both makes even less work to create v2 and opens up quicker possibilities for native client apps and 3rd party clients. By dropping legacy at base functionality, everyone at the company is then free to focus completely on v2 going forward.

I started shopping the plan around and made everyone, including myself, a lot more comfortable about the migration.

Organizational transformation

My coaching work was part of an enterprise Agile transformation project, the largest ever attempted at the time for a national telecom provider and a Canadian design firm. I was brought in part way through the project and we found over the following months that even though we were getting high praise from the executives and individual contribitors; we were getting significant pushback from the many layers of middle management. I learned that can happen on projects like these but it was becoming particularly a problem for this one. I also learned that we weren’t the only consulting firm with coaches assigned to this project. They were in charge of “change management” and had been talking with people in a different way than we had. They’d been gathering opinions from people throughout the company and the quotes they shared from middle managers, I found very interesting.

I realized we as an organization had made a pretty significant mistake in introducing a new culture into both companies: We didn’t discover what the existing culture was and we didn’t map anything from existing to new. Without this, we left a lot of people seeing no value in the new culture we were training people for.

This matters because there is a lot of value people place on how they go about their work. Secrets to success, how they consider their role, what control they have, how they apply their skills, when they know to take certain actions. All of these combine to create the current culture and if you are not shown how old habit A gets better with new habit B, why would you want to drop habit A? If parts of the new culture seem to make important portions of your role irrelivant, what value can you see in working within it?

These questions needed answers. I shared this realization with my fellow coaches. Unfortunately this became known too late for this particular assignment but we resolved to put it to use in future engagements.


Originally published at www.ihoby.com on January 22, 2019.