Wednesday, February 15, 2012, 6:30 PM

Caplin will be hosting an “Agile UX Safari” in a couple of weeks. It will be a little different to the last one at MindCandy (we don’t have a tree house in our boardroom!) but we share their passion for design and development and mixing the perfect Agile/UX cocktail.

Check out the event –  We look forward to hosting a healthy discussion on all things design, UX and agile.

Which is to say: All civilized people write poetry from time to time.  Both its reading and its writing are necessary to a civilized mind.  But, in most cases, we should be civilized enough to keep it  - at least the writing part – to ourselves.

About writing, Samuel R. Delany

At the SPA 2011 conference, John Nolan gave a ‘rant’ about how Engineering was an unhelpful metaphor for what we do and that Cooking was much more accurate.  He made a lot of good points but one of the possibilities that struck me the most was that even though only a few will be professional chefs and bakers, everyone in society will occasionally need to do some kind of cooking even if it is just microwaving ready meals.  Is programming the same?  Maybe not yet but it’s less than 20 years since the general public got in on the information revolution and it took a lot longer than that for all the changes that the printing press brought to make themselves felt.

Despite the fact that in 14th century England being able to read was enough for you to benefit from much milder sentences (something that saved playwright Ben Jonson from hanging) it was relatively rare.  Learning to read in Korea was so difficult when they used the Chinese logography that only aristocrats had the time to do it.  When Sejong the Great commissioned the Hangul alphabet he wanted a system that even a stupid man could learn in 10 days.  It was effective enough that within 60 years of its invention it was being suppressed because the power structure of society was threatened by common people being able to read and write.

Widespread reading and writing was a huge change, a classic case of the tool shaping the tool-user.  It changes the way we think and acquire new information.  Learning it is also fundamentally hard, something that we ignore most of the time because we get it over and embedded into the structures of our brain so early.  So the fact that programming requires using your brain in a particular (and, for some, peculiar) way is no guarantee that it won’t become part of what is expected of civilized people.

I have a friend with a creative job in advertising, not the kind of role that would normally involve programming, but a big part of why he was hired is because he can actually build or prototype the things he comes up with in brainstorms.  A nurse that I know was recently expected to manually convert 230 pdf documents to word documents because someone had lost the source files.  This took her about a week of boring, repetitive work, but if she could have automated the steps she was taking and apply them to all the documents, she could have been done in less than an hour.  Some other friends of mine work in a place where they are expected to enter the same data into 3 different systems, a process that could and should be automated.  Businesses are losing enormous sums of money in staff time.   The successful businesses of the near future will be businesses that expect their employees (of all stripes) to have a minimal ability to script their workflows.

The traditional approach to these problems is to blame the software and its designers and with some validity, but it is ultimately unrealistic to think that a single piece of software will be able to fit every evolving scenario perfectly or never have to integrate with systems that the original designers hadn’t considered.  Even if those conditions could be met the users themselves (or their organisation’s processes) will find ways to turn valuable software into albatrosses.  Misguided attempts to cope with this are perhaps part of the reason that Wirth’s Law seems less humorous and more serious every year.  Long term the solution is to give users more control over the software they are using in a way that makes sense to them.

Clearly the kind of programming professionals do – writing magical incantations into an IDE – is not something we should expect everyone to be doing, but then I never prepare a curry from scratch either, nor do I own many of the tools of the professional chef yet I still manage to cook up a meal every now and then.  The future of programming for the masses will be simpler; perhaps something like If This Then That or the next evolution of Siri.  Outlook filters and Excel spreadsheets are already here, and in wide use by people who don’t recognise that they are programming. There are even board games based on programming.

At Caplin, we know that we are creating software that will be integrated and customised to fit its final niche by others, so unlike the occasional poet, we have to be aware that our code is that rare thing – a poem that will be published.  The challenge is to make sure that it’s fit for consumption by the civilized mind.

It saddened us at Caplin to hear of Steve Jobs’ recent passing, but we’d like to reflect on his achievements and how they have revolutionised the world.

Steve Jobs was not a designer or an engineer. He wasn’t the creator of all of the beautiful product designs, the flashy graphical user interfaces, or the advanced technology behind the products that Apple produced. Steve Jobs was the tenacious and cohesive force behind all the brilliant minds that produced those things, holding them together with a shared vision and determination to change the world.

