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.


Design Jam – an exercise in rapid design and collaboration

I was lucky enough to be part of the first London Design Jam which took place at London City University, London. Like locally organised Barcamps Design Jam’s structure followed a similar format. The doors opened at 8.30am where the attendees were greeted to excited faces with a sense of curious anticipation. Organisers, Johanna, Dees, Joe, and Franco, had done well to plan and prepare the event in such a short time.

For once I decided not to let technology distract me from mixing and collaborating so I kept my laptop and phone out of sight for the most part. I wanted to fully immerse myself within the team.

Design Jam followed a basic theme: Bring a bunch of user experience geeks together to design a solution (to a problem) by sharing skills and knowledge through collaboration. So after writing our names (as well as skills and expectations) down on index cards and placing them on a group wall, we gathered for the day’s briefing.

Our team (Bucket9) was made up of: me, Makayla, Ana, Sjors and Helena.

Describing the problem.

What is the ideal interface to keep track of previously viewed online content, across multiple devices and locations?

What does this mean?

Nowadays many of us consume online content using various output devices and in many different contexts (on the go, in the office, commuting, etc.). Often we mark this content in some way to read it later, share it or keep a permanent record of it, mostly through bookmarking, to recall it. Retrieving that content can be difficult or clumsy so by looking at a specific user’s needs we might design a solution that eases that pain.

The question we attempted to answer was how could we make that experience easier, more effective and fun?

Solving the problem.

Before tackling the problem space we used introductions as an ice-breaker which, if we’re going to work as a team, should ease any possible anxieties. We came up with a design process which would prepare our solution for the end-of-day presentations. Whilst far from ideal, our rapid design process attempted to provide some logical structure and looked like this:

1. Brainstorm – thoughts, current methods and applications available, what works and what doesn’t. Gather our collective thoughts and create an affinity wall.

2. User research – from online research we sought quantitative data looking at what currently exists, what is popular and what percentage of the user population engages in these products. Furthermore, a short qualitative study, interviewing users (attendees at the Design Jam) on what devices are being used to mark content and how they retrieve that content later. With more time we should have looked deeper to reveal specific problem areas. This became evident when we started designing our solution, as Leisa quite rightly points out in her post, ‘Designing at speed – DesignJam1‘. Leisa reiterates how important it is to focus on a specific problem and design a solution on that.

3. Conception – understanding the territory from beginning to end. Providing the team a view (the vision) of the problem space and reference point for communication. We came up with the concept of a ‘bucket’ where all that previously consumed content would be placed into the bucket – a single collective – which with logical application allowed the user through preferences, settings, toggles, etc., to retrieve that content from various devices in a way that provides an great user experience. (the ideal solution)

Our product, Bucket. What is it? It’s simply repository where all previously consumed online content is stored and managed so users have the ability to recall and retrieve that information in a quick painless manner, that’s potentially immersive in its nature.

4. Problem and scope definition – identifying the problems and deciding which of them we tackle based on the time allocation.

5. Divergent and convergent wireframing – individually break out for 15mins to sketch as many ideas for the design of the UI and elements of it. Then reconvene to discuss our individual ideas, collaborate to determine the best possible solution(s) to move forward. Finally, wireframe our ‘ideal solution’ and then refine it, iterate it as necessary… or until the artefact communicates its purpose.

6. Presentation of solution – prepare the artefacts into a coherent story and test amongst the team.

Final thoughts for the day.

While the process of designing a solution is far from ideal, using the Design Jam format, I think you get out of it what you want, and of course what you put in. I focused less on the quality of the design process and more on work pace and collaboration, where rapid design is required. That said, for future events the organisers of Design Jam could focus on specific aspects of the UX design process, e.g., user research and modelling, concept creation, communication and output.

Bucket Concept

Bucket Concept

Presenting Bucket9 during the final presentations at Web Jam

Presenting Bucket9 during the final presentations at Web Jam


References and links.

Wiki: http://www.designjams.org/wiki/Design_Jam_London_1

Flickr Photos: http://www.flickr.com/photos/doos/tags/djl1/

Design Jam London: http://www.flickr.com/groups/designjamlondon/