Category: User Experience

Making a start on digitalness part 3 – organising for digital

~ mylesrun ~ Leave a comment

It has taken longer than I hoped to get round to this post. This is the third in the series of loosely themed pieces about what it means to ‘be digital’ and some ideas on how to make a start. The first and second pieces are available for the curious/persistent reader.

The impetus to write this post came from leading the first of a series of sessions for Digital Leaders on Developing a Digital Mindset. Future sessions in London and Leeds are available as part of their Academy courses.  The sessions are short, workshop style events aimed to give those with less hands-on experience some ideas and techniques to consider in their work with their teams. The premise is that we all need to be more digital – so how might we go about it.

During the session there was discussion about technology integration programmes in organisations and the fact that they are often pitched as transformation efforts. This, in turn, lead to exploring the notion that ‘being digital’ is not really about technology  – or that, technology alone is insufficient for real digital change. Technology programmes can generate efficiencies, speed and lower cost (they can also deliver none of those things, at their worst). But they probably won’t change the organisation much, and are less likely to change it in the far-reaching ways ‘transformation’ promises.

Some of the most significant elements of a digital mindset are how groups plan, behave and organise. Being digital is about people more than it is about technology (or at least as much) – hence the significance of culture. The ways and means of systems implementation will not support or sustain a digital mindset. Don’t be fooled by systems implementation houses that pitch this as an outcome from use of technology.

Anyway, with that in mind, this post is about organising for digital. Again, in no strict oder of priority, here are some of the most important features of digital organisations or teams. They are:

  • Flat (or flatter). This is not to say that there is no hierarchy. Some people are in charge and need to be (some decisions will need a ‘buck stops here’ approach). A flatter team or organisation will, however have shorter routes between a decision and action. It will also have less mediation and introduce less confusion between a decision and the enacting of a plan to carry it out. (Empowered and accountable teams can get things done with less fuss. as explored in Post 2). From my personal experience, the BBC is not a flat organisation – it is lumpy and bumpy in arcane and vertical ways. Time to and from a decision to action is best measured in planetary metrics. Spotify, on the other hand, is pretty flat and swift in movement and action.
  • Open (or tending to openness). This goes hand in hand with flatness and trust. It is easier to get things done quickly if access to information and to people is more open. Open document stores and open access to performance data are principles that digital organisations have been energetic in adopting. Team members are trusted to use data responsibly, making the apparent risk of open sharing lee problematic. (Organisations with a parental leaning will struggle to adopt digital ways, I believe. They are better suited to programmed waterfalls and the committees needed to steer them).
  • Accessible. Teams working in an open environment are easier to access – and anticipate ease of access in turn. This is partly a facet of openness and the access to information that results from it. It is also a cultural feature that allows for access to expertise and experience throughout an organisation. The structure and model of Stack Overflow echoes this across technology disciplines, being built around the expectation that access to expert guidance is readily available. Tools like Slack and Trello facilitate open access.
  • Small. A productive digital team tends to be a small team. Or, not too big. It will be large enough to get stuff and be self-contained but not so large that it becomes unwieldy, slow and over complicated. Jeff Bezos still stands by the principle of Two Pizza sized teams at Amazon. The optimum size of a team is one that can be fed by two pizzas (probably in the range of 8 to 10 people, depending on pizza size and appetite). It is easier for this size of team to take decisions and to communicate those decisions and share relevant information. Big is not beautiful but a large organisation can have many two pizza teams within it.
  • Multidisciplinary. Those small, self-contained teams are made up of the required skills and capabilities to be self largely self-sufficient and productive. A productive team will have the ability to:
    • Gather and analyse data and communicate information and usable insights from it
    • Design, test and improve a good user experience (this will include but not be limited to user interface and visual design)
    • Develop and test code – or at the very least, have access to and control over developers
    • Manage a the activity, inputs and outputs of the team, most often in the form of an agile project manager
    • Take responsibility for marketing, communication and distribution. Otherwise known as “if you build it they really might not come”.
    • Manage the product and define the roadmap around user needs and priorities
    • Manage the product and define the roadmap around commercial needs and business outcomes
  • Flexible. These small and multi-disciplined teams are easier to form and reform around shifting priorities. There is less organisational heavy lifting required on behalf of the business. Similarly, extended and complex orientation is less likely to be needed as new teams group around their objectives. More mature digital organisations will also have developed production tools and infrastructure which supports this flexibility and can be applied across many or all areas of business.
  • Clear.  Whilst the objectives of the team are clear, this is equally true of the individuals of the team. A smaller team is easier to direct in this respect. The daily stand-up of the agile world supports an open sharing of the activity and next steps of all team members. Accountability is individual and well as team based, as is responsibility.

