Boxes and Arrows: Comments by James Kelway

James Kelway — Mon, 12 Nov 2007 11:35:16 GMT

Hi Ben

This article is in the pipeline and will certainly feature invisible variables. It is those variables that can impose fragility to the Agile environment but by embracing UCD ethos and a number of other elements agile can still be a force for good in development culture. I will use a case study to illustrate this – which is due to launch in the next 2 weeks…

Cheers
James

James Kelway — Sat, 12 Jan 2008 16:20:37 GMT

Just to let you know that the article is finished – I’m just awaiting the go ahead from the Boxes and Arrows team…

James Kelway — Mon, 16 Mar 2009 21:51:02 GMT

Hi Andrew, I agree with your reservations about our industry’s use of personas and its great to read another angle about how we use them. I feel that in many environments, as Livia points out, they are the tools that you need to capture the imagination of stakeholders who will inevitably throw the project off the road on an ill-conceived whim. I have found that there are good and bad uses of personas and I guess this is what we are highlighting here.

I do feel that documentation, deliverables, are key to define how successful our work is. Design in general has always suffered from not documenting its reasons for making design decisions. The successes are often realised and celebrated but the methods behind these cases are not published, or lost in time, in the heads of the designers.

This is a strength of information architecture and user experience. We have the tools to establish why we can achieve an upturn in site revenue or why the user’s feel that the site is a better product. To deny personas would be a mistake, as 37 signals suggest, and to feel a persona more by role-play sounds interesting and I can see for some situations it is a necessity.

Dan Brown recently mentioned in a talk at IXD that if Apple had used personas – would the browse feature of an iPod have been more intuitively designed? Perhaps a great product could have been even better. I am of the opinion that they are part of a tool box that helps us create better designs, better products. As you say, if they make us honest or true to the delivery of a project, then a persona is a great thing. Let us keep hold of them, and make sure they are alive.

James Kelway — Wed, 16 Apr 2008 22:15:03 GMT

Cheers Andrew – I think collaboration, as you say, between team members is key.

I recently wrote a post you may be interested in here http://userpathways.com/2008/02/22/user-stories-or-person… though not as in-depth or well-researched!

I think the communication with stakeholders is separate like you say to the communications you have within the team and perhaps different deliverable is the way to go. A richer set for design and development maybe?

James Kelway — Wed, 02 Apr 2008 12:18:23 GMT

Thanks for a great series Joe. You mention in an earlier article about how this can be applied to other sites, not explicitly dashboards or portals. I think this way of looking at the IA that can be used for various online solutions will be really valuable. In terms of governance for access rights on sites where there are multiple web editors, this way of isolating page elements helps in defining the roles of users who administer sites.

Have you thought about widening the perspective to include all types of website? I am thinking particularly about CMS and how these software solutions affect what can be delivered and the controls content producers have over the visual representation of the pages they maintain. Obviously what they do with a page has a big effect on the user experience but these patterns that you outline here may help to control, or define, the ability to move elements around.

The company I work for are about to purchase a system that will give control over to the website producers, away from the UX team, so they can change the page in an instant. Have you any tips to look out for in terms of user engagement metrics or the monitoring of what they do with the aim to not disturb the user experience?

James Kelway — Thu, 03 Apr 2008 12:03:42 GMT

Mainly I think we have cultural issues to deal with on top of the technical implimentation and also the impact on our users. I have to remind myself that our users are the people who are on both sides of the website – the people managing the content and those who are viewing it. So I guess we do not want to constrict their creativity in producing killer content, but we don’t want to destroy user engagement because of a few minutes of madness with no guidelines or governance.

We are definately going to set up some metrics to easily see where choices on the interface have impacted on user experience. Thanks for the list here as that will provide the bluepint for our sequence of measurements. We have also worked on other engagement metrics such as frequencey of visits, bounce rate, page impressions per user, time on site etc.

We are also working on A/B testing which with the new CMS, should enable the producers to conduct their own testing. As there are so many different sites this seems the only way to ensure a level of test and measurement. Our IA department numbers 1 – and the UX team are too stretched to offer anything other than consultation.

So this leads me to governance. The navigation (and revenue drivers such as subscription sign-ups) I think should be locked down. At present all elements on the page can be moved around, a WYSIWYG approach for the site editors. These elements are so key to user’s interactions that the thought of them moving rings the usability alarm bells.

I’m thinking an adaptation of your model, the layers you mention, needs to be constructed and outlined to all the stakeholders. So often our discipline seems to come across as the killjoy to the party when new technologies are bought and developed. It would be nice to somehow come up with a workable solution where our producers can create without feeling their hands are tied but our user’s needs are not compromised through changes in the interface.

Dan Brown’s take on this is interesting as he rightly states CMS is not linear and in fact the whole process will become more iterative – perhaps that is what we are leaning towards, iterative content management. With the testing and live metrics this will be even more true. I will keep you posted on future developments – but thankyou again for the series, it really has allowed me to start framing the problem.

James Kelway — Mon, 17 Nov 2008 22:13:53 GMT