From his early career, making breakthroughs with the development of a personal computer, Steve managed to make users embrace technology and welcome it into their homes and workplaces. Creating the first commercially successful computer with a graphical user interface, Steve Jobs made the computer appear friendly and unintimidating, and the masses embraced it.

“Then I get letters from people about the Mac, saying, ‘I never thought I could use a computer before I tried this one.”

Steve Jobs tied a respect for all forms of design into his work.

“Design is a funny word. Some people think design means how it looks. But of course, if you dig deeper, it’s really how it works”

From industrial design with the release of the original iMac which changed the personal relationship users had with their computers, to visual design, putting the utmost importance on the styling of the GUI: “We made the buttons on the screen look so good you’ll want to lick them.” - as quoted in Fortune magazine (4 January 2000)

He paved the way for the profession of User Experience to be born, for without user interfaces, we could not design the experience a user has with the technology. Even as a businessman, he understood that users should not be responsible for offering design solutions, saying things such as:  “A lot of times, people don’t know what they want until you show it to them.” …..”You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.”….. and when asked if Apple did market research: “None. It’s not the consumers’ job to know what they want.”

Amongst Jobs’ many achievements such as revolutionising the mobile phone, making strides in the advancement of touchscreen technology and giving us compelling mobile technology, essentially freeing us from our desks, he was above all a visionary, pushing the usage of technology to new boundaries.

He created products with such an attention to the human experience that not only removed any alien feelings towards technology, but allowed us to welcome it wholeheartedly, changing our very culture, incorporating it into our everyday lives, and even, in some cases, almost worshipping it. Steve Jobs was a brilliant thinker of our times who has changed the world in manifold ways. His legacy will live on forever in the future of computing.

Overall it was an excellent conference with a great group of attendees. The numerous inter-session conversations I had with fellow attendees were as enlightening as the sessions themselves.

Here are my thoughts about the sessions that I attended.

Monday 13th June

HTML5 Boot Camp

This session by Laurie Young and Ismael Celis was one of several focussing on the hot topics of the moment, HTML5 and JavaScript. After a brief introduction to HTML5 and what it provides we got cracking with the exercises.

Working in small groups we were asked to implement a web page that allowed the user to drag an image from the file system into it. The next task was to upgrade it to get the image(s) to persist when the user refreshes the page using local storage. Finally we were asked to use a web socket to send the image to a pre built server which would then distribute it to everyone else viewing the same web page.

There was a reasonably large range of JavaScript experience within the session, however I think most people managed to complete the exercises. It provided a great introduction to several of the most universally helpful HTML5 JavaScript APIs.

Improving Trust in Teams

Rachel Davies’ session looked at how to improve trust in teams.

Split into groups of four we were encouraged to discuss our various experiences of both low and high trust scenarios. Perhaps unsurprisingly most of the scenarios that were highlighted involved low trust. Once each of us had relayed our own trust stories within our groups we were invited to share the most interesting ones with the wider audience.

Afterwards we resumed working in our groups to draw force field charts that highlight things that we believed help to improve trust and those things that hinder it. We drew these up on a flip charts and again shared our thoughts with everyone attending the session.

Finally we looked at one of the forces behind improving trust and what we might do to nurture it.

It was an enjoyable session that has really made me start to realise that there are perhaps more facets to trust than I had previously considered.

At the Extremities of Extreme

This catchily titled session by Julian Fitzell and Jason Ayers was a fascinating introduction to the theory behind wolf pack programming. This technique takes the familiar pair programming, but turns it up a notch, taking collaboration to a new extreme.

I can barely do the concept justice here, but my simple interpretation is that with adequate tool support developers can collaborate without having to be sat around the same PC if they work on precisely the same instance of the code. The tools would allow a developer to see which functions/methods the other people working on the code base were looking at or editing. This allows pair programming to be followed where appropriate, but the navigator can slip off to do some driving if they think of something that will help to remove a block that they have observed that the driver is about to encounter. They also advocated judicial use of spikes to hunt out the quickest solution to a problem.

They had run an actual wolf pack programming session on Sunday which I am now disappointed that I missed.

At the moment the example sessions they have been running use Smalltalk, however my thoughts are about how we might trial these techniques for JavaScript development.

Invited Rant

John Nolan entertained the conference audience with a rant against the term “software engineering”, specifically that:

Software engineering does not and should not exist

He reaffirmed Kent Beck’s statement that:

Software is software

He conceded that:

Software is like engineering

But saying it is engineering is wrong. Instead he introduced us to a different metaphor:

