Diverging Requirements

As the lead designer, I led the project and did all the design work. For the research I worked with a researcher in planning, execution and socializing learnings. 

I got regular design feedback from my fellow designers, including Design Ops and Design Leadership. Development also had a lot of input. Finally I worked with the Documentation team to add important information about the Recorder to the online help. 

I was the lead designer on a web application that enabled users to record actions they took on their Windows PCs and play them over and over again, thereby automating business processes.

Business Context

Knowing what the software actually does is necessary when designing the interface, because one of the principles of good user experience is that the user should know the state of the system. Once I knew what the system did, I could boil down the system status to only show what the user cares about. 

You can compare this to a car dashboard. The instruments don't tell the driver the position of each piston in the engine, because that knowledge doesn't help the driver make decisions. Instead the instruments show the current speed and how much gas is left in the tank. That data helps the driver decide whether to speed up or down, when to break and when to start looking for a gas station. 

Based on my many years of experience in the UX field and conversations with stakeholders, I can usually come up with a plausible strawman for what constitutes the speedometer and fuel gauge of a given piece of software. Research will then help refine it. 

After workshop: Recorder workflow for retrieving an object in a browser window

Before workshop: My impression of the Recorder workflow for retrieving an object on the user's screen 

My design efforts were hampered by getting different answers to the same question from different people in Development and Product. So I set up a workshop to document the current functionality of the Recorder. 

I was super happy that the workshop was very well attended, including by key developers. After the workshop I was able to repay the Recorder developers by sharing the documentation I produced with them. It's important to me to respect the time of my cross-functional partners. 

Search Algorithm

Returning to the Recorder, the user wants to end up in the top right square that says 'Perform action on found object.' The algorithm tries up to four different strategies, roughly in descending order of success probability. 

The user has the greatest chance of success by using DOM XPath to find the object.  Unfortunately our most numerous and important persona, the Citizen Developer, is going to struggle with even knowing how to pronounce DOM XPath. If we want them to use this method, they're going to need a lot of hand holding. I can definitely design and write an interface that does this. 

The other persona, the Professional Developer, knows what both DOM and XPath are. They also know (or can easily find out)  that they can turn to third-party tools to find the DOM XPath of an object on a web page. 

The second strategy is either Path or Coordinates, depending on the browser that's used. Path is a proprietary numerical expression for finding the object in the DOM, so it's even more obscure than DOM XPath. On the face of it, Coordinates seems like a more Citizen-Developer-friendly strategy, but it hardly ever works because of minute changes to window size, zoom level and similar. The final strategy requires a lot of computing resources, but it does often work if the matching algorithm doesn't time out.  

DOM stands for Document Object Model, a way of representing objects in a web page as a hierarchical tree structure. 

XPath is a way of expressing a path through this tree structure to the object we're looking for.

Before: Object search criteria appear to be in random order

Rather than build one interface that didn't work for either group, I proposed two interfaces with the ability to toggle between them. 

Given that the production version had been designed without the aid of research, we discovered a lot of fundamental issues. To ensure we were heading in the right direction, my researcher and I performed Rapid Iterative Testing & Evaluation with both professional and citizen developers. 

Unfortunately it soon became apparent that the two personas had diametrically opposed requirements. 

A free version of the existing product is available for anyone with an internet connection, so we tested on that first. The research was remote and unfacilitated with stimuli presented through UserTesting.com

We recruited for two different personas:

* Professional Developers, typically with a Computer Science or adjacent background

* Citizen Developers, without Computer Science background 

After: Mockup of full-screen modal for Citizen Developers

After: Chunking of full-screen modal for Citizen Developers

For Citizen Developers I proposed a full-screen modal, for a distraction-free experience. It would include a large preview pane with relevant markup. DOM XPath, the most succesful strategy, would also be prominently featured. 

After: Mockup of action panel for Professional Developers

For Professional Developers I proposed a highly sanitized version of the current experience. 

I was planning a card sorting exercise to arrive at a mental model of search criteria that makes sense to professionals. I was also working with Design Ops to create a visual design that supports new developers in learning a succesful mental model. 

1. Text only

I included this version in the user testing only because it would require minimal Development effort. We'd simply add a line to the details boxes at the bottom of the page with a cost estimate. 

4. Interactive slider

There's even less information in this version, but I think that if we can get users to engage with it, the impact will be much stronger. 

3. Static bar graph

There's less information in the bar graph, because it assumes that you've invested $10,000. But the visual impact is greater than with a table. 

2. Table

A new section on the page, with a table showing how the cost grows over time and with higher amounts. 

1. Text only

I included this version in the user testing only because it would require minimal Development effort. We'd simply add a line to the details boxes at the bottom of the page with a cost estimate. 

4. Interactive slider

There's even less information in this version, but I think that if we can get users to engage with it, the impact will be much stronger. 

3. Static bar graph

There's less information in the bar graph, because it assumes that you've invested $10,000. But the visual impact is greater than with a table. 

2. Table

A new section on the page, with a table showing how the cost grows over time and with higher amounts.