I guess there are are many ways to skin a cat. Keep voting and I will definately do it, wireframes are too complex to gloss over. I have found that from the paper to the html prototype they all have their place and particularly within the Agile environment

James Kelway — Mon, 17 Nov 2008 22:14:05 GMT

Keeping up is a good point. I will try to cover future aplications of prototyping. The monthly wireframe issue is a great idea by the way. Such a complex area that touches everybody in a project team

James Kelway — Sun, 11 Apr 2010 11:26:16 GMT

Great to have some feedback here with some important questions. I have the benefit of hindsight and much more experience since this project went live. This gives me a perspective similar to the one that Anthony Colfelt writes in his article a couple of months ago (http://boxesandarrows.com/view/bringing-user).

@Marius

I was effectively a UX team of one here so I did the IA and interaction design, working very closely with the visual designer (for UI) and the development team for functionality of the elements. This would occur on a daily basis, very much in a loose, iterative way of designing and developing simultaneously. So although wireframes were handed to both parties, decisions were being made around these documents as they were being worked from and we moved quickly, sometimes without further wireframe revisions.

So yes it was a Sprint 0, for some elements and then I carried on through subsequent sprints to check the new functionalities with the website editor (product manager). It was not optimal as a way of working, one problem we had was that we were located on several floors which meant a lot of protracted meetings. But under the circumstances, it was the best we could do.

@Holger

I too hold a love/hate relationship with Agile. Mainly as I am a big supporter of iterative design, and a development process that seems to be based on the cyclical nature of design is very interesting. However it does have limitations, mainly on the type of culture that it operates in. Some companies or organisations will never be able to build in a truly Agile way as much as they are incapable of utilising social media technologies. Unfortunately it is the nature of the beast.

Agile, like so many new ways of working, seems to require a course in change management before people rush headlong into it. Your fears about Agile are mirrored time and again in the clients that I work with. They like the idea but they feel they are on a train unable to get off. If it is not managed by a very empathetic project manager the client feels lost and out of the loop with a budget being spent on intangible elements they can not see.

Fragile is such a great way to put it, and there is definitely room to improve this area of Agile. It seems to need the UCD thinking more at its core to help bridge that gap between the concept and the delivery of the product. Agile is development and delivery focussed but it needs great communication and collaboration between people to produce quality results.

@Eric

I totally agree about the difference between launching and construction. This being a relaunch I highlighted the project in this context but as you rightly say, construction is the focus of Agile. Launching in a phased way was the initial ambition of the development team but it proved too much of change in technical architecture.

James Kelway — Fri, 30 Apr 2010 01:19:50 GMT

@Craig

This sounds really interesting and glad to hear it works for you. It is dependent where you operate, but it is a really important matter to find the solution that is right for the context you operate in.

@Justin

The boundary spanner is actually the core message of this article that I wanted to get across and I am really glad you picked up on it. UX people are the ones who have the ability to bridge those roles in organisations that may be more traditional and subject to organisational structures that confine efficiency. We should strive to go beyond boundaries, reach out and collaborate beyond our remit as a matter of course. If we do this effectively and avoid the jargon (especially amongst the stakeholders) then business value is derived from our behaviour. I firmly believe this is the
differentiator between the usability guy and a person who will transform the product to a desirable or delightful experience.

@Matthew

The case study really highlights what occured within the confines of what we were able to operate in. Agile was the method of the development department. You are right in saying that iterative design is not agile, I completely
agree. Agile is a way of getting work done with a series of steps and methods that are clearly defined, taught to
scrum masters and stuck to rigidly in my experience.

I would say that iterative design happens in a different arena in a different mode in the development of the site. Sorry if this was unclear - but it is an important distinction to make.

I agree with your point of how it could be done, but that was not the reality in this particular company and that moment in time. The organisational make up of the business proved to be an impediment to developing the site optimally. This meant that the ‘Agile Master’ was not actually the boss of the team but the client of internal departments. The scrum was managed by another person, who led the development team. In this situation, there was no way that they would do any IA at all.

I have written about this recently (http://userpathways.com/2010/04/agile-and-the-importance-…) and it would be great to have some feedback.

What you raise here is really valid, but this situation, called for this solution. It couldn’t be done in any other way – at that moment. It was not optimal but it achieved the brief in a manner that satsified both the users and the business.

James Kelway — Mon, 10 May 2010 12:10:36 GMT

@Matthijs
Thanks for the links and I agree Sprint 0 is the way to go – one sprint ahead. But as you say, the product owner is there also in this IxD stage. Such an important fact, and one that needs to be encouraged and monitored to ensure a successful project in my opinion.

This parallel way to design and develop works really well when communication lines are clear and used frequently, if not it can go badly wrong very quickly. Hence the need for boundary spanners, or product owners who collaborate in all stages of the product’s creation.

James Kelway — Mon, 21 Feb 2011 12:31:21 GMT

@ Andy
Thanks for the comment and I have recently posted on my blog this same subject (or at least this is covered in the comments). I agree about people being so important. Getting the right team and the right mix of personalities will define how easy it is to reach success.