Software is cooking

The examples he provided were very compelling, although even John conceded that he wouldn’t be changing his business card to read Software Chef just yet.

Tuesday 14th June

Unfortunately I missed most of Tuesday’s event as I was preparing for my presentation the following day, which leads me to…

Wednesday 15th June

Web Apps That Shine

I co-presented this HTML5 focussed session with my colleague Adam Iley. The specific context for it was the features of HTML5 that allow up to build web apps.

We introduced the offline support that is provided by HTML5, including local storage and the application cache. Afterwards the attendees paired off and worked at upgrading a n0tr, simple note taking website, to work offline.

The second section highlighted the tighter integration we can now get between a web app and the device it is running on. On mobile devices access to geolocation, and the device orientation is available, whilst on the desktop we can implement drag and drop both within the web app as well as to and from other applications, including dropping files into the page. Again we asked the pairs to upgrade the n0tr app to use some of these techniques.

We concluded by talking about portability and other concerns for building and releasing web apps. The presentation is available online as are the exercises that we ran.

Invited Rant

Jason Gorman’s rant was titled Slow and Dirty.

It was a thought provoking view on our responsibilities as developers with plenty of statistics to help back up his points. When starting on a new project the features come in thick and fast, however over time productivity starts to plateau. On the 8th major release of a major product (no names mentioned) the cost to write or change a line of code was 20 times as much as it had been initially.

Making our software maintainable is our responsibility, and is not something that we should abandon in our quest to keep adding new features to keep our customers happy. We need to be prepared to pace ourselves for a marathon, not a sprint.

Finally, beware the statistical aberrations that seem to have flouted all of this advice and are major successes nevertheless. Just because your great aunt smoked 60 cigarettes a day and lived to be 103 doesn’t mean that to give yourself the best chance to survive to 103 means that you should smoke 60 a day.

Specification By Example: By Example

The final session I attended was run by Lasse Koskela. Lasse asked us to split up into groups of three, then handed out an index card to each group that specified a requirement for a particular software system. Within our groups we needed to capture the specification by writing or drawing out the various examples we could think of.

My group was asked to produce the specification for an email verification system. We sketched out the interaction between the server and the user, defining 5 different scenarios that we could think of, one of which covered a hacker.

Two members of each group were asked to switch over with people from other groups. The remaining person on each group was asked to explain the examples they had drawn up to the new members, and we were asked what improvements could be made.

Finally everyone changed groups again, moving onto a requirement that none of us had worked on before. We are asked to review what had already been done, then start afresh and come up with our own examples.

Overall the session went very well and it was interesting to see how much would be achieved in a very short period of time by sketching out the examples with tight collaboration between all the members of the group. There was a warning flag though that the lifespan of the examples that we created was limited as there was contextual information that was only available to those who were involved in the conversations surrounding the creation of the examples – a little more structure might be necessary if these are to persist over a long period of time. Nevertheless this was a technique that I’ll be trying out at some point soon.

Web applications a la node
Javascript turned out to be very popular this year and the first session I went to was on node.js. Node.js is considered a highly performant framework based on its insistence on evented stream processing ‘all the way down’. We used cloud9, which is a fairly impressive web based ide. The part that you as a developer write is in javascript which is rapidly becoming more accepted as a server side language. In this case, javascript is a fairly good choice because evented io seems to be a lot easier in a language that makes it easy to create closures. Javascript developers are also used to asynchronous calls and callbacks, and not used to having to worry about threading, which all fits in quite well with the node.js philosophy. We also used a templating engine called Jade (which is a little idiosyncratic in my opinion).

At the end of the day, while node.js is very interesting from a technical point of view – event based might be an good way of writing servers in general – and from seeing javascript extend its reach, I think it’s unlikely I would choose to use it over any of the many other frameworks for building web applications.

HTML5/Javascript Boot Camp
The HTML5/Javascript Boot Camp session was run by some guys from New Bamboo, who also do Pusher. It covered drag and drop, reading files, localstorage and websockets for building a system that shared images. HTML5 has too many aspects to cover in a single session, particularly a practical one, and they said that their main aim was to get over peoples inertia at writing html 5 code.

