UX team of one

UX role tension

UX role tension

Over the last three months I’ve been working on a very exciting (and challenging) project as the sole UX person. The start-up product we’re designing targets a niche market sector. Our product team is made up of a representative from marketing, operations, development (3), management (and the product owner) and user experience design (me). And while our full time developers meticulously sew the pieces together I find myself running around fulfilling various other non-factored roles as well as assisting our team’s roles too. Don’t get me wrong it’s pretty exciting and fun with huge rewards, but there are times when I feel I’m straying off the UX track and neglecting my core responsibility. I’ve noticed this especially when I stumble on elements of the design I’ve not been party to. And, it’s no one to blame, we all have tight deadlines and need to get on with our tasks, certainly during this phase of rapid development.

Whilst most functions are covered by our team roles my UX role is spread too thin. I’m being pulled in many different directions and in equal strengths of importance. Prioritising is extremely difficult. For those who have worked in a fast-paced start-up environment know it’s chaotic, but we do our best, and just get on with it… the product needs to get to the market, right? Everything seems to be important and everything needs to be done now (yesterday actually).

So in the last three months I’ve learn’t a few things, which I think is worth sharing:

1. Don’t focus too much on UX documentation – just communicate intention as quickly as possible, that may mean a lot of sketching,
2. Don’t get too pixel precious during the early stages, there are bound to will be changes after the testing is done,
3. Test early, even if you test it within the team – paper prototypes work well,
4. Budget wisely – if you manage a budget don’t use it up too soon. Keep enough for post beta release updates,
5. Work closely with development and business teams, keep the conversation flowing, and finally,
6. Use role blurring to learn how business and developer folk think and ask tons of questions.


Expert reviewing a heuristic evaluation

I recently changed jobs and now work as a User Experience Consultant at Interaction Design Studio. Since starting I’ve been doing a lot of work conducting heuristic evaluations (HE).

Screen shot: Expert Review

Just to recap, a HE is an inspection method or review conducted by a usability expert, of a website which complies to widely accepted (and even adopted) design principles. These design principles (called heuristics) are what is considered standard practice or rather best practice. For example, when submitting form data the system should inform the visitor that ‘something’ is happening – processing, validating, checking, submitting – something that keeps the visitor informed. An ‘official’ widely used set of heuristics are Jakob Nielsen‘s ‘Ten Usability Heuristics‘.

A practitioner involved in the field of user experience conducting HEs is an essential skill and dare say one that should be mastered. Having the ability to pick apart a website and analyse its strengths and weaknesses has many benefits, notwithstanding cost-benefits and speed to conduct. Often the findings provide insights which allow website owners to fix the quick and easy issues, the low hanging fruit fixes. In most instances conducting a HE serves to highlight potential flaws and usability failings, but also suggest or recommend ways to fix or correct the issues.

I’ve been reviewing and reading HEs conducted by other practitioners. I find it kind of interesting to read their assessments. Often they spot issues which I may have missed, or articulate the problems differently. Reviewing HEs is also a good way off checking work too, making sure there are no errors, and of course it acts as a second pair of eyes strengthening the assessment process.

But, are we writing these reviews with the end-user in mind? Are we using technical terms with explanations? Quite often the reviews I write are written for business managers, website owners and marketers, and not user experience or usability professionals. So should we place more emphasis (on our writing) on our clients? Perhaps we should be writing both a technical and a normalised version? Or should we be documenting our findings providing explanations for technical terms which seem impossible to omit?

My view is that prior to writing a HE be clear about who its recipient is. All HEs or expert reviews should be written in normalised language and where unavoidable provide explanations for technical terms.

What do you think?

Mobile device switching, for improved productivity

Use Flow: User to submit press release from mobile device

Many of us working in the corporate world operate two mobile devices. In many instances the reason is primarily because the company has a corporate deal which involves an email exchange server and an associated Blackberry device policy. At the same time people have an additional smart phone for private use, like an iPhone. I know I do.

It’s widely accepted that certain functions work on some mobile phones but not on others and that operating those functions, like text documents, on different devices culminates in a better user experience. For example, trying to create and edit a document using an iPhone is seemingly easier than say the Blackberry (that does not include the manual operators, it’s the applications functioning).

During a recent usability test (testing a news wire iPhone app) I discovered that the participant did exactly as I do. When I asked how they would edit and send a document (press release) from their device they said they’d email the document from their work mobile device (the Blackberry) to their private mobile device (the iPhone) first, then edit the document on their iPhone before sending.

What contextualised findings have I learnt from the empirical usability test? Well, other than the specific functional insights originally set out, a) the only way to access work files is through the work device and therefore only good for emailing out* and b) workers are very good at finding alternative ways, albeit unconventional or perhaps inefficient, to complete tasks.

* phoning too of course

Agile UX

Matt Roadnight discussing Agile methodology (user story map slide)

