A Back-and-Forth with Jared Spool, Founder of UIE

In late November, I gave my advice on the question, "What are the things which a Front End Developers must know?" where I praised Jared Spool and criticized User Interface Engineering (the institution). Jared cordially responded and asked if I had any feedback, and I (somewhat hastily) fired back with three suggestions:
  1. Cite your sources.
  2. Talk about innovative technologies, not antiquated ones.
  3. Update the UIE website, for the sake of credibility.
The full message is included at the bottom, after Jared's response. His answers are really good, and from what I could tell, not documented anywhere else. Jared was kind enough to allow me to post this here on my blog. Hopefully, other people find it enlightening.

On Nov. 29, 2011, Jared replies:

Hi Jonathan, Thanks for answering my question. I didn't think it was harsh at all. In fact, I agree with all of it. It's all places where we could improve. To speak to your points directly: Citing our sources: This is a constant tension around here. We try to do it as often as we can, and we probably could do it a bit more. However, there are reasons you don't see it as often as you'd probably like: 1) People talk to us because we *don't* get specific in our sources. In many cases, we couldn't talk about what we've learned in any more specificity without running into a huge set of NDA and IP battles. 2) We've learned that when we describe our research methods in more detail, people focus on that detail more than they focus on the findings. We don't want people focusing on our research — we want them to take what we talk about and go investigate their *own* users using their *own* designs. Our goal is to start a dialog and create a vocabulary around design. We don't claim to dictate good design practice; we're just trying to get people talking about it. 3) A lot of our research is work-in-progress. We're still collecting data and feeding it into our analyses. We are often reporting mid-analyses results to see what people resonate with and to find out what questions come up, so we can adjust our course. Talking about the specifics of how we've gotten there just complicates that conversation. All of this drives us to be more general in our descriptions, do a lot of handwaving, and not cite the specifics as often as we probably should. That said, if you ever have a question on how we've gotten to a conclusion or what the research is, please ask. I try to answer as much as I can when this comes up. Up-to-Date techniques and innovations: I hear you. Frankly, we're not at the leading edge of this stuff and we're up front about that. We see ourselves as more historians than of reviewers. We choose technologies and techniques that have a proven track record before we talk about them. I get that you're at the forefront of this stuff, ahead of where we're at. Fortunately for us, our audience (which is mainly composed of insurance companies, hospitals, financial services firms, universities, and government) thinks things like Modernizr is leading edge stuff. Hell, they think using javascript is a new advance (the feds JUST got permission to use it in their public-facing web apps from the White House). Part of our problem is we need people who can write and speak effectively to these technologies for our audience. A lot of the folks who are at the bleeding edge are smart, but not very good at communicating effectively. We vet our folks pretty well to meet our audience's needs and I'm always scouting. Things like OpenGL and Sass are very much on our radar. We're waiting to see them get a bit more traction, have some great enterprise-level examples to show, and find the right people to talk about them. It'll probably be a little while and I'm guessing it won't be soon enough for what you're looking for. Cleaning up the UIE website: Man, I can't tell you how much our web site is the bane of my existence. (Almost interesting fact: most of the core of UIE.com was written by Josh Porter 10+ years ago, when he worked here.) I talk about this with the staff frequently and I'm sure they are tired of hearing about me whining. We've done better with our temporary sites recently. (Our most recent event site for the User Interface Conference was designed by Dave Shea and I think was worlds above where we're at in other places.) We run the company very lean. Most of the "profits" we make are rolled back into our research, because that's where we think we get the most leverage on our investment. Because of that, we don't have a ton of resources to put on our web site and everything takes a long time. None of us are designers or developers, so we have to do everything through contractors, which takes even longer. That said, we've hired Dan Rubin to redesign our virtual seminar program site, which we're gutting and rebuilding from the ground up. We are expecting that will then bleed into the other portions of the site where our blog, articles, and podcasts live. That's expected to launch early Q2 of 2012. We're also hiring a web developer intern to help keep things maintained without using contractors. (If you know someone, we'll be posting the ad in a few days. I think it's a great opportunity for someone wanting to build up some experience and get paid to learn.) Sorry if that's a long answer to your response. Again, I appreciate hearing your thoughts on this and wanted to let you know where I was. It's definitely things we think we can do better. Jared

My original message to Jared, dated Nov. 28, 2011:

What UIE could do better: You asked, so I'm going to answer :] 1. Cite your sources. I'm a front-end engineer, but I have a degree in Journalism, of all things. One of the things that is so painfully apparent in a high percentage of the articles on UIE is that you don't cite specific research or exact people. It leads me to believe you're either reanalyzing the same data set year-over-year or making it up completely. 2. If you're going to write about new techniques or technical innovation, find highly technical people. I've seen a bunch of articles on how awesome Modernizr is, which is cool, but it came out in 2009. Talk about OpenGL, Dart, Coffeescript, Sass and LESS. Those are things interface engineers should be using today. 3. Clean up the UIE website. It's hard for me to take the concept seriously when you're not eating your own dogfood. I admit that the website is very "traversable," but it's a pretty terrible reading environment. I apologize if this seems a bit harsh, but I think it's somewhat deserved. UIE is capable of gaining a position of authority in an industry that is currently very fragmented and unfocused. By making UIE better, you'll hopefully make the web a better place.