Test-driven Development From Hell
Jason Gorman ran a session where we did the TDD ‘write a roman numeral converter’ exercise but with the aim of breaking as many of the TDD rules as possible within as little code as possible. I found it a bit harder than expected. Jason claims that being ‘good’ at that exercise requires two things; mindfulness about the TDD practices and an eagle eyed pair. He was particularly keen to make the point that many people were doing much ‘better’ than they realised at breaking the practices but their pair was not paying enough attention to spot it, so the takeaways were the responsibility of the pair and more generally trying to develop mindfulness of the TDD practices.

At the Extremities of Extreme
Last year I did the ‘wolfpack programming’ session run by the guys from Cincom (in Smalltalk). It’s an extremely interesting and fun working methodology that they consider to be ‘at the extremities of extreme’. The environment is essentially a simultaneous collaborative web based ide, where the unit tests are run on every change and code changes take immediate effect. They introduce it as taking all of the agile practices and turning them up to 11 and the whole methodology is based on the metaphor of packs of wolves. However the whole idea does depend on good, specialised tools so it would be difficult to replicate the experiment outside of the smalltalk environment that they have built.

Rant – John Nolan
John Nolan gave a short rant about how software development is not very much like Engineering at all, and that Cooking is a more apt metaphor. He also made the point repeatedly that ‘Software is Software’, and that all the concern with finding good metaphors from e.g. eastern philosophy or western engineering were mistaken, not particularly helpful and somewhat childish. Apparently we aren’t warrior monks on the path to code enlightenment.

Changing the industry by changing education
Apart from bemoaning the fact that undergraduate study at universities tend to produce people who don’t know TDD or about the existence of source code revision control systems (or sometimes even the ability to program anything), and also worrying that the teachers who teach computing at an earlier level are crushing the enthusiasm to program out of children, we also heard from someone who has (with great difficulty) introduced a 40 hour a week masters degree course in the USA where the students work on real agile projects for paying customers from day one while simultaneously learning the skills they need to work well in software. There was also some debate on the relative merits of Computer Science (I’m fairly keen on at least some CompSci), and an idea that companies with enthusiastic programmers should consider it part of their CSR to encourage them to visit local schools to enthuse the children.

Treating Javascript like a full programming language
Rich and James from Caplin ran a session that, considering the level of interest in Javascript and also the confusion over how to do it well, seemed very timely. It was extremely well attended, and was also very interesting. I think lots of people were interested in the idea that design patterns (such as MVVM), and TDD and other modern techniques and tools were applicable in javascript.

Rant – Keith Braithwaite
Keith humorously characterised software development in London in a way that got a lot of wry smiles of recognition (you’re working for a bank and you have to write some software to take some numbers from one system and add them up. However, for political and compliance reasons you’re not allowed to add them up yourself, you have to send the work to ‘the compute grid’, which only accepts data in a format that is exactly like XML but with the angle brackets reversed and all numbers have to be in base 13….). He contrasted the ‘stress’ level of what we do with the life of a farm worker (his father) or the life of a domestic servant (his mother).

Double Loop Learning
Benjamin Mitchel did a presentation on dealing with conflict based on the theories of Chris Argyris. I found the presentation a bit disjointed and rushed but it did cover some very interesting ideas about the proper way to deal with conflict. The title ‘double loop learning’ comes from not just changing our actions when we realise we need to improve but changing the mindset behind the actions. He was also very negative about the technique of ‘easing in’, where you try to get the person you’re criticising to guess the criticism you intend without you actually having to say it, and other forms of deceptive communication which are often ineffective.

One practical suggestion that I found very interesting is that generally speaking when we approach a situation of conflict we try to communicate our high level, abstract ideas but it’s better to start by communicating the observations that they are based on, moving up the ‘ladder of inference’ and checking at each step if the other person agrees. (ladder of inference: data -> selection of data -> ascribing meaning to the data -> assumptions -> conclusions -> beliefs -> actions).

Developer Anarchy at Forward
At Forward they have a very flexible and responsive working environment. They claim to have done away with managers and the traditional product management roles in favour of a much more developer led system, based on giving the developers visibility on live, responsive business value data (around the number of people visiting the site, number of click conversions, etc) and continuous deployment. They make it extremely easy for developers to follow their own ideas, but everything anyone tries receives feedback about real business value very quickly. They also offer 20 days of ‘innovation leave’ a year, where the developer is free to persue an idea. They don’t have to say in advance what they are going to do (in case they change their mind), but they do have to demonstrate it afterwards. It sounds like a very responsive and productive environment, based on the idea of making failure cheap and having as much as possible rooted in real data (even whether to fix a specific bug or not is based on whether it will measurably improve the bottom line).