I attended Agile UX SIG #2 last night at the ThoughtWorks where agile geeks met to discuss the much hyped Agile methodology. While I’m curious about all the fuss I’m also professionally interested to learn how Agile might improve workflow. Further, next year (User Interaction Design MSc) I’m enrolled in a ‘Agile Methodology’ module at university (see below). My hunch is Agile methodology will gather further momentum and become more widely adopted in the future so I need to pay attention to it.

Agile Development description:
This module provides a systematic understanding of the fundamental principles and techniques associated with agile project management, by linking the DSDM Atern framework with the object oriented paradigm through tools like SCRUM. Kingston University, CISM

Anyway, at last nights meeting Matt Roadnight, an Agile Scrum coach, explained how he coaches Agile Sprint methodology with business teams (his clients). Essentially there are three overlapping groups: Project Owner, Team Members and a ScrumMaster. Every project has what’s called a ‘Backlog’ – a set of items that must be designed/developed to progress the project. The project undergoes continuous flurries of meetings, or Sprints, where these backlog items (or groups of related and timely) items are discussed. Future items requiring attention are discussed in sprint planning meetings too.

Role definitions and responsibilities

Matt went on to define roles and stressed the importance of collaboration and communicating amongst each other he defined responsibilities. The Project Owner – typically a senior stakeholder – is responsible for the Vision which includes strategy, business case, user experience research, as well as ROI. The Analyst is responsible for the Features and finally the User Experience Designer is responsible for the Experience. While the Analyst may be a stakeholder too, the UED is customer facing. I might add at this point that there was a little push back from the attendees arguing that user experience and features should not be seen as separate activities… they should validate against each other.


Matt spoke about trying to group backlog items into related groups or Themes which focused on an particular aspect of the design. They are made up of units of User stories. A typical ‘story’ might look like this:


The next Agile UX meeting (in ~6 weeks time) will include a practical hands on 2-hr session walking through a typical lifecycle of an Agile project.

Who first conundrum surrounding product innovation and user needs

Recently, Don Norman, from The Nielsen Norman Group, posted (Technology First, Needs Last) what seems to be a provocative assertion that in product design, technology comes first, then it’s user needs. Put another way, of all the notable innovation to emerge the driver was technology (and not what UX design folk universally believe –  user observation and ethnography). Norman cites examples of how new products evolve when technologist take existing products and serendipitously produce innovative products. The examples include: “The Airplane, The Automobile, The Telephone, The Radio, The Television, The Computer, The Personal Computer, The Internet, SMS Text Messaging, and The Cellphone”

While still relatively new to the field of interaction design and all its associated family of off-shoots, I’ve found myself at a cross road of understanding. I’m looking for some clear thinking of what truly exists (of possible). The most frusting thing about the aforementioned assertions is it’s personally frustrating that I have no absolute stance. Let me continue and take a stab at it at this posts conclusion.

I’m currently reading Alan Coopers’, The Inmates Are Running The Asylum, in which Cooper begins by arguing that in a world of products operated by computer chips, products are being designed that do exactly what their programmers instruct them to do with very little user empathy. From his writings I deduce Cooper implies that we need to do more ethnography so that products offer better support and function to its users. Where technology leads it seems difficult to achieve this.

In James Kalbach’s post, Don Norman on Ethnography and Innovation, he counters Norman’s Edison example deducing:

“It would also appear that Edison did a type of ethnographic observation in inventing the light bulb”

My view of product design and innovation is that before a new product is realised many hours of work goes into understanding what users need or what would help better fulfill a users tasks. Time is spent observing – through ethnography and other methods – users and how they interact with their surroundings. Also, a great deal of time is spent truly understanding exactly what the problems are. Answering the ‘why do we need it?’ questions. After reading Norman’s piece I can see that there are alternative instances where innovation stems from evolution alone (using technology). As the world moves through the technology age, more and more instances of ‘technology-first’ will become evident.

My views are divided. I fully accept that new products (and services) are created by technologists first, especially nowaday’s for example in web applications, thus supporting Norman’s assertion. But, I also accept that there is a huge and essential role in understanding user needs that leads to innovative products development (and services).

UXCampLondon – a day out the office

As local community-driven events go none comes close to the UXCampLondon experience – people, subject matter, venue, organisation, communication and relevance all culminating into a UX Festival.

On Saturday, August 22nd, we (pre-registered attendees) gathered at the eBay/Gumtree offices in Richmond to enjoy a full day un-conference-style barcamp for the local User Experience (UX) community – the first-ever organised by Cennydd (Bowles) of Clearleft). Cennydd and his able support team did a stunning job.

I, like many folk, missed the pre-registration but scooped a last-minute place after Cennydd contacted me through Twitter on Thursday evening (August, 20th) to ask whether I was still interested. You bet. I cancelled my track racing plans and began thinking about what I’d talk about.

What I learnt about the local UX community

The local UX community…

  1. is SOCIAL – we love to network (see the Twitter tag)
  2. LOVE what they do – designing good user experiences (see The Wall of Deliverables)
  3. are willing to LISTEN and LEARN – all the sessions were well supported (even mine) with plenty of commentry and debate
  4. KNOW HOW to put on a barcamp and enjoy themselves doing it.

