My background has often blurred the line between product manager and UX person, and I was interested to hear some tension(?) at London IA last month about IAs being perceived as claiming product management territory.

Inspired is mostly a practical, sane book exploring familiar (to me!) problems. It deals with UX a lot and is definitely worth reading if you are working in an environment that has both UX and product manager roles.

Marty suggests (p6) that the right ratio of roles to have is one product with:

• one product manager
• ½ interaction designer/information architect
• ⅛ visual designer
• 5-10 developers

He sees 4 ux roles, which maybe be separate individuals or not (p18)

• interaction design (deep understanding of users, tasks, flows, navigation, wireframes)
• visual design (precise layouts, colours, fonts, emotions)
• rapid prototyping
• usability testing

There’s some supportive stuff about the timing of UX work (p117)

• UX work should be done before implementation,
• using a sprint zero approach, maybe one or two sprints ahead for an agile team.
• need to give UX team some (but not loads) of time and space to research and design

Some good advice for working in large organisations (p170) and with your manager (p63)

• measure and plan for changes in plans
• conduct the real meeting before the official meeting
• be low-maintenance to your manager (use someone else as your mentor)
• learn how decisions are actually made in your organisation
• do skunk works projects/seek forgiveness not permission
• build relationships before you need them

Other interesting points

• doesn’t recommend outsourcing interaction design because it takes time to develop the deep understanding of the users, they need to be on hand throughout the project and UX is just too core to the business. (p19)
• recommends that Product should be “organizationally on par with engineering and marketing” and that ideally Product should include the UX team (p53)
• recommends high fidelity prototypes as the product spec (p113)
• product manager should attend every usability test (p133)

At the BBC, our attitude to constraints and their role in design was one of the sources of friction we identified between our (finely defined) UX sub-disciplines. Those with ‘architect’ in their title tended to be very conscious of the constraints. The IAs often spent longer working with particular products and were more likely to be embedded with the product team. They developed a detailed understanding of the content structures, technical systems and the organisational politics around a product. The interaction and visual designers were more likely to work from the design hub with other designers and to work on products for defined projects. They came to projects fresh and unblinkered. Neither situation is wholly good or bad. Both bring insights.

But it did result in the designers feeling that the IAs were too aware of the constraints and were unambitious in pursuing the best solution for the users. Conversely the IAs often felt the designers were being idealistic and naive, and that’d they never get anything built.

(these are broad brush generalisations, there were some great examples of successful partnerships between the teams but there were certainly issues)

In these conversations somebody usually brings up the serenity prayer:

“God grant me the Serenity to accept the things I cannot change, Courage to change the things I can, And Wisdom to know the difference…”

My instincts are often on the side of accepting many of the organisations constraints. I like realistic plans, and I’m aware how deep seated some constraints can be. I don’t see how designs that never see the light of day help the users. But it would be simplistic to say I’m always on the side of conservatism.

In my last team, our troubleshooting explicitly involved dividing problems into ‘change’ and ‘accept’ categories but I surprised myself at how uncomfortable I felt at some of the things that ended up in ‘accept’. I wasn’t happy to just leave them like that.

This all reminded me of a creativity course that I found helpful in accommodating the instincts of both dispositions. One of the techniques the course taught was to explicitly structure ideas generation into phases:

• firstly unshackled ideas generation (everyone is reminded they’ll be able to bring the constraints in at the next step)
• then a step where the ideas are filtered with the constraints. Ideas are divided into do-able now or soon, and ideas that require work to tackle the constraints (which may require another ideas generation session!)

The approach helps me to use both my desire to make things better and my desire to get working stuff out the door. The different types of ideas could be taken forward by different teams but I suspect most of us would be happier if we could accommodate both types of challenge in our our work

In reality these sessions are rarely entirely useless and I’d prefer to run them rather than having nothing at all. A lot of feedback is often about content which can usually be changed at the last minute.  You can also capture general customer research insights that can feed into the next project.

A couple of projects I’ve got involved with recently have involved late stage usability testing . We need to tackle this but we’ve got some bigger challenges than usual in bringing in a better approach to usability testing.

1. The organisation can’t afford rounds of testing

This is hardly unique to us and I fully expected this when I took the job. The answer usually involves the word “guerrilla” at some point.

2. We have some challenges in doing guerrilla testing

