What do we deliver?

I have been working on my portfolio recently, mostly because I read a nice portfolio rant at LondonIA (sorry, you must be a LondonIA member to read it). It basically said that in order to get a job you have to share some work in advance. After all, how are they going to trust you if we cannot see what you have done in the past? (we humans do this all the time: expectations are set based on previous experience).

Working on your portfolio has you thinking over about your professional career. It is a wortwhile exercise, but be prepared to embarrass yourself over your early work. We all learn by doing, and we all make mistakes. Focus not on what you did wrong, but on what you learnt by doing it wrong. That would be my advice.

One thing I noticed was my transition from a document-centered craftsman into an experience-centered one. When I started in the field I was very worried about the document itself (probably because I come from an engineering background where blueprints are suppossed to be an objective way of describing products), trying to document my work as exactly as I could and having it comply with my (complicated) company’s standards.

Little by little you can see I stopped creating specification documents and started going for sketches and wireframes more and more. I understood that experiences are my deliverables, and documents are just communication tools. We have to create them because we have to explain our reasoning to our clientes and co-workers, and because we have to translate our ideas to other people, and documents are a good artifact for that. But nobody makes money out of documents as such. And we have to create value. Well, at least if you want to make a living out of UX.

So, why many of us are obsessed with documents as deliverables? I was talking about it with a good ol’ colleague, and what I got out of that conversation was that people on big companies have to justify their salary, and the easiest way to do that is by creating documents. Bigger documents seem to justify bigger salaries. Meanwhile, people fighting for their lives in smaller companies and start-ups are more worried about earning their salary (i.e. making real money thanks to good user experiences) to stay alive.

My point: we are user experience designers, we deliver experiences. Do not obsess with documents, obsess with experiences (perceived by users). Documents are there to communicate, they are not our deliverables. Have them be great communication artifacts, but go with the least amount of effort that can communicate your ideas.

2 thoughts on “What do we deliver?

  1. In my experience is not the documentation that is important but the immutability it provides. If it’s not written down, every time you speak with the “UX guy”, the “Operations guy” or the “Product guy” the requirements have changed, even the overall idea has shifted.

    That happens, in my humble opinion, because we don’t make up our minds about something until we’re “forced” to write down our ideas on paper. If everybody behave more seriously in this aspect, communicating clearly what have been really thought off and what not, we all may skip the non-sense powerpointing.

    Since that seems to be a totally utopian idea, I must completely agree with you on emphasizing that the documentation is not the deliverable, it’s just a proven support for it.

    • I agree with you: documents are great for making up our minds on the details (where the devil is) about how to turn our ideas into something real; but that is what “sketches” are for: just enough details to evaluate & iterate.

      The big problem I see in the (common) situation you expose is the lack of communication and organization: stakeholders that do not understand or agree on the big picture, and who then try to micromanage to leave “their mark” on the project. Therefore, we use documents to “fight” them: “look here, you agreed to that, you told me to do this”.

      I think that it should be the designer’s job to reach agreement with stakeholders on the big picture, and then proceed to design a solution that is synced with this big picture, with little interference from stakeholders, and communicate it to the rest of the team. Probably utopic too.

      Then, this is one of the things I like about Agile: requirements that become “frozen” for the sprint, which is similar to the situation I described above.

Leave a Reply

Your email address will not be published. Required fields are marked *