The ‘Wall of Deliverables’

I decided to display my interactive engaging wireframe as an example of alternative ways to encourage engagement with a slightly fun kid-like wireframe assembly method (worked well for me). With exceptional competition my chances at claiming the prize was slim, however I did receive a few votes (using little green dot stickers). Thanks to those to voted for me. The winner, however, was a set of user flows (citation needed).

Photo: wall of deliverables

Photo: wall of deliverables

The opening session

Photo: Jeff Van Campens session: Diaries of a madman

Photo: Jeff Van Campens session: Diaries of a madman

I was struck by how many folk were interested in formal study in the UX/IxD. In the first session Cara bravely kicked off her session with Getting started in UX – my quest for answers‘ as her title. She opened up for feedback on where/how she, as a Project Manager, can get started in a UX designer role. She invited the session attendees to share their experiences. I empathised with Cara by suggesting we were in similiar positions… as did another attendees too. Andy Budd‘s, from Clearleft, heretical view carved a way for talented and experienced UX designers over newly qualified Masters graduates. He view from a small agency’s persepctive.

Photo: Cennydd and Dees leading the session

Over the course of the day in-between lunch and tea breaks, fantastic sessions were being put on by other attendees. With all talks ranging from research, corporate UX, iPhone/mobile UX design, UX patterns and personal experiences within UX, there was something for everone. Cennydd and Dees put on a ‘Location’ discussion which spoke about all experiences and thoughts related to location and its impact on real-life experiences and of course UX design.

The beanbag session

Photo: our outcome from the session

Photo: our outcome from the session

Another stand-out session I attended was facilitated by Andy (Budd) entitled: Design Games 101; better ways for collaboration, facilitation and ideations. The session was very much an interactive session focusing on ways to inspire and get creative with clients. Andy tasked everyone to split into groups – size irrelevant, but smaller groups prefered. We were then given boxes, pens and a sheet of paper and tasked to design a box (yes, 3-D) for Gumtree. We were to design it so people looking at the box would know what Gumtree was and what it offered highlighting all the obvious draws. We were given 10mins to come up with the design, in our teams, and then to present our design (the box) to the rest of the group.

The exercise was great fun, ‘forcing’ each person to bond, to form good teamwork to come up with our design… something that is very often difficult to achieve in the field. The exercise got us thinking about what we were designing, but importantly, as Andy stated, to think about design without the usual constraints (again difficult to achieve). Personally, I had a lot of fun and inspired to try this technique at work, but it also got me to think about design without constraints, this before ploughing into my projects. I’m sure all my fellow attendees would concur that the session was both fun and useful.

Finally, the all important supporters

A huge thanks to all the supporters of UXCampLondonVodafoneAmberlightSaros ResearchGumtreeAxureRosenfeld MediaSilverback and Addlestones.

UXCampLondon sponsors

UXCampLondon sponsors

For anyone local to London and interested in UX design be sure to watch out for news of the next UXCampLondon (follow uxcamplondon on Twitter).

Photo: Post UX Camp London riverside setting (Richmond Upon Thames)

Photo: Post UX Camp London riverside setting (Richmond Upon Thames)

A heuristic evaluation

The usability ‘guru’

I seem to be known as the usability or website guru at work. Don’t get me wrong, I love it and flattered, but importantly I’m slowly crafting a UX (user experience) culture within the office. The biggest problem I have, however, is I’m usually drafted in at a very late stage – usually just before it’s about to go live. I know I’m not alone here – especially in the corporate world – so I know it’s common.

A typical scenario -email transcript – might look like this:

Hi Rob,

Please could you run your checks over my designs? I need to send it back to the designers tomorrow so could I have your feedback as soon as possible please?


— the requester —

“..run your checks..” It’s quite comical, but at least I’m asked so I can’t complain. The trick is to embrace the request and respond (to the requester) in an interested manner.

My lo-fi heuristic evaluation (feedback)

I need to be sensitive to my clients needs. Instead of diving into full scale heuristic – strengths and weaknesses – evaluation, I start basic quick wins feedback they can take to their designers now (before it goes live). I start by printing the visual on an A4 piece of paper and attaching it on to an A3 piece. This gives me plenty around the artwork of space to add my comments, draw lines, speech bubbles, add post-it notes, and even attach cut-out printed Twitter feedback tweet (after I’ve internally posted). I ensure the artifact has lots of colour and activity – making it look interesting and appealing. Once the piece is littered with ‘constructive’ feedback I present it in person for a walk-through. I preferably go to the clients desk so that our walk-through is ‘on show’ for all to see.

I ensure the feedback piece is left with the client so that the UX legacy is left behind – for reference and reminder.

The outcomes

The early results speak for themselves. I’ve been receiving direct and indirect feedback on how it has helped and how they appreciate all the effort. Whilst I’ve not seen earlier requests for help yet, I’m confident that will change.