There are many ways to get things done and no set of guidelines can simply be applied to the unique circumstances of any organisation. Unlike systems, these ways of working cannot be implemented to a preconceived plan. These things take time and effort to bear fruit and find the right shape and size for the circumstances. They are worthy of consideration, however and it is relatively easy to give them a try and adapt them to your needs. Easier and cheaper than a technology programme that is.

 

 

 

 

Making a start on digitalness – digital behaviours are simple but hard

~ mylesrun ~ 3 Comments

Slightly warily, I am considering a series of posts on one theme. The theme is ‘making a start on digitalness’. I am wary because I have started this kind of project before and lost momentum. I am considering another attempt for this topic. In drafting this idea as one post I became lost in notes and paragraphs and my thread became entangled. I think it is too complex for one piece. So. This might become a series.

The idea is borne from a growing sense that many teams and their leaders are peering over the garden fence at their neighbours and gazing in envy at their digitalness. In the learning world, this gaze is often directed further afield to more distant neighbourhoods. Nearby locales are more familiar and inspire less of this longing. This envy is not about technology.  I don’t see much coveting of our neighbours kit – we all have access to the technology and tools we (think we) need. It’s more of an admiration of the lifestyle.

Like anything valuable, making a start on being digital is hard and will require constant effort. I am taking it for granted that ‘being or becoming digital’ is desirable. It is possible not to try it. That route will guarantee irrelevance at some point, however. (I refer you to the inevitable YouTube “How to  do something or other” video which you did not make but everyone prefers to what you did make). So why not make a start?

If this does become a series, it will cover organising for digitalness, the culture of digitalness, working digitally and digital behaviours. This post is about the last one: behaviours. (Yes. These themes overlap – hence the entanglement).

It is also focused on making a start on digitalness not on an end state. This is because, in my experience, digital teams and organisations don’t fix at a certain point. Something happens, mainly to users, that requires a response. By definition, something has changed. This is one of the reasons why it is hard work. Like all the best jobs, it does not freeze in form and repeat.

Here are some hallmark behaviours that I believe a digital team and the members of a digital team will exhibit. These are the behaviours I would start and practice.

A digital team will:

  • Aways seek the user need – answer the “what’s in it for me?” question (the me being the user)
  • Always seek and meet the user to find the user need – there is no substitute for direct knowledge
  • Have a clear user focus – stakeholders are not front of the queue
  • Have a good sense of the business needs (stakeholders are important but not front of the queue)
  • Get something in front of users quickly (until the user has experienced it, there is no reliable way of judging whether it is any good or not)
  • Not wait for the finished article (until the user has experienced it, there is no reliable way of judging whether it is finished or not)
  • Focus on producing the minimum product /service/content from which they can learn about genuine user response (until the user has experienced it, there is no way of judging whether it is enough or not)
  • Seek data data to understand user behavior – don’t move unless you can measure (not ‘track’ – that is something else)
  • Observe – see what happens when you do move
  • Respond quickly to observations – change what you did last time and
  • Observe again…
  • Learn and want to learn – the data and the testing are all focused on improved understanding and then on an improved outcome
  • Reflect on experience – digital teams (agile teams in particular through the sprint retrospective) will find time to discuss and assess recent performance
  • Communicate frequently and directly throughout their work – Slack is a favourite of digital professionals for this reason
  • Share information routinely and openly – Slack is a favourite of digital professionals for this reason
  • Organise themselves quickly to focus on goals – the daily stand up is one of the rituals to set next steps and share recent activity
  • Seek expertise to solve a problem (and share the result) – Stack Overflow is a towering monument to this behaviour

