A UX Design Startup Story
5 lessons learned along the way to a thriving design culture
By Steve Psomas, UX Design Manager, Workday
Workday User Experience (UX) has a fabled history. I was fortunate to be one of the early hires and witness its rise.
To start with some background, the UX Design startup culture within Workday wasn’t an accident. In early 2007, Workday had been building HR and Finance software in the cloud for two years. The Workday UI looked like any other enterprise application, a series of applications pieced together by developers. There were two events that provided the justification to build a design team.
The first event was when our leadership declared Workday to be a new breed of enterprise. We weren’t competing against other enterprise apps. In the cloud meant something greater, more current, more modern. Our solution had to compete against the best consumer apps. The second was when the same leaders observed that the combination of our applications and users is quite complex.
Workday is a configured solution; so every customer collects and displays a unique set of data for its employees. On top of that, our users are divided into back office users and self-service users. Back office users are the HR, financial, compensation, and payroll professionals who use Workday every day to accomplish their primary tasks. Self-service users are the employees and managers who might log in twice a month to perform a task. Before designers, an employee who requested time off, for example, saw something too close to what a payroll professional might see. These variables set the stage for user-centric design: learn more about our users, sort through their needs, apply sound design principles, and make it engaging.
When You’re Writing Specs, You’re Not Designing
UX for startups isn’t for the faint of heart. In early 2010, I became the third UI product manager to join Workday. This mighty group was the UX team. We filled two roles: as UI product managers (PMs) we were the advocate for delivery of features, and as designers or researchers we were the advocate for users. These two interests often conflicted. And not surprisingly, delivering a feature tended to win out.
We were prolific writers of Functional Design Documents (FDD). These documents covered topics such as the justification for the feature, its flow, its new UI widgets and their micro interactions and states, as well as accessibility, keyboard support, and security. We documented everything, including the scrutiny received in stakeholder review meetings. While we also delivered an annotated wireframe, it felt like documentation was our sole role.
A couple of years later, designers became pure designers; as we grew, we no longer needed to double as PMs. This change was an important statement about the value of good design at Workday. We stopped providing a written account of a feature’s finer details. In so doing, we lost a little insight into technical feasibility. On the other hand, our small but growing design team adapted to storytelling and walkthrough. And as pure designers, we allowed ourselves to question the way common UI components work. That’s when we really started to innovate.
Design Small Enhancements, Then Sell-Sell-Sell
By the end of 2010, the design team was two interaction designers and a design researcher. We would use visual design talent from Marketing when needed. That wasn’t very often because our aim was to reuse components already designed and developed. Back then, we didn’t have our Workday Canvas Design System to refer to, and there were more than a few holes in our component library. If you needed a grid, also known as a table, we had View Grid and Edit Grid. And each component worked one way, every time.
Within the Workday framework, a tiny enhancement could, and still does, have a ripple effect across the system. We could achieve great improvements by exploiting existing components for reuse. Our work was better received when we distilled it down to one or two small, net-new enhancements. But we had to bring that vision to stakeholders. We had to know what PMs were dreaming up and what kept them awake at night. Then we had to sell our vision.
Selling our vision was a big part of the gig. In a former life, I had a three-year sales career that came in handy. That meant rejection wasn’t as damaging to my psyche, but it still wasn’t easy to pitch my own ideas. We learned to think of it as sharing our design vision with development and product management. Point is, it’s easier to sell a vision that’s been chopped up into viable pieces.
Take on the Issues You’re Ready To Solve
Until 2013, Workday delivered four updates a year. The development organization designed, researched, developed, and tested at a pace I had never experienced before in my several years as a designer and developer. The sheer pace of delivery pulled us into a loop of diminishing certainty — the time it took to prototype a design was equal to the time it took to develop it due to the development tools. So as development was finishing a feature, we ran it through usability testing, giving designers a small amount of time to tweak in response. We got qualified usability results, but it was frenetic.
We learned to deliver the best UX design we could, and move on. It was healthy for our team to realize that not every problem could be solved right then. Working through issues like timing, process, and when to engage made the design culture what it is today. When any member of the design team recognizes an operational issue, they are encouraged to take it on.
Design for the User, Not the System
Around 2013, something happened that caused a shift in thinking. During usability tests, we would hear participants say, “Yeah, it works, but I would never do it this way in real life.” We kept hearing this, and we began researching the response. It took quite a bit of excavation to get at the root of the problem: Our data structure was unfriendly to a user’s mental model. The strength of an object-oriented data model is that you can get to anywhere from anywhere else. But in real life, navigating data that way is unnatural.
Take, for instance, finding a colleague’s manager. Easy enough to navigate, right? Just look up your colleague, A, and their manager, B, appears on their profile. But behind the scenes, traversing to that manager is a lot more involved. It goes something like this: Your colleague, A, fills a position, C, which is in an organization, D, which is managed by a position, E, filled by manager, B. For that very task of looking up a colleague’s manager, and several other tasks, we had been exposing every one of the objects to our users. Knowing this was confusing users, we began overlaying a contrived structure. For example, we installed an admin menu, a simple list of tasks that were otherwise found by searching.
The shocking realization was that, as designers, we hadn’t been fixing up a UI. We had been inventing one. Out of the raw data display and intricate tasks, we were shaping a new UI. In any other organization, this would have opened the gates to anything goes. Instead, we held fast to placing the user at the center of our design, creating an experience aligned with our UX design principles: simple, fast, and clever.
Make Design a Craft
As the team grew into this new posture of creating from scratch, demands on the team grew exponentially. It was as if all our PMs were clamoring for us to create a feature concept to present to their stakeholders at the same time. Multiple factors contributed to this phenomenon:
- Our track record of delivering great designs
- The commitment to great design by our leaders
- The sheer pace of development
- The growing number of UI components
- The growing number of PMs
- The need for a PM to pitch a strong concept
At times, features were held up because UX couldn’t deliver on early concepts. And early concepts were exactly where UX wanted to be. Something had to change. It was imperative that we reset the perception of design as a craft instead of decor. We needed to embrace the idea that “Not everyone can become a great artist, but a great artist can come from anywhere” — Ratatouille (2007). In a way, this was how we reallocated our design resources.
Designers worked on two kinds of projects, 1) new concepts or new enhancements to an existing feature, and 2) projects pieced together using existing components. We knew that the value of any design team was its capacity for creativity on new concepts, so we dropped the second kind of project. In other words, if something required a new concept or enhancement, designers got involved. But if a PM could piece together existing components, then they could design it themselves. The system worked well. We learned that focusing on creating new designs delivered more value to our users.
Stay True to the Startup Mentality
Fast forward to the present, when design teams are engaged throughout Workday. Some of these problems still exist today. For example, tiny enhancements still ripple across the system, catching us unaware. We still end up archiving concept work. We still struggle to get ahead of the pace of development within our teams. But these are blips in the volume of work we produce. Designers and researchers can sense their impact on every person who uses Workday. We pitch solutions to design problems with a vision of our own. Design teams here collaborate on operational problems. We invent and represent design as a craft.
In the last year, we’ve launched efforts to mature the organization by establishing a Center of Excellence, sponsoring design education, growing new skill sets, promoting deeper research, bringing content strategy in early, investing in design operations, and more. Look out for further posts that elaborate on these efforts and how they turn out for us.
To this day, the UX design startup culture still prevails at Workday. This startup mentality provides even a large company like Workday with a spirit of entrepreneurship and innovation that’s necessary for design and research to thrive. I encourage you to adopt that spirit into your own design culture. Take what we learned early on, own the solutions to your team’s problems, and make design a craft.