Our target audience (blind and partially sighted people)  is a small section of the population and can’t easily be found by popping into libraries and coffee shops. Everybody else really isn’t representative and would give completely different results. Although admittedly our target audience can often be found in our own offices, or rather in the public resource centre downstairs. But you can’t just get them to test on your laptop as you need to have the access tech that they are used to using. We might need to try and find folks who are both willing to test and also use the access tech we have available. Not insurmountable problems, but will take a bit of planning.

3. Can’t easily do paper-based testing or flat onscreen mock-ups.

I’ve mentioned this particular challenge before. We can survey and interview quite easily. We can test existing or competitor systems. But when it comes to trying out how well new designs are working, our options get a lot fewer. Whilst it would be interesting to experiment with tactile mock-ups, the admin overheads and learning curve probably aren’t justified.  Really we should just concentrate on working prototypes, rather than getting carried away with how cool an IA presentation idea “tactile wireframes” is.

The profession is still judged, by and large, by the quality of our documentation. Most recruiters and hiring managers seem more interested in the quality of annotation than the quality of thinking.

I’m rather inconsistent in my approach to documentation. Mostly the medium is picked for the context. Is the project agile? How good are the developers? Is there a remote team? Do lots of people need to be consulted? What are their reading preferences?

Whilst I’m happier with pen and paper  than computer, I think it is far to say that I doodle a good deal more than I sketch.  Now there’s always a way to get chickens into a blog post… this little trio were sketched during a conference presentation, presumably a scintilating one and probably about something 2.0 related given the labelling of the fowl.

In fact, it appears I doodle most when irritated by the speaker. In this case , rather than asking an insightful question to highlight the cliched and superficial nature of the argument, I wrote “blog, wisdom of the crowds, whatever”. That told him, I’m sure. I do still want this mug though:

None of this is what my friend had in mind though. She’d like this more: part user journeys, part concept map, but mostly not very pretty. Not really for sharing (apart from with you lot, of course) but it could be re-jigged into something more respectable.

I do these little pages all the time but again they aren’t for collaborative purposes. This one was so I could sanity check we had all the functionality we’d need on the product backlog before the supplier drew up the drawbridge.

Then of course, there’s cheating. Those search forms I shared recently were created in Visio but with the sketchy stencil:

I very rarely do this kind of documentation anymore. My business stakeholders are bored by them and the developers are best told what to do by pointing over their shoulders.

I do still do content models. This kind of specification still gets traction with the developers:

But, horror of horrors, a lot of my documentation these days is actually reasonably high-fidelity mock-ups. These are really aimed at the business stakeholders. Colours and fonts are pretty much fixed by our visibility requirements, so the business units know better than to ask for their favourite shade of puce.  And they worry less if they don’t have to try and visualise from wireframes. It doesn’t take me any longer as I’ve got a colour stencil and the choices are pretty limited.

Is this ironic? I’m working for an organisation of and for blind people and I’m producing the most colourful deliverables ever.  But then you should see the colour of the office floors.

Something of the bits of Latin /Greek are obvious, some not:

Carpenter=wagons, Cooper=vats, Plumber=lead, Lawyer=law, Miner=digging, Baker=roasting, Butcher=slaughtering goats, Doctor=teaching, Teacher=also teaching, Farmer=collecting tax/rent, Soldier=being paid, Tinker=jingles, Tailor=cuts, Dyer= dark/secrets

Vicar interestingly just means substitute or deputy.

And who slaughtered anything that wasn’t a goat? (I’m putting the etymological dictionary away now).

It seems for a modern job title that a single word is not enough. You need a combination of object and activity.

Possible objects in my professional sphere:

project/programme
product
business
content
user experience
customer experience
usability
interaction
systems
software
applications
development
technical
information
accessibility
search
web
digital
online
intranet
e-commerce
sharepoint

Posssible activities:

manager
analyst
architect
designer
producer
engineer

Some people seem to feel hemmed in by the activities bit and choose something vaguer. This usually implies they will only produce opinions not things e.g.

consultant
expert
specialist
professional

In the public and non-profit sector you also get ‘officer’ as in police officer but also projects officer or knowledge officer. This usually just means one who holds an office and seems to be a way of avoiding saying ‘man’. “Head of” is similar but usually at the opposite end of the hierarchy.