One interesting observation as I scratched out that list: digital teams are learning teams (this is an element of the culture of digitalness which will form the heart of another post is this possible series). The focus on improvement requires equal attention to what has and has not worked, adjusting for both outcomes. Progress is made through this learning.

All of these behaviours signal organisational traits, ways of working and cultural patterns. To be properly embedded, they need those other factors to be in place too. To be true to the title, however, I think we can all start with these behaviours, individually and collectively, try them and make progress towards more effective digital working. The role of the Product Manager – the missing link in developing helpful learning technologies – is an excellent mechanism for gaining and sustaining momentum with these changes in any team.

As with all these successful digital endeavours – these things are simple but hard.

[Worthy of another post in the series?].

 

 

Stakeholders beat out users in LMS implementation (of course they do)

~ mylesrun ~ 2 Comments

I have been nursing this thought for some time now. I managed to spend a little time trying to add some structure to it and see if that helps me think it through more constructively. I belive it did.

Now, in Web 2.0 style (yes I am a traditionalist), I thought I would share it and see what that process might add.

Much is written and spoken about the UX challenges of corporate systems and their implementation. Mcuh of that has dealt with our old friend the LMS. Not much of the commentary is positive. I reckon that the structure of the vendor/customer relationship is, perhaps, the most significant factor in creating that negative sentiment. The poor user is a distant and quiet voice amongst the chorus of sales folks, solutions partners, stakeholders and implementation teams.

I have tried, quite simply I know, to illustrate that in the diagram below. Depending on the size of the organisation, more or fewer of these ingredients might be in place. There is a lot of decision making going on between the bright idea and the recipient of that idea. The needs of the organisation are studiously gathered and arranged. The system is painstakingly designed in the image of those needs. (A cynic might suggest vested interests are at play. I can see the point).

It is then, all too often, implemented at the poor user.

Learning Management Systems – from Vendor to user

LMS chain

The digital consumer market is quite different. The product creator makes the their product available as directly and swiftly to the user as possible. And that’s about it. (I recognise that I have not reflected that economic dynamics of the market here. The ad networks, analytics, optimisation and billings systems are not represented. These, however do not often impact the user value, they signal the user value in the metrics). Meeting user need is central in a fiercely compeitive market for free and paid products – attetnion is always limited, it seems. All other value flows from there.

It is much easier to design a tool a user wants to use when those layers of corporate interest are absent. Hence the universal preference for consumer tools such as Google, Twitter, YouTube, Wikipedia etc. as Jane Hart reminds us annually. In fact, when those layers of interest are present, I would argue that a product is not made for a user. It is made for the customer. That is where the invoices land after all.

Meanwhile users vote with their clicks and swipes and adopt the consumer tools that have become so familiar to our daily lives, at work and play.

What do you think? Does the diagram look familiar? I am minded to pursue this line of inquiry, so any steering thoughts would be welcome.

 

An LMS for the open web? Not for me, thanks

~ mylesrun ~ Leave a comment

Yes. This is another post about the LMS. A perennial feature of any learning commentators blog. I return to theme this week following a call with Don Taylor about leading a session at the Learning Technologies Summer Forum on designing good user experiences for digital learning. Something practical about good and bad practice is required. As I turned the theme over in my mind in drafting some talking points, I realised that I was essentially listing reasons not to use an LMS. Yes. This is that kind of post.

Since landing on planet L&D, I have tried to understand why nothing like the Learning Management System and its raison d’etre, the eLearning course, exist on the open web. In the roughly twenty years of evolutionary experimentation in the venture capital funded laboratories of the web there has been no meaningful sighting of an LMS-like product or service. If these tools are the best of the available solutions to the learning potential available online, then where are the public equivalents?

Similar services do exist to make courses available on the web (or course like packages of learning content). Masterclass is a really interesting example of the type – an explicit course provision product with closed, commercial access to exclsuive courses. This makes sense, I suspect, to provider and learner alike. It is the closed part that works best here. Register for an account and pay for the course. It’s a very simple, paid access LMS. The value for the payment is access to the course and experience. What is the user value for an open access LMS on the web, however? What extra benefit would I receive from use of that system? It certainly not search or browse – Google is pretty good for that. Recommendation is well handled via social media, as is discussion and commentary. Access to expertise is available and in large part is free, although I fancy this may change over the coming years. Of course, none of this is tracked but I don’t think LMS data is used by learners anyway (is it?).