Lightning Talks
We had a guy suggest that everyone eat porridge at lunch as a way of avoiding sleepiness, plus a number of companies trying to recruit. It seems that there is a shortage of good developers at the moment.

Web Apps That Shine
This session was run by myself and Ian. Naturally it was the highlight of the conference. Lots of people were impressed with the html based presentation that Ian wrote for this session incorporating interactive elements with the presentation itself. You can access the presentation and code examples at webappsthatshine.com

Rant – Slow and Dirty
Jason Gorman showed us some interesting graphs and industry data that showed that for the vast majority of development teams, spending more time on quality would result in faster delivery.

Whatever Happened To…?
Run by people who had been at SPA and other conferences 10 years ago or more, we had talks from people who had been at the forefront of Subject Orientated Programming (now pretty much dead, although traces of it can be seen in AOP), Software Reuse (achieved in a much reduced form compared to what was imagined), Design Patterns (changed the world, but not quite as positively as they’d hoped), and OO (complained about the number of ‘objects’ floating around with only data, or only behaviour).

There were lots of other sessions that I didn’t get to, and some interesting ‘diversions’, such as learning the board game Go, and hearing from the government on their plans for agile projects (something that generated enthusiasm and skepticism in nearly equal measure). Overall, it was an excellent conference, full of interesting people.

A few weeks ago, two members of our UX team (Rafael and myself) had the privilege of attending the Web Directions @Media 2011 conference for two days of talks on all things web.  The range of speakers who drew in ideas from tangent subjects, like history, product design and even gaming, gave us fresh ideas to contemplate in regards to UX. This is a summary of some of those insights.

Brian Suda – Visualising Data

One talk that was particularly applicable to the sort of data-driven work we do at Caplin was on the art of visualising graphs and charts. Brian Suda covered the basic styles of charts common today from pie charts to bar charts to line graphs and then moved onto more graphical expressions of charts. His underlying message was that in order to quickly grasp the content behind a chart, we need to strip away the other visual distractions, such as unnecessary lines, words/measurements, shading, imagery, etc. As an example of this, he referred to Edward Tufte’s Data-Ink Ratio when creating charts that don’t obscure the information. The Data-Ink Ratio refers to the amount of ink that is used for the actual data (non-redundant info) compared to the total amount of ink used in the entire graphic. What he was suggesting was that a graph that is useful should only have the non-redundant info, and get rid of all other ink usage. Below is an example of how this can be achieved:

Mr. Suda also mentioned that while visually stunning, 3D graphs proved to be more problematic than beneficial as the third perspective distorted information and hid information behind foreground objects.

I'm glad my doctor doesn't track my blood sugar with this graph or I'd be suffering from hypoglycemia.

Similarly too much “chart junk”, as Suda put it, crowds the information and distracts, as can be seen in this example where the data is paired with an image to reinforce the information behind the data:

Mirroring the data with related imagery. Thank goodness it peaked in 1980 or she'd have uncomely legs.

The take away message was that we should let the data speak for itself rather than clogging up the information with unnecessary text, lines and graphics. Perhaps the beauty is in the simplicity.

Tom Coates – A New Network

One talk that really spoke to me, coming from a product design background, was the introduction speech which focused on the whole environment around any given experience. We don’t live in isolated bubbles so we shouldn’t design in a bubble. Physical objects and digital interfaces should communicate across time and space to benefit our lives. One example of this was a guy who hacked his clothes washer so that it sent him notifications when it was done washing, when it was using energy, how much, and when it needed to be fixed. While this particular example may not be the best application of object-interface communication, it’s a step in the right direction to considering our complete environment and keeping products and services loosely joined. In industry terms this is often called ‘service design’.

One other cool concept that was shown was an interactive window display where round faced characters pulled colours from real objects, such as a man’s shirt, and became those colours. They then created colourful patterns out of all the colours they had collected that day. Bringing that level of fun into interaction design sounds promising and like a natural evolution.

(Watch the video here. It’s the bottom video. Skip to 3:13)

So how can we consider service design when designing financial applications? By being aware of the lifestyle of the people using these applications. Can we combine usage of mobile phones, desktops computers and tablets more so that our users aren’t chained to their desks? How can we, considering their circumstances, free them and benefit their lives?

Hannah Donovan – Designing without the Browser

