UX case study

 


Recently, I decided to work on a UX design side project. This required working with a technical lead in San Francisco as well as separate stakeholders in various areas of the US, while I was living in Auckland New Zealand.
 

Why did I decide to work on this side project:

  1.  To challenge myself by exploring a topic that was completely foreign to me.
  2.  To test my ability to empathise for a user when I had no context or understanding of what that user is trying to achieve.
  3.  To innovate and create a desirable product by using human-centered methodologies.
    The side project is an online calculator for building developers, policy makers and housing advocates. It’s purpose is to enable these users to calculate affordable housing in a particular area. They would use the calculations as artifactual evidence that could help build a case.

Outcomes:

As a solution, I did the following:

  1.  Applied an new UX strategy to the overall experience.
  2.  Established who the target audience by creating user persona’s.
  3. Created a clear pathway for these particular user persona’s.
  4. Re-designed an hi-fidelity mock up. This included thinking of what was technically feasible (based on the scope provided) and what was viable for business. As well as, what was human desirable.

For the online calculator, the redesign and new strategy would equal an increase in usability satisfaction, which lead to new user engagement and higher retention. The increase in usability satisfaction is evidential and can be a direct correlation to the work that I help conduct. 
I gathered metrics of the previous calculator (pre-redesign) and metrics of the new outcome (post re-design). This was done by using the System Usability Scale (SUS) — a “quick and dirty” reliable survey for measuring usability. 

SUS Scoring from pre redesign (67) to post redesign (88).

SUS Scoring from pre redesign (67) to post redesign (88).

Process

I will now talk about my involvement in this project and my key takeaways.

1. Where’s the data?
How do we know this to be true? | Benchmarking | Requirements.

When I decided to embark on this challenge, I knew that I was going to using my empathy hat a lot. I learned very quickly, that there was virtually no data or knowledge about the audience that was using this calculator. The calculator had been in beta for many months and, unfortunately, the developers who created the first beta version, didn’t quite love data about users as much as I did.

The original team would tell me “we want this” or “I know a solution perfect for our users”. I started to push back on this thinking as it was focusing on solutions. I asked: “How do you know this to be true”.There was no tangible evidence and only anecdotal facts based of the interactions the team had with the “super user”. I didn’t want this to bias my opinion of all of users.

There was no tangible evidence and only anecdotal facts based of the interactions the team had with the “super user”. I didn’t want this to bias my opinion of all of users. I’ll admit, there was a lot of back and forth at this stage. But that was okay! It just meant that I had to hack ways to find knowledge about the end user and empathising with them.

I did this the following ways:

  1. Survey’s: First I started off by conducting a SUS survey to understand usability satisfaction.
  2. Heat Mapping: I used Hotjar to observe what was going right wrong. On a side note: this exercise was extremely useful. When I later needed to write a user interview script, I was able to clearly write the script and probe on specific areas on the user’s actions.
  3. Benchmark analysis: They say imitation is the sincerest form of flattery. I feel like this is especially true for then it comes to product strategy. To understand more about what products were doing well in terms of on boarding, user flow and good architecture, doing your research is great. I read user reviews on similar products and started a spreadsheet of what was working well in comparison to one another. I essentially benchmarked my way to the next step.

Which was starting to write requirements. Writing requirements is a delicate balance between campaigning for what’s best for the users as well as understanding what’s technically feasible in the scope provided. Now that I had a bit of data, I was able to get specific.


2. Users. Who the heck are they?
Interviews | The 5 Why’s| User stories | Persona’s workshop.

I could investigate all of the quantitative data I wanted, but none of that was going to tell me why these users want the things they want or do the things they do. The best way to answer these questions was to set up interviews with real users.

At the time I was interviewing, I realised I wasn’t really getting into the depth of why users liked or disliked the calculator. I was getting a clear picture on what wasn’t working, but not why. I changed my interview strategy slightly and applied the “5 why’s” methodology. This methodology is an iterative interrogation technique to explore cause and effect of an underlying problem. Even though I didn’t want to feel like the participants were being interrogated, this technique was extremely useful for curating the final user stories.