At the heart of my LMS misgivings is basically that lack of user need. A service like that would attract little or no funding in a world where generating a large , loyal user base (i.e. millions) is the oxygen of investment. The value in the LMS is the for the learning provider: allocating courses to learners, managing access and tracking and reporting on completions. From a user perspective the LMS typically erects barriers to learning content. It then controls the experience of the content once accessed.

The gradual emergence of the Learning Record Store might shift movement in a more positive direction but I suspect it will be adopted by LMS operators as a means of dragging open content into the closed LMS domain. Open Badges also play a part in creating a location or system for recording and displaying learning achievement and activity in the wild – there is more hope here I feel as the education sector starts to consider these kinds of services. (I fear, though, that they have also been bacterially infected by the faddish application of another new buzz-tool: gamification).

Find things out. Get things done.

At one point of my BBC career I held the title of Director, Intranet Refresh Programme. The team I worked with were tasked with refreshing and re-presenting the entire corporate intranet (take a role like that with care is my advice). We had a working motto for the new product “It will always help users find things out and get things done”. This is the kind of utility value that good open digital learning tools should have too. They are designed to answer those needs as defined by the user and available at the moment of need with minimal or no barriers to access. An LMS is a long route round to the need of getting something done.

All of this is not to say that there is no value in the LMS. The idea of recording behaviour in a learning system is excellent. If only that data were then put to the use of the learner. This is where LinkedIn Learning Solutions could play a role as the place where open learning resources can be collected and reflected upon in a social context, gathering value in the user profile. Early days for this development, perhaps but there is something to pursue there clearly The utility for the user being the management of their profile and its value to a marketplace they chose to participate in.

None of this is intended to caim that there is not a role for the LMS in corporate learning. There are too many of them around for that argument to hold water. The value (and there is a fair amount to contend with), however, is for the orgnanisation rather than the user. That is why we, as users, don’t chose to use them.

 

 

 

The device is not the user – the user is

~ mylesrun ~ Leave a comment

Flicking through some conference notes this morning I noticed a quote from an event I attended last year. My notes are poor so I cannot attribute the quote. It was the 2016 version of this event. If you are responsible for it, or you know who may be, do let me know and I will attribute accordingly.

Here is what this wise person said about developing for mobile.

Think of a mobile phone as a customer, as a person, not as a device.

Reading this again, it struck me as blindingly obvious yet very helpful – a hallmark of much good advice. Short. Simple. Direct. Thank you.

As with most consideration of UX matters, a quick check of my own behaviour and expectations helps confirm the approach. There is also the simple fact that (most) devices do not work independently. They are the tools of the user. As tools, they are applied to a purpose, to the purpose of the user. Whilst consideration of how the device or the OS and software handles our content is crucial, it does not necessarily support the intent of the user.

I have been hung up on the challenge of rendering and presentation across devices and platforms in the past and have overlooked the user intent as a result. This is not an easy problem to solve. As always (and as I remind myself) the start point must be the user need. What is trying to be done? The device and presentation is, at least, secondary. As machine learning marches on, it is still useful to remember that there are organisms behind the machines.

What is, perhaps, importantly different about our mobile phones is how we personally attach to them. They are part of us and we imbue them with our selves as we use them. This brings a mobile phone interaction closer to us than with other devices. Close enough for us, as service providers, to pay extra care and attention. A dumb response on the phone feels dumber and more brutal than via the laptop browser I reckon. More care needs to be taken.

We also have some more particular needs on our phones. Time may be more pressured or more scarce, at least. We may not be sat attentively waiting to bathe in the wonder of that content. Standing, on the bus, in the supermarket, walking the dog. These are modes that require simplicity as well as brevity. At the very least,  they require choice. These are not device constraints they are the context of the user.

That context can be remarkably well defined on a phone as well. The amount of data available will vary from native to mobile app to mobile browser and from provider to provider. This data can describe a great deal about the user behind the device. To my mind any data we have needs to be handled responsibly. It needs to be put to good use or not gathered at all. The more data we hold form a device and it’s owner/user, the more utility and value we are responsible to offer. That’s what I expect on my phone, anyway.