One of the issues User Experience Designers encounter is creating designs that communicate for themselves. Often clients get confused about the flatness and skeletal-element of wireframes, or are confused about how things would interact in reality, and often understandably so. Essentially what you are looking at is a flattened, bare bones version of a web design; a snapshot of one moment on that webpage without the fluidity or context for interaction. When Hannah Donovan gave her talk on this very problem, she posed the question “What is the ¾ view of UX design?”. If we look at architecture, concepts of buildings come to life when we put people into the picture, or we animate movement throughout them in 3D models. If we look at product design, we can have 3D models that rotate to show all angles, textures, colours and give people an idea of form, shape and semiotics. With cartoons, we can create complex characters who have personalities, different poses and expressions.

With UX Design, we are often limited by the 2D, especially if we don’t want to waste the time to develop functional coded sites in the concept stage. So then we must consider, how can we breathe life into our web designs and wire frames so others can interpret them easily? If I were to scratch the surface at answering this, I’d probably lean towards having more interactive prototypes that guide the user through specific workflows, teamed with painting a more complete picture of the world of the users who will be using the design. For instance, when do they access your site or app? Why? What are the circumstances around them? How does this app/site interact with other technology or sites? How can it be simpler according to their lifestyle?

Overall, WebDirections was a fantastically refreshing event that posed new questions to us that we will seek to consider in our design process. Hopefully we’ll see you at WebDirections next year!

Sketch of concepts at Design Jam London

Below are some thoughts on the experience of Design Jams, I’ve been to three events so far, two in London and one in Oxford. Design Jams are one-day events where designers get together to learn and collaborate, the events are run by local volunteers and all results are shared under a Creative Commons License.

I’ll be using a paper published by Nigel Cross and Anita Clayburn Cross in Design Studies 16 (1995) called Observations of Teamwork and Social Processes in Design as a guide for analysing the activity of my teams at Design Jam.

The idea here is to have a better understanding of how the teams articulated a (partial) solution to a design problem in a really short amount of time, it might help designers taking part of such events in the future by giving them a series of items they could pay attention to, helping them make the most out of their team’s time and expertise.

In the experiment observed by Cross, team members all worked for the same design consultancy, were in the same hierarchy within it and brought no pre-determined roles to the experimental session. Their challenge was to design a rack for a specific backpack to fit on a specific bicycle model, the amount of time given to participants was not mentioned (although more than once they refer to it as not being long enough).

Design Jam’s topics are usually much broader, add to it the short amount of time and the fact that team members don’t usually know each other and you’re in for a challenging (but always fun) day.

Cross observes the following aspects of teamwork in his paper, and I will try to relate them to my Design Jam experience:

1. 1. roles and relationships
2. 2. planning and acting
3. 3. information gathering and sharing
4. 4. problem analysis and understanding
5. 5. concept generating and adopting
6. 6. conflict avoiding and resolving

1. Roles and Relationships

When working as a group team members have roles and relationships relative to each other, these can be formal (as in “I’m going to keep track of the time”) or informal (you simply start doing something and from then on you’re responsible for it).

Not knowing each other, the first thing Design Jam teams usually do is a quick introduction of experiences each member can bring to the team. They then go on to read the topic once again to make sure everyone is on the same page before they start discussing it. (more on this in topic 4 problem analysis and understanding)

A few roles usually begin to emerge: someone volunteers to read the topic aloud and might become responsible for presenting the group’s ideas in both the interim and final presentations. Someone else is usually responsible for time-keeping and the general idea for the project is usually based on early sketches by one of the members (more on how this happens in topic 5: concept generating and adopting). As in the experiment, all of the members at some point exercise a leadership position within the group, either by suggesting ideas or by trying to keep the team focused on the task.

2. Planning and Acting

According to Cross the team in his experiment had a great awareness of time and scheduled their tasks, but still the author admits that “conventionally, much design activity – particularly the conceptual design stage – is unplanned, intuitive and ad hoc”, he also cites other studies that reference an “opportunistic” behaviour of the designers, which means they’ll pursue ideas as they occur, diverging from planned activities. A few observations made by the author:

• – there was explicit planning of activities and scheduling of time;
• – a role of “scheduler/timekeeper” was assigned to one member;
• – at times someone will draw attention to what to do next or what they should be doing;
• – there are unplanned discontinuities of activities;
• – activities may be started without a formal decision;
• – there is an opportunistic drifting from the plan

Sketching at Design Jam London

