What's your idea?
The community is doing an amazing work maintaining, improving and adding to the *.d.o infrastructure. But it is very much feature focused and where features often are looked at and implemented in isolation and from a technical point of view.
*.d.o has, according to https://drupal.org/home, a cool million users. To provide a great UX for all of them and where they can focus on getting things done is without a doubt a challenge. A challenge I feel isn't really being taken completely serious.
To fix this we need a proper UX strategy to guide us both in the planning and preparation beforehand and during the implementation of improvements and new features.
What are the benefits?
It will allow us to much better understand how users are using *.d.o, where we have room for improvements, how it can be improved so everyone can better focus on getting things done rather then pogo-sticking around trying to figure things out.
It will also give new users a much better impression of *.d.o, allowing them to quicker find and understand the information, resources and tools they are looking for.
Done right it will also give us invaluable feedback and understanding about needed improvements to Drupal core and contrib too. The shear size and complexity of *.d.o is in itself a litmus/benchmark test for what can be done with it.
What are the risks?
The only risk is short term as it will take some time to do the needed research and development of the UX strategy. Once that is done, there are only benefits to come.
How can we measure the impact of this idea? (metrics)
This will actually be very easy to measure as the Drupal community is very passionate. We will both see it in specific discussion and in project focused collaborations where users notice that they get more things done with less confusion about how to do it.
Who directly benefits from / will use this improvement? (target audiences)
The primary target group is everyone that currently use *.d.o as they will get a better user experience and be able to focus on getting things done.
Secondly it will be every new user who will have a much lower learning curve to where to find what they need and how to use it.
Thirdly it will also have an impact on anyone that is researching if Drupal is the right fit for them. They will much quicker find what they need to base decisions on. Just the greatly improved UX will in itself make them much more positive of what Drupal is and can do for them.
Lastly, the UX strategy for *.d.o also needs to be coordinated with the UX/usability team and strategy for the Drupal project itself. This because some improvements needs to be made to Drupal core, some to contrib projects and so on. The UX needs for both *.d.o and Drupal itself are not exclusive, they are very much co-dependent. Thus a collaboration really is a win-win.
Are additional resources available for discovery/implementation? (volunteer effort, financial backing, etc.)
I'm sure there are a lot of people in the http://groups.drupal.org/usability group that just wait to help out with this. I'm one of them.
Comments
This seems like it would be
This seems like it would be more material for the Drupal.org Content Working Group.
Not really. It is about the
Not really. It is about the countless UX problems we have with the whole of *.d.o.
--
/thomas
T: @tsvenson | S: tsvenson.com
Yes. Which is exactly [part
Yes. Which is exactly [part of] what their charter covers. :)
Strange place for it?
Thanks for pointing me to that Angie. But to be honest it makes me quite confused about UX being part of the content WG. UX is about much more than that.
--
/thomas
T: @tsvenson | S: tsvenson.com
@tvenson I do understand the
@tvenson I do understand the confusion. The content working group, focuses primarily on content. It does not focus for example, on community tools like the issue queue. The role of strategic (UX) oversight is the DA, therefor this proposal placed in the 2014 plans seems appropriate.
@webchick Let me know if this is incorrect, but it was my understanding that although the content group has much to do with the overall UX, it does not cover all parts of the experience, which is what this proposal is about.
I am not sure I actually understand the proposal though. It's unclear what steps are involved in creating a strategy, how it will actually benefit d.o. Nothing about this is small impact, both in resources of figuring out and establishing the actual strategy.
Given that from my point of view, the DA/D.O group is still struggling immensely on the tactical part, with little to no UX resources available - having actionable parts to this proposal would increase its success to become part of the roadmap.
Hi @Bojhan and thanks for
Hi @Bojhan and thanks for taking time to discuss this.
I agree that the idea does lack actionable items and would very much value your input on that.
A couple of things I believe is relatively easy to start with and that should be useful resources quite quickly for the community is:
A set of generic personas
This would be personas based on typical visitor and user roles on drupal.org. It would include, but not limited to:
Then whenever we need to make changes to our sites we will be able to use these personas to better understand what roles will be affected and what they expect to get out from it.
UX review guide
This would be a logical next step after the personas. This guide will be used as early in the change process as possible. Preferable before any changes have been made.
It will show how to select the suitable personas and how to use them to understand for example the workflows different user roles expect and thus be able to identify possible UX problems so they can be addressed.
Of course a complete UX strategy includes a lot more, but these to would be relatively easy to start with as well as implement in our processes.
--
/thomas
T: @tsvenson | S: tsvenson.com
I like the idea of
I like the idea of 'personas', as we could then add a field like 'audience' to new nodes, allowing users to select an audience. This could give us a new field to add to the search, and/or the site search could be adapted to favor items with an audience targeted at personas the searcher has. This would prevent site builders from getting bombed with code questions when searching for issues.
This is one of those ideas
This is one of those ideas that sound great in theory but fall down in practice, especially in a big crowd-sourced site. We already have personas (or roles) in the handbook pages and the tagging is so inconsistently applied by different people that I think it's worse than useless. It's one of the things I'd like to get rid of because of the way it adds cognitive noise without much value.
Content, Tools, Infrastructure...
A huge amount of Drupal.org is text and images written by humans for other humans -- and in that sense, I think of it as content.
The DCWG's charter means that we're primarily focused on certain kinds of content on Drupal.org -- the documentation section, the issue queues, and bits like that -- are outside our domain. The issue queues are an interesting example: they're full of content, but it's user-generated content outside the purview of drupal.org editorial process. The act of working in the issue queue is much more complex than (say) reading a case study, and its UX needs more and different attention on the software side.
But the content itself is tangled up in the 'UX' of using Drupal.org, just as the software that drives it is mixed into the act of reading and maintaining the content. The DCWG definitely has its hands full at the moment, and I don't want to suggest that we should be tackling anything more, but I'd hate to see a UX strategy and a content strategy emerge in isolation. If there are conversations coming together I'd love to set up lines of communication to make sure we share useful information and insights.
Agree 100%
I agree 100%. I’m all in favour of these communication channels.
I also want to point out that Constantine’s Usage-Centered design process that I discuss below does integrate a Content Modelling stage. I highly recommend it for the DCWG’s purposes and as a possible way to integrate the UX aspects that you mentioned.
Also, you mentioned the Issue Queue ‘issues’ – for anyone interested in this topic, @tsvenson and I prepared a fun talk at Drupalcon Portland that you can see at Living and Working in Issue Queue City" - and this talk also touches on UX Strategy.
Michael Keara
User Interface Systems Architect,
The User Advocate Group
I think it’s absolutely
I think it’s absolutely critical for ‘Drupal’ to have a clear handle on UX Strategy if it is to continue to be successful. Having said that, it’s worth looking at what is meant by ‘UX Strategy’ and also what is meant by ‘Drupal’.
UX Strategy is a way in which the goals of users can be reconciled with the goals of the organization behind the website/app. So right off the bat, we can see that there are many places in which UX Strategy can be applied to ‘Drupal’.
Even with this preliminary breakdown we can see that there can be different UX Strategies for different purposes. Not identifying these channels clearly can make for confusing discussions.
I don’t believe an emphasis on personas is a good place to start a Proper UX Strategy. We need to dig deeper than that and approach the problem by identifying groupings of user intents or task objectives. (I would like to use the term ‘Roles’ to describe this approach but sadly that term is quite buggered up by applying it to describe set of permissions. A given user can constantly change ‘Roles’ but their permissions rarely or never change.)
Certainly this is related strongly to Content Strategy. But UX Strategy also has to provide meaningful guidance to the ‘formal’ or coding aspects that developers deal with on a daily basis. Our current approach leaves developers to solve many critical UX-related problems in isolation and that tends to keep Drupal UX evolution perpetually at the tactical level, generating countless tactical issues.
A UX Strategy is like a skeletal system. It provides deep and critical support for the entire system. Creating a Proper UX Strategy for Drupal is not a small matter. But the alternative is that, in time, Drupal will collapse under its own weight.
As I write this I am wondering if this is the best forum to be discussing these ideas. If I came at this post through the Usability Group context then maybe it is. If I came at it through the 2014 Roadmap Brainstorming context then maybe it’s too much detail for that purpose. But that again underlines the need for a UX Strategy for d.o doesn’t it?
Given all that, I think a good starting action is to identify/create somewhere on d.o. to accommodate discussions and proposals about UX Strategy in all its various dimensions and where we can tackle this sizable problem without being burdened by the endless tactical issues. I believe that if we can get over that hump the tactical issues will eventually begin to diminish.
Michael Keara
User Interface Systems Architect,
The User Advocate Group
How go find out about the roles then?
Could you expand on this a bit? How to dig deeper? What kind of research and analysis is needed? Wouldn't a pragmatic set of personas be a good place to start and find out about a higher-level grouping of tasks?
@User AdvocateI see where
@User Advocate
I see where you coming from. Yes, if we where to look at personas from a purely UX design and strategy perspective, then I agree with you.
However, if we also look at personas as an educational tool for the community I believe it could provide a game changer.
After all, there are quit a few of us within the community that have been barking the UX mantra for many years now. Yes, we have had some progress and a few wins. It has helped Drupal to become more user friendly too. But, looking realistic, UX is still not taken seriously enough or applied early enough in our processes.
Also, UX is still kinda treated with some suspicions by many, even that that our ideas slow down getting things done. It is a complex beast and it takes time to really understand it, what it can do and why it is important to spend resources on it.
Exactly, and this is where I believe that the persona tool very well could be the one to help us start making an important change here.
A set of well defined role oriented personas would include both a general role description and good definitions of their task objectives. A guide document can then describe how to apply them and also how to discover and extend them for new drupal.org features as well as Drupal Core and contrib.
It could help us begin to bring down the wall that over the years have been erected and now effectively separates drupal.org and Drupal. A wall that has made them into two separate and quite unrelated entities.
At the end of the day, drupal.org is built on Drupal - It is depended on Drupal to function.
All the challenges we have maintaining and running drupal.org stems from what features Drupal provides. In that aspect drupal.org is no different from any other site it is used on.
But we are in a unique position. We maintain both drupal.org and Drupal. In many cases it is the same people even. Still we treat them differently. Another aspect that is unique and separates us, from other sites, is that the community goals and objectives are all focused on improving and spreading the use of Drupal.
So, personas done right right can very well become the tool to help us bring down the wall. Allow us to instead build bridges for creating awareness, understanding and education about our UX needs.
Its not "the" solution, but it can be the start towards it.
--
/thomas
T: @tsvenson | S: tsvenson.com
Could be a Perfect exercise for DrupalCon Prague
One thing more. This could be a perfect exercise for DrupalCon Prague.
Not just to work on creating these these persona roles, but also conduct a survey amongst the various roles that attend. Ask them relevant questions about what their normal roles are, what they come to drupal.org to do and so on.
--
/thomas
T: @tsvenson | S: tsvenson.com
The importance of precision in terminology
@tsvenson and @yoroy I’ll try to answer both your comments/questions here.
I believe precision of terminology can make or break a complex undertaking such as forming a UX Strategy for any project. This goes tenfold for projects such as *.d.0. and the Drupal project itself. So I want to articulate what I believe are rigorous definitions for ‘persona’ and ‘role’. I've used these definitions on many successful projects from both a design and development point of view. The definition of ‘role’ that I use has its roots in Object Oriented design so it may be unfamiliar with people who haven’t had such experience.
For expediency sake I want to refer to an excellent paper, User, Roles, and Personas, by Larry Constantine, Chief Scientist at Constantine & Lockwood. I highly recommend anyone who is serious about UX strategy, and usability in general, read his document.
Constantine draws an important disctinction between 'user-centered' methods and 'usage-centered' methods. Using this distinction he points out the corresponding difference between personas and roles: “personas describe users while user roles describe relationships between users and systems”. By ‘systems’ we mean the technology behind applications and/or web sites – so we can see how that applies to both *.d.o and the Drupal project.
What this means is: personas are extremely useful for helping people (e.g. designers and developers) get a clear vision of a user as a real person rather than a pure abstraction. This can be useful for motivating people to care about 'The User', however fictitious their representative persona may be. It can also be useful as an aid for grasping how usable a design might be as we project ourselves into a mindset of a given persona. But, as @LeeHunter points out, personas can add "cognitive noise without much value" if used inappropriately.
More importantly from a UX Strategy point of view, these imagination tools don’t offer much concrete guidance or direction for designers and developers when it comes to determining precisely what the essential components of an interface should be (I call this 'screenware'). Those insights come from studying the relationships of the user to the system – i.e. by studying their roles.
Constantine says “Compared to personas, user roles are a more technical and formally structured model.” It is more technical because the methodology comes from a technical environment and is aimed at expediting the design/development process. We should take note of that especially when (as you said @tsvenson) “UX is still not taken seriously enough or applied early enough in our processes.”
I believe the extent to which developers can take UX seriously is directly related to the degree to which actionable guidance comes from a UX design process and thus the extent to which it expedites rather than hinders the development process. Anyone who is active in the Drupal community, especially developers, should care a lot about having such a UX productivity enhancing design process in place.
Constantine’s paper outlines a proven methodology for doing precisely this. He breaks it down to 3 distinct models:
Personas enter the picture at the end after these modelling processes have established such factors as the primary roles, usage frequencies, and importance to business success.
@tsvenson, I understand what you’re saying but it strikes me that educating the community about the value of UX (via personas or otherwise) is a quite different goal from forming a UX Strategy. Certainly it can be part of a larger undertaking to improve all aspects of Drupal but I think it's only peripherally applicable to what you posted about originally.
I'll just say once again that the precision of our terminology directly affects our ability to solve problems effectively. Given the rigorous definition of 'user roles' presented by Constantine I'm hoping that more of us here in the Drupal community will begin to see how we are wasting a critical conceptual tool by applying the term to refer to sets of user permissions. My suggestion is that we consider using the term 'user groups' as a perfectly adequate term for 'sets of permissions' and thereby release the term 'role' for the full power that it possesses.
Finally, If anyone is interested in more thoughts on UX Strategy as it pertains to Drupal I invite you to also check out these links on my blog:
Michael Keara
User Interface Systems Architect,
The User Advocate Group