I used the Jobs To Be Done Framework to create multiple user stories based on my interviews. My focus was primarily on situation, motivation and outcome. To help solidify these motivations, I decided that compartmentalising these users into different categories was going to the best next step. In an effort in trying to not silo my empathy levels, I realised that the team need to digest the user goals as effectively as I did. This is why I decided to conduct a user Persona’s workshop.

Outcomes from the personas workshop

Outcomes from the personas workshop

There were two key outcomes came from this workshop:

  1.  The team members that were not naturally in tune with having empathy with users became very aware of what the users problems could be.
  2.  We were all speaking the same language. We became a team aligned rather than a team fragmented. This was especially useful since we were working remotely.

After this exercise, the fog really began to clear. After the persona’s workshop it was easier to think about how to create a robust UX strategy moving forward together as a team.


3. The users journey, what makes most sense for them?
IA | User flows.

Now that we had a solid understanding of the users motivations and we could see where the problems were, strategizing the flow felt like the next logical step. I was interested how this was going to work from a 10,000 ft view but to understand that, we needed to architectect the details first. This enabled us to understand the optimised users flow.

IA is like a dance routine. It’s about the calculated, choreography we want to user to take. It’s about considering the structure it creates to foster specific moments and interactions. It Anticipates the movement in the way users want to flow. I’ve come to realise that good IA should define the patterns that govern the meaning of what we intent to communicate.

Hierarchy, taxonomy and navigation were still problems that needed to be solved. I decided that doing a card sorting sessions as shared team would help me define this. The final outcome looks a little scary (see below) but it all made sense. We even sense checked this with a few were carefully picked participants that aligned to our established persona’s.

Outcomes from the card sorting workshop.

Outcomes from the card sorting workshop.


4. Negotiation time.
Tech reviews| business requirements | managing expectations.

It was Andy Warhol who said:
“In a way, every social action is a negotiation, a compromise between ‘his,’ ‘her’ or ‘their’ wish and yours.”

When it comes to creating digital products, there is going to be negotiation. We cannot build everything and we have to accept that the product is going to be flawed. As a UX’er, I’m always going to side on what’s best for the end users. This means, that sometimes, there is going to be negotiations between technical leads and business stakeholders to form a compromise on what we think is best.

A tangible key learning that I could take away from this whole experience is that rapid, iterative prototyping is the most effective way to solicit feedback from all parties involved on a project. Whether it be the business stakeholders, the technical leads or the users themselves, I learned that communication was going to be most efficient when there was a prototype among the conversation.

Listening to users first and foremost also helps negotiation. Once I set up unmoderated user testing on a testable prototype, this was a fantastic way to establish our steps forward as a team. We were able to understand what had to be out of scope based on what the users were telling us what they wanted.


5. Scalability and longevity
Creating a design system| Hi-fi outcomes

Now I have written the agreed upon requirements and my brain is of full knowledge of who i’m designing for. This means that the next transition was building an the hi-fidelity outcome, which we tested with remote unmoderated testers from Usertesting.com.

Designing an outcome isn’t just thinking about how the user is going to interact with it, it’s about designing for scalability and longevity. Consistent components and language is not only a better user experience but it’s better for team alignment. Building a design system is more than just UI styles guides, it’s the way the team works. I struggle with the notion of building something that isn’t scaleable. What’s the point? In my opinion, building a scalable product requires a robust design system, which is why I started to build the design system alongside this project.


The return on UX investment

Investing in the future requires thinking about the future now. The true return on UX investment is not to just learn about your users but to understand how you can help them in the future.

There were two ways in which I was determined to educate my team mates on why embedding a UX strategy was a smart investment: 
 1. Building a scalable design system. This lays good foundations so future thinking is less about retrospectively rebuilding components and more about innovating a scaleable product.
 2. Baking in analytics with development. Throughout this project, I kept on wishing we had more data. My gut told that we needed to embed an analytics tool into development early. This would ensure that getting metrics on user activity would be accessed moving forwards. In this case, we decided to go with Inspectlet.