In my first Design Jam, although we were all aware of time constraints, we had no detailed list of activities, we also did try to keep track of time at the beginning of the group work, but it didn’t last long and this surely had an impact on our final solution. This is something that was easily fixed on the next two events simply by making a list of activities we should be aware of and keeping an eye on the countdown timer.

I can recall various situations where we made use of the “opportunistic behaviour” which, being part of the design thinking, is something positive as long as you have an established plan to go back to.

3. Information Gathering and Sharing

Relevant information needs to be gathered, extracted from the source and shared with the team (one interesting aspect of the experiment is that the researcher had in his possession additional information on the project that could be requested by the team as they needed it):

• – gathering and sharing of information is not formalised;
• – errors in understanding the requirements, misinterpretation of information and forgetfulness of requirements;
• – misunderstanding of apparently shared concepts;
• – use and reliance on individual experience or knowledge

As in the experiment, our teams had no formal role of information-gatherer or a defined strategy for gathering/sharing information. At some point we all decided we should look for similar products that had some of the characteristics we were identifying for our solution, but no specific notes about each product were made, we relied instead heavily on our individual experiences and knowledge during research and exploration.

In future versions of Design Jam it might help making the topic available a day or a few hours before the start of the challenge, so that everyone can do their own research and then bring some ideas to the table. Another possibility would be for the organisers to prepare some material with references giving the teams a starting point.

4. Problem Analysis and Understanding

According to Cross there are two ways of analysing and understanding a problem: listing and framing.

When listing, you’re summarising and sharing the problem with your group (using a whiteboard, flipchart, etc.); framing is a way of internalizing it, through sketches, notes or verbal exchanges (for example, saying “hmm hmm” when someone explains something to you) before making your understanding of the problem external.

A recurrent behaviour on all Design Jams was not giving enough time to framing as for listing of the problem, a tendency is to try and solve the problem as a group, sharing/discussing a problem with the group is important, but give yourself a few minutes to think about it on your own, making notes and sketches. This was especially true on my first Jam, by the end of the day I had a feeling of not having completely grasped what we were trying to solve, which is a fatal mistake when trying to design something.

5. Concept Generating and Adopting

The experiment is mainly concerned with how concepts are developed together and how team members persuade others to adopt a certain concept.

• – concepts are built cooperatively: concepts have to be built up, with ideas being discarded along the way and additions and variations added to a concept;
• – persuasive tactics are used to get concepts adopted: it may be necessary to persuade other team members to the value of a concept, it’s also common for designers to become emotionally attached to concepts (usually their own)

Final presentation at Design Jam London 2

On all Jams the teams I was part of we had no major issues cooperatively generating and adopting concepts, we’d probably get better results by using idea generation exercises (the 6-up template, for example), as it was suggested by one of the team members and done by a couple of other teams. I noticed we suffered from what Cross calls the “fixation effect” of a concept, after we saw a particular early sketch from one of the team members we all used that idea as a starting point, not giving much thought about alternative approaches.

6. Conflict Avoiding and Resolving

Disagreement between members of a design team are inevitable, but since they all (at least we hope they do) want to find a solution for the design task, they’ll find ways of resolving or avoiding conflict, according to Cross these are usually expressed by means of:

• – noncommittal “agreements”: shrugging shoulders or saying “ok” without really meaning it, when this happens issues usually reappear later in the process;
• – arguments that close a disagreement: someone will come up with examples of existing products/situations that prove a certain idea to be inappropriate;
• – leaving disagreements unresolved for the sake of finishing the task: usually expressed as “let’s keep going and take a look at this later” or even making fun of an idea as a way of dismissing it (usually when team members know each other reasonably well);

On my first Design Jam we had a few points of disagreement inside the group, especially as we moved closer to the end of the exercise, where we couldn’t quite agree on which format would be ideal when starting to add content to the interface, because of the short amount of time though, we ended up leaving those disagreements unresolved and trying to get as much as we could ready for the final presentation, the normal thing would be of course to look for arguments that could close the disagreement.

Conclusions

Even though my analysis is not as precise as the original experiment (I wrote this based on my memory from the events, Cross recorded his experiment on video), our behaviour matches almost all of the those described, I think it’s a valid exercise to reflect on this and be mindful of them in the “real world”.

I was not completely satisfied with the design solution from my first Design Jam, I think we had some interesting ideas come up but we didn’t explain/develop them very well. The results from my groups in the next two Jams were considerably better, probably because we accepted beforehand that a “perfect” solution was just not possible with the amount of time given, finding a main line of thought and keeping the team focused on it during the whole exercise was vital.

