The first designer
As the first design hire at an engineering-heavy company I had to work to integrate design into the fabric of all things. This position offered up a set of challenges to me: some familiar and some brand new.
This retrospective captures some of those challenges, how I overcame them, and what I learned in the process.
My colleagues at AMS were incredibly intelligent and hardworking. This retrospective is not a critique on anyone there, it is rather my effort to objectively reflect, and learn and grow as a designer.
Challenge 1: What is UX design and what are you doing here?
The company was transitioning from battery installation and management to a SAAS model built around energy trading.
The VP of engineering advocated for hiring a UX designer. However, in a company of about 80 people: 2/3 worked in battery management and of the 1/3 in the software group, many of them were analysts and data scientists, or very new engineers and product managers that were also unfamiliar with UX.
I scheduled time to get together with each team lead to introduce myself and chat about design and learn what they do. I also put together a company-wide info session on the topic.
Why was it important for people to understand what I do?
1.
Teach people how to work with me
As a designer, I have no inherent knowledge about how how people trade energy or what goes into maintaining a massive battery.
I'm reliant on learning from my coworkers, and they need to know how to include me. If everyone keeps referring to me as the graphic designer and thinks that's all I do, then of course I'll never be included in a meeting on how we can improve XYZ because why would I need that knowledge?
2.
Lay the groundwork for hiring
UX does more than just pick a color at the end. We had a lot of design work to be done, and I needed to start hiring other designers to assist with the backlog.
By explaining all that I, and my team does, I can begin to make the hiring case.
3.
Heal the growing rift
There was a growing rift between the two halves of the company. The battery side saw all the attention the software team was getting, and felt in the dark. The software they used was deprioritized and there were frustrations.
I wanted to communicate that I was there for everyone and that design thinking could be a tool outside of myself.
Mixed results
Lots of interest & excitement...
The battery teams were really interested to learn about what I do, and asked a lot of great questions.
It was an energetic and engaging session that broke down barriers between myself and the non-software teams.
...but not the right audience
Unfortunately the people that I needed to hear my message most were the people that had already decided that design wasn't important. They didn't stay for the learning session.
I should have pushed harder to have a targeted session with a more focused message.
Challenge 2: Not everyone at the company was happy to have me - I was taking their 'job'
When I joined the company already had 5 products (see a snapshot in my assessment on the Sigma One project) that had been planned, researched, designed, and built by the commercialization, product, and engineering teams.
These people already had processes in place for working together, relationships built, and I needed to both do my job of bringing my expertise to those areas where appropriate, while also not offending the team or dismissing the work that had already been done.
The team was rightfully proud of what they had already created, but as a professional designer it wasn't up to the standard of something we could offer as a business.
"This is what I'm good at, let me learn about how I can best support you in it"
An open mindset, and a collaborative approach drive my interactions at the workplace.
I had many 1:1 and learning sessions early on to learn about how different aspects of the product process were handled at the company. My approach was to first listen and learn, make a recommendation for something I could work with them on to make better, and build trust that I can take on more work going forward.
Customer journey map: Trading Platform
In an attempt to formalize and refine our process for new clients (and new functionality) getting added into our system, I worked with Product and the Customer Success team to visualize our process, and identify which teams need to be involved at what stage, as well as socialize this with the appropriate teams.
This was meant to address confusion and issues that our clients were having, as well as the confusion and internal issues for how we work with each other.
Mixed results
Product and front-end engineers are allies...
The front end engineers were thrilled to have real process and designs to work off of.
Product owners were happy to offload ideation and concepting, and to have a partner in strategizing how to grow the product and make it better.
...but there is resentment in other areas of engineering and in commercialization
There were factions of the company that I continued to struggle with throughout my entire time at AMS. Particularly when it came to engaging with users and taking on larger technical aspects of the product.
The commercialization team in particular was very busy, and saw no reason to change their methods or engage with me.
I needed stronger allies higher in the organization to help break these barriers. The VP of engineering that advocated for my hiring in the first place left the company shortly after I joined.
Challenge 3: Conducting research as a team of one
Any product needs to be based on a solid understanding of it's user's needs, but especially a product as complex as what we were building.
1.
New features were based on sales-pushes
The commercialization team owned the contracts with our clients, and therefor the communication channels.
New features were often a result of which sales person was the most vocal about what their clients asked for.
2.
Sales-pushes weren't grounded in viable research
Those same sales calls that generated features were not based in any real research methodology. Each person had their own process, and the feedback that each call generated was difficult to aggregate because it was all different from client to client.
3.
The roadmap was all over the place
Because each sales person was promising whatever necessary to make the sale, and then pushing it on the product team - our roadmap was unstructured, constantly being reprioritized based on the new lead, with dubious claims of importance.
Solution 1: Share what user research is, and ask to do it
"We don't want to look like we aren't the expert, and they don't care about what it looks like. They will never agree to do that"
Solution 2: Refine my message, advocate with CPO, and create a framework that would enable the commercialization team to still maintain ownership, but in a more beneficial way
A script that gathers good data and sets the stage for later UX
Oftentimes on a sales call the conversation would drift to design. Rather than pause the call so that the right people can join, I aimed to put together a basic script that would enable the caller to collect a solid foundation of information.
Across calls this would enable us to have consistent data, as well as set the stage for how the client could be engaged with for a future UX discovery session if appropriate.
A simple UX research pitch to propose to clients
If I couldn't be on a call with the client, I needed to provide the caller with a simple, clear, and consistent way to talk about what a UX research session looks like and why it's valuable.
I created a number of these targeted to different types of clients and research needs.
Facilitator guides to for consistent research
If I needed assistance conducting research, like for instance this observation session for the CAISO product, I would create a facilitator guide to make sure that who ever was with me, whether a product owner, engineer, or member of the commercialization team, we were able to ask the right questions, capture the right things, and have a consistent set of results to compare afterwards.
Overall positive results
Slow to start...
I felt a bit like a broken record at times, and generated a large amount of research proposals and decks that went unused.
However, I believe that that initial work was important to show that:
-
I really did believe that this was important and was going to continue pushing for it
-
That I was actually more flexible and accommodating with my various research requests than the group originally took me for, and that it was possible to find agendas and solutions that worked
...but we got there eventually
I did ultimately get to travel to Australia to conduct user research with 3 clients, and I was able to manage the client relationship with our California-based partner PG&E.