Design for users not for learners

~ mylesrun ~ Leave a comment

This thought has been rattling around my mind for some time now. Possibly for years, in fact. It was nudged to the front by a recent debate about the merit of user needs analysis versus learning needs analysis. The LNA acronym is a foundational feature of the L&D world. It is a given. Thus, not having one feels like a high stakes risk.

To be clear, the debate I was part of did not consist of any denial of an LNA. The conversation turned around how helpful one is without broader understanding of user needs. To be even clearer, the context of discussion was the best route to researching a digital learning experience. Knowing what folks need or want to learn is crucial – universal agreement in that one. Also a universally emerging realisation hung in the air that is is not enough.

LNA is necessary but not sufficient. I think this was our conclusion. We need to know what the learning needs are but more than that, we need to know why. What does the learner need the learning for? Learning itself is rarely the goal. It is a route to another destination. Often a requisite route but not the whole deal. Think of the ocean of ‘How to..’ videos on YouTube. They are not there for the sake of learning. They help us get stuff done.

This is where a solid and proper user experience analysis offers a stronger foundation. UX, properly considered, will discover, analyse and define the entire experience that satisfies a user need. Hopefully, only one need. Or, one at a time. Moments of learning and knowledge acquisition will be in there, amongst other elements. Things like, discovery (with it’s own foundation, search), reading, watching, listening, communicating, writing, producing, clicking, swiping, sharing, commenting, saving, to name a few, are also likely to be critical to a helpful experience. These may or may not be learning moments but the learning will not happen without them. The learning will not happen without a well designed and focused whole experience – a problem solved or a need met.

Knowing how these tools and behaviours fit together will start to shape a good UX outcome. What the content is and how it can be used is likely to shape a good learning outcome within that. I think (still thinking see) that learning design (and learning designers) needs to extend its reach and start to take UX design into account. This is what is fashionably called design thinking these days. As with any good fashion, this discipline or method or way of thinking has been around for 20 years or so by now. Only more recently has it been packaged to seem like a trend. I am too old to be fashionable but old enough to recognise the value of this method throughout my (digital) working life.

Sticky is (still) a good thing

~ mylesrun ~ Leave a comment

The phrase “sticky website” feels like something of a throwback to me. I remember first hearing the phrase and debating it as a product objective when I worked in the search industry. At the time Ask Jeeves (yes, I am that old) was popular and well used but not habitually used. Search was and still is a staple benahviour for online users and a vital tool to making sense of the choices available. In this regard, a lower frequency of use search engine has a weakness to address. And so it was for Jeeves. It was a familiar and high reach product but only a habit for the few. (The search advertising industry did, however, support a very profitable business as a result).

That frequency of use metric was drummed into me early in my career in online services as result. A small increase in frequency could have a dramatic impact on the profitability of the business. Ever since, I have regarded frequency, loyalty and depth of use as critical signs of the health of a product. How often your users return (daily, weekly or monthly), how many of them come back over the period and how much they use your service (whether searches, page views, orders, applications, message or whatever per visit) are vital in assessing how useful you are to them.

We spent quite a deal of time, money and effort at Jeeves in various marketing campaigns to persuade users that the product was the equal of the competitors or, at minimum, worthy of consideration, versus them. The best of these efforts did increase reach and nudge users to gives the Butler a try. Rarely did we retain those users, however. They would try but then return to Google. The proof of the pudding being relevance, speed, accuracy and simplicity. No advertising effort could mask those experiences relative to the engineering power of Mountain View. They did not stick.

That stickiness goal is still crucial, I think and the stickiest services are those that are useful. They reward repeat and frequent use. This is one good test of the “if we build it they will come” model. That may be true (if very unlikely). Will they, though, stay around and come back soon and often enough to return that building effort.

Stickiness equates to utility more than anything else. Be wary of a primary goal to engage users. Being engaged is rarely a primary user need. I suspect that our attempts to engage users often mask the fact that there is a weak primary interest in our offer. Being useful or interesting is much more fertile ground. From that foundation, it will be much easier to be engaging, if engagement is needed at all.