Meeting new people with the same interests, listening to other ideas on the same design challenge, watching different solutions and then reflecting on everything and trying to identify where we could have done a better job surpasses any final result and makes joining an event like Design Jam well worth a Saturday.

I highly recommend other texts from Nigel Cross, he’s written a few on the importance of sketching to design that are especially interesting, take a look at his complete list of publications.

You can watch interim and final presentations from my teams here:

Design Jam London – Team TubeViz

Design Jam Oxford – Team CycleConvoy

Let me know your thoughts/experiences related to team work on events similar to Design Jam. Thanks for reading!

References

Cross, N and Clayburn Cross, A (1995) Observations of Teamwork and Social Processes in Design, Design Studies vol. 16, no. 2, pp. 143-170

Cross, N. ‘Understanding Design Cognition’ in N. Cross Designerly Ways of Knowing, Birkhäuser, Basel, Switzerland, 2007, pp. 99-116

James Bond was not having a good day on the Gold Exchange

Caplin are not ones to pass up on this type of information. So last Thursday I went down to the rather nice Grange Hotel in St Pauls in order to attend the seminar.

Of particular interest to us were the demographics of the people who attended. Caplin are big believers in using personas (specific user profiles of real people) to assess how to better serve our customers. Getting to know the end user is part of making sure that we design software that offers the best experience for that person. City AM is not just distributed in Central London or the Square Mile. Many outlying railway stations will have a distribution and the majority of the people with access to the paper will not be city workers. Yet they are choosing to read a very business-orientated paper in preference or perhaps in addition to the Metro, the wider news and entertainment-based offering. Just who are these other people who either trade or are interested in trading?

There were perhaps 60 people in the room, down on last year apparently. Perhaps the recent somewhat depressed market put some people off. I asked one attendee why he was there and was told that a unpleasant experience with spread betting had made him feel that he needed to learn some strategies before trying again. However the majority of people in the room were active traders, mostly in FX. The guy next to me had been able to leave a career in sales to make a living full time from Forex trading. About three quarters of the room wearing suits, only a few in jeans and jumpers and of the latter all traded privately.

I asked GFT what they felt was important to their customers, citing the Single Dealer Platform (SDP) as an example. SDPs have overtaken multi-dealer platforms in the FX market in recent years, accounting for about 25% of all FX trading. In contrast to Multi dealer platform which offer the user more than one price, they deliver integrated pricing and liquidity from multiple sources and then make them available via a single user interface By offering a SDP, a bank or other sell-side institution can concentrate on providing a better service for their clients.

GFT said that they felt that their customers were with them due to the customer service that they could offer. The help available, 24/7 live chat, the quality of the trading software and analysis tools available and perhaps most crucially the connectivity were much more important to the clients than the prices themselves. In fact in when any web search will uncover multiple brokers offering 0 to 0.5% spreads there have to be other things on the table in order to keep your users.

Worrying times for the dollar?

Onto the speakers. David Morrison, GFT’s market strategist, presented on “CFDs and Investment Themes for 2011”. He described the advantages of trading contracts for difference whilst the disclaimer, that one can lose a lot of money, was also never far away. The high degree of leverage can work against you as well as for you. An interesting talk on the political forces driving the markets followed, discussing the movements of the precious metals and oil and whether the former had already seen their peak or still had a way to go. The message that stuck out for me on the gold bubble? His observation about those awful TV commercials that urged viewers to send in their Elizabeth Arden necklaces in exchange for wonga. “CASH FOR GOLD”. When those same companies start selling then this really will have been a bubble. Oh and watch out for the Fed’s second dose of Quantitive easing and whether or not it is the last.

Boris Schlossberg spoke about “Actionable FX Strategies for the Individual Trader”. Boris is the Co-head of Global research. He had a super-confident presenting style, easy with his topic and betraying his Wall Street roots. Schlossberg had promised to share with his audience the one critical economic variable that matters more than any other in the currency market. That variable? Interest rates. Together with the state of economic growth, trades between any chosen countries and politically in/stability this can give the trader a good idea of what is driving the exchanges. Traders were encouraged not to oppose the markets, but to find the trends and go with them. “Trade what you see, not what you think”. Tight volatility points to indecision. A choppy market is best left alone. Schlossberg gave us a strong trade home message. Never move your stops, don’t let sentiment get in the way of economics. Get a separate account to experiment with. I think I might take his advice.