John has worked as Design Lead for Ancestry.com for the past 3 years. In that time, the Ancestry.com team has tripled in size, now numbering about 15 people spread between two states, Utah and California. John works mostly from his home in Ogden, Utah and finds he’s very productive without the distractions of an office.
John has a long and sparkling list of client work, reaching as far back as Iomega and their Zip Disk products. John was conducting user research and designing world-class user interfaces before I knew UX was a thing.
John graciously took a couple hours to meet with me to discuss his work.
High-def Prototypes Are a Must
A static mockup can’t explain what is going to happen when you click this thing or tap that thing. But a high-def (HD) prototype is built in the actual technology that will run a web application—HTML, CSS, and JS! It looks and acts like the real thing.
Some argue that designers don’t need to know how to code. John’s response to this argument is, “It doesn’t hurt. And it helps a lot.”
I agree. The more we know how the web works, the better we can design for it. A painter knows paint. A sculptor knows clay or marble. Musicians understand acoustics, feedback, mics, guitars, pianos, etc. There’s a technical aspect to every medium. The better a designer understands the technical aspects of their craft, the better their designs.
Set Up a Good Pattern Library and Hold Designers to It
Another cog in the gears of John’s success is pattern libraries. When John started with Ancestry.com they had just a few page templates to guide their design work. While this is better than nothing, John found it to be very limiting. It left designers unable to answer the question of how things should look when a new situation arose.
The Ancestry.com team is working to remedy this situation. The design team is working to develop and implement a flexible component library that helps speed up the design process and improve consistency site-wide. They strictly follow design patterns laid out in a central library. These patterns are built around components instead of page templates. The components are designed to work in every situation they could be used. If a designer presents work that alters a defined pattern, they are required to change their design or to submit changes to the pattern library. If they submit changes to the pattern, they must be viable everywhere that component is used. Through this rigor, Ancestry.com is able to maintain a high level of clarity and consistency.
Speak the Language of Business
John starts every new effort by carefully defining the objectives for the project with the stakeholders. What are the goals? Why are we doing this? How will it benefit us or our customers? John aligns the design and discovery activities with these clearly defined objectives.
These objectives are different from business requirements. Requirements define what must be done. The goals define why we’re spending our time and money meeting the requirements. They provide meaning. John works to get clear goals and then consistently ties the design work back to those goals. This is the language of business and John is fluent.
Hire Well
I’m going to depart from John’s direct responses for a moment. There was one particular question I wanted to ask John. I asked John about my hiring philosophy. I trust his experience and wanted his honest opinion. In brief, here is my hiring philosophy and John’s response.
I have only two requirements for hiring.
1) Can they learn what they need to know to do the job?
Working in the user experience and technology field means lifelong learning. You have to be curious. You have to aggressively digest new technologies and practices. You enter this field with your eyes and mind open. Those who think they know it all have already lost the war.
2) Do I want to spend a lot of time with this person?
Whoever you hire, you’re going to spend a lot of time with them. For example, I have two interns right now. They shadow me daily for the express purpose of learning to do what I do. Some days, I spend more time with these people than I do with my own children. Whoever I hire, they need to be someone I can get along with.
Mostly this boils down to not hiring divas. If I have to choose between hiring a talented diva or a team player with less experience, I’ll choose the team player every time. I can teach User Experience tools and processes. Arrogance is a road block I don’t want to deal with and avoid at all costs when hiring.
John agreed with this philosophy. In his experience and research, hiring well is key to any team’s success.
John not only agrees with this philosophy, he lives it. John had this to say about his success:
“Design is never a one man show. Team is everything - tight collaboration with designers, programmers, and product managers is what makes success happen. Without being surrounded by great people who are way more talented than me, I'm nothing.”
Well said John. And well done.
“Act Well Thy Part”, poster by John Dilworth
Thanks John!
My two hours with John flew by. He is bright, articulate, and captivating. It was great to share stories and insights with one of my longtime UX heroes.