All combinations of object and activity are plausible and many are common. Although so far I only know one Usability and experience design oompa-loompa.

“Our bounce rate is pretty darn high for folks who find our site through search: about 68%. New visitors also bounce at a high rate: about 67%. Our blog, which gives us the most traffic from search, has a bounce rate above 75%.

Friend of NTEN Avinash Kaushik says that organizations should aim for a bounce rate under 50%. We don’t expect our new visitor bounce rate will get THAT low, but there’s some work we can do to make sure people find MORE great content and stick around our site.”

via Wireframe Testing: Failing Informatively | NTEN: The Nonprofit Technology Network.

I don’t use my IA title much within the organisation. The web team get it but that’s four people.  I tend to introduce myself by what projects I’m working on. In project kick off meetings and meetings with stakeholders I’ll explain what I’ll be doing on the project but not my title.

A lot of the teams I work with are intimidated by IT projects. And for them the language of user experience design and information architecture is as alienating and terrifying as the language of server architecture and database design. It is all big words from people who get paid more than they do and seem to work in an alternate universe of conferences, social networks and blogging.

So mostly my introductions go something like…”I’m Karen, I’m part of the project team and I’ll be responsible for making sure users can find their way around the new site”. Or “the search actually works this time”. Or “putting your content into the system isn’t such a nightmare”.

So my boss and I are trying to come up with something that both more accurately conveys what I actually do and is also a user friendly one.

Anyone got any examples of doing user research into what their job title should be?

“Admit it. Ours can be an insular profession. As much as most of us think we communicate simply and effectively, we often don’t. Why? I think it’s because we’re sometimes overly concerned about how we’re coming across to our fellow UXers. You know what? Forget about them. Your real audience is the business stakeholder. When you’re planning a presentation or trying to figure out how to communicate your research or design solution, don’t let your inner Nielsen—or head-Nielsen for fans of the reimagined Battlestar Galactica TV series—prevent you from communicating in terms and concepts that your stakeholders can understand and groove on.

You know what this means, don’t you? You’re not allowed to use the term heuristic evaluation anymore. Banish it from your professional vocabulary! Now, wave goodbye to it, because, if you use it again, I will personally come to your house and punch you in the arm.”

via 8 Things You Should Be Doing in Your UX Practice, but Probably Aren’t :: UXmatters.

Absolutely. Couldn’t agree more. But it is ok to tell them you are user experience designer?

We’re going to make sure our site architecture is sound before we worry about making it purty.

The story so far:

* We started with a card sort. Rebecca Sherrill, our Information Architect at Beaconfire, has written a terrific synopsis of that process, with definitions, a walk-through of the process, and an overview of the findings. You should read it.

* Building on the results of the card sort and an Audience Matrix (Excel) we had filled out earlier, Beaconfire produced a draft site map. Holly and I worked with them in a conference call to revise the map (PDF), then brought the entire staff into the process during our weekly staff call.

Beaconfire now has our feedback, which they’ll use to refine the site map, then produce a wireframe version of the site.

via Redesigning NTEN.org: of Card Sorts and Site Maps | NTEN: The Nonprofit Technology Network.

The Toolkit is divided into four sections:

The Introduction will give an overview of HCD and help you understand how it might be used alongside other methods.

The Hear guide will help your design team prepare for fieldwork and understand how to collect stories that will serve as insight and inspiration. Designing meaningful and innovative solutions that serve your customers begins with gaining deep empathy for their needs, hopes and aspirations for the future. The Hear booklet will equip the team with methodologies and tips for engaging people in their own contexts to delve beneath the surface.

The Field Guide and Aspirations cards are a complement to the Hear guide; these are the tools your team will take with them in order to conduct research.

The Create guide will help your team work together in a workshop format to translate what you heard from people into frameworks, opportunities, solutions, and prototypes. During this phase, you will move from concrete to more abstract thinking in identifying themes and opportunities and back to the concrete with solutions and prototypes.

The Deliver guide will help catapult the top ideas you have created toward implementation. The realization of solution includes rapid revenue and cost modeling, capability assessment, and implementation panning. The activities offered in this phase are meant to complement your organization’s existing implementation processes and may prompt adaptations to the way solutions are typically rolled out.

via Human-Centered Design Toolkit – Case Studies – IDEO.