I had the pleasure of spending last week in Chicago at Drupalcon. I was there to run a workshop and do a talk but, to be honest, I was also mostly there to decide whether it was time to break up with Drupal for good.
My relationship with Drupal is now heading towards the 3 year mark. The number of hours that I’ve contributed (unpaid, in addition to those I’ve been fortunate to be paid to contribute) are really starting to rack up. I was starting to question whether those hours were well invested and whether it was wise to invest any more. Whether in fact it was possible that my contributions might actually constructively lead toward significant improvement or whether, after all, trying to do good UX in open source is really just thrashing.
Well. We didn’t break up. It’s not all roses, but there’s hope.
The first sign of hope came in Dries‘ keynote where he identified not just usability but delightful experience as a goal for Drupal8. Frankly, I’ll be beyond surprised if Drupal8 gets anywhere close to ‘delightful’ by the release of version 8 but as long as we’re tracking in that direction, I’m pleased.
The second sign also came from Dries’ keynote where he started talking of initiatives and distributing leadership throughout the community. I think this a great idea and gives not only UX but other disciplines the opportunity to really stand up and take a key role in the community. I noticed, however, that Dries didn’t mention any specific UX initiatives, so I thought I’d share five that I think Drupal should embrace in the coming months and years.
1. increase the overall UX/Design competency within the Drupal community – help developers (who always make loads of design decisions, in Drupal-land and beyond) make good design decisions.
What does this involve?
- Making and publicising a good pattern library so that developers contributing user facing code can help us maintain consistency and enhance usability.
- Continuing to make the case for good usability through sharing ongoing usability testing and showing how, where and why users struggle to complete tasks
- Increasing the size of the usability team in the Drupal community – here we need to focus on lowering our pretty atrocious attrition rate – keeping the good people we attract rather than just attracting more people only to see them give up and leave, exasperated, in short order.
- Creating an environment that supports and encourages good design practice. More on this below.
2. Incrementally improve known usability problems from Drupal 7 in Drupal 8. Refocus on the Site Builder persona.
There are lots of known usability problems remaining in Drupal7 that it would be great to see nailed in Drupal8. In particular, a lot of the site building tools were not given as much attention as they deserve because of Drupal7′s focus on Content Creator.
At the Usability BoF in Chicago the team discussed refocussing Drupal8′s UX goals on the tasks of the Site Builder and therefore on improving the interfaces that are encountered during the core site building tasks. Regular usability testing on these tasks will also be undertaken during this cycle.
3. Improve Drupal’s ‘Out of the Box’ experience
The learning curve of death cannot continue. We can’t expect newcomers to sign over their first born child before we let them set up a simple website. We need to give them something quickly. Enter the Snowman (nee Tsunami) (see also @eaton’s initial proposal for this project).
4. Improve the experience for Content Creators
Refocussing the UX efforts for Drupal8 on the site builder leaves our Content Creators in an awkward, somewhat unloved position. The challenge remains to find a way to enable the people who run our Drupal websites day to day (and the people who can be incredibly influential in deciding whether or not Drupal is the chosen infrastructure or not) to have a good user experience.
There are several efforts in progress addressing this challenge including Project Verity (the not-drowning-tho’-equally-not-quite-waving project that I’ve been working on with the team at Mark Boulton Design), Workbench (recently released by the guys at Palantir) and no doubt many others that I’m not aware of (yet!)
It seems at this point that the fate of the content creator is in the hands of contrib not core. If you’re looking for an opportunity to really contribute to the future growth of Drupal consider this a worthy cause.
5. Make Drupal.org a better environment for creating good user experience
Nobody I’ve ever met who works on the Drupal project actively wants to create a crappy UX, but our tools don’t necessarily make it particularly easy for us to do so. Drupal.org needs better collaboration tools that encourage us to follow good process (eg. to explore the problem space and possible ideas before we start coding the first one we think of), to get the right people in the room for discussions at the right time (smart but not annoying notifications), to help drive productive, efficient, consensus focussed discussions, and to help ensure we’re all pulling together, not frittering our energy away on related projects that don’t know about each other.
This is the goal of the initiative that Randy Fay & I kicked off in our Core Conversation at Drupalcon, it’s called the Prairie Initiative (also see Randy’s and my slides on this topic aka ‘Redesigning The Issue Queue’ ).
This is where I want to spend the bulk of my ‘Drupally’ time over the coming months (albeit only a few hours a week – I’ve got work, kids, side projects, a mortgage to pay – don’t we all). I’ve got some unfinished business on the Drupal.org redesign project anyways, the issue queue is my itch to scratch (I’ve moaned about it enough) and getting this right (or at least, a little righter) seems like a fascinating and challenging project to me. Also, I get to work with some of the Drupal community’s finest. Expect to hear more on this in the coming months.
There they are – the five UX initiatives I’d like to see for Drupal 8. I’m not sure how things become official initiatives in our new Drupal 8 landscape but I imagine that if a whole bunch of us keep saying it over and over, form into working groups and start getting exciting stuff done, that’s got to be a good start. If a delightful experience is really what we want to achieve then, IMHO, this is how we get started.
The discussions around the design and user experience objectives for Drupal 8 begin to kick off and will no doubt crank up a gear at the upcoming Drupalcon. (are you coming? come to my workshop! no ux/design experience necessary)
As much as I want to see us continue the great trajectory for improving the user experience for Drupal that I think the community achieved with Drupal 7, I have some reservations about our capacity to maintain this momentum without addressing some of the structural issues within the community – effectively the environment in which design can happen.
There are bunch of topics that we can explore around this – I’ve pitched a Core Conversation for Drupalcon about redesigning the issue queue, for example. I hope I get to talk a whole lot more that during the coming months. Today I want to talk about a structure of leadership for design in the community and to propose a model.
One of the main reasons that we were able to achieve so much with Drupal 7 was because the D7UX team (which I was privileged to be a part of) were given a mandate, a bit of authority, and a clear brief. If we want to continue to take big steps with Drupal’s user experience (and we still need to take several big steps on this front if we want to be competitive and remain a viable option for a wide audience), we need to find a way to replicate this focus in the longer term.
Currently we have two UX Maintainers – Roy and Bojhan – who are both incredibly dedicated and do great work within the community to promote a better user experience. I have nothing but the greatest admiration for their resilience. There are also, increasingly and largely thanks to Acquia, more UX and usability resources available within the community.
We have the dual challenge of encouraging existing community members to become more ‘UX-y’ and attracting UX Outsiders into the community in order to grow this team. We also have the dual challenge of making many, many incremental changes that could rapidly improve Drupal’s usability (we call these the ‘low hanging fruit’), as well as considering the bigger, more hairy challenges around defining and understanding target audiences, and finding ways to create good experiences for an incredibly wide set of journeys and requirements.
In order to make it possible for such changes to happen, I propose that the Drupal UX Community requires three types of leadership: A UX Maintainer (or two), a Design Pattern Library Maintainer and a Designer in Residence. Let me describe these in reverse order.
The Designer in Residence: This person is tasked with addressing some of the Big Design Problems – the more strategic/structural problems that will impact Drupal’s long term ability to be a compelling choice for organisations in the coming years, that will look at the challenges of multiple platforms from a UX perspective, that will look at target audiences and optimising out of the box experiences/on boarding. This role will benefit from having an ‘outsider’ perspective. This person works with the UX Maintainer(s) to take great strategy and turn them into achievable tasks. This person shares their work with the Drupal community and the UX Community at large, along the lines of what we did with D7UX. They are Drupal’s UX ambassadors to the outside world, they help draw fresh UX talent into the community. They conduct generative research. This is a role that could be rotated every six months or so, getting fresh eyes on the big problems would be fantastic. We could invite people we’d love to work with to take this role from time to time.
Design Pattern Library Maintainer (or librarian, if you prefer): this person leads and coordinates a project to develop an excellent library of design/UX patterns that can be applied consistently throughout core and into contrib. They work with the UX Maintainer(s) to ensure that new patterns are applied/communicated and they take requests from the UX Maintainers to develop patterns that are missing or confused. They might conduct A/B testing to establish optimal patterns. They take work from the Designer in Residence and turn them into patterns as a part of the process of making big design ideas achievable.
UX Maintainer(s): work with the overall community to get the day to day UX work done. Help push things through the queue, coordinate and communicate usability testing, incrementally improve the UX of Drupal by knocking over the ‘low hanging fruit’ improvements, help educate and train up members of the community to be more UX-interested and UX-aware. Works with the Pattern Librarian to see that patterns are implemented well across core and contrib, works with the Designer in Residence to make Big Ideas achievable.
I believe that each of these roles should have clearly identified goals for a defined term (say, six months?) so that they can see and show what success looks like and be able to get useful feedback on the work they’re doing.
I also believe that these roles should be funded positions. I believe that one of the best ways an organisation can support good User Experience in Drupal is to put their hand up to offer sponsorship for a part time role for six months.
If we do this – get the structure in place for good design to happen, and create funded positions to make working on Drupal a viable alternative for good UX people who have so many other competing demands on their time at the moment – I am very excited about the prospects of Drupal’s User Experience in the years ahead.
Something significant needs to happen in the way we do Design and UX in Drupal – along the lines of D7UX but more embedded and integrated and more sustainable. We won’t achieve what we need to by making lists and prioritising them. We’ve still got a lot of big problems to solve and a lot of hard graft to do.
What do you think – might this help make it happen?
Every now and then I’m asked for advice on getting started as a UX Freelancer. I tend to say the same thing most times, so I thought I’d put them together here for future reference and for the benefit of anyone else who’s thinking about making the jump (or who has made the jump and wonders whether we see the world the same way….)
I offer no guarantees about any of these tips, all I can say is that they have worked for me and that they form the basis of my ongoing approach to UX Freelancing. Some of these I’ve known since the beginning, some I’ve learned, most often the hard way.
In presenting these tips I am speaking particularly to those people who think of freelancing as I do – working for multiple clients on multiple projects (not always at the same time) in the course of a year, not taking a series of long term full time contracts.
If you are also a freelancer and would like to offer additional or alternative advice please do feel free to add your comment below.
1. Why are you doing this?
Why are you choosing to freelance? Is it for a better balance between work and the rest of your life? For riches and fame? To have more control over the work you do? There are lots of reasons why people choose to freelance (some of the more or less based in reality!). Think about why you’re doing this and then think about what decisions you’re going to need to make in order to achieve this outcome.
It is crazy how many people start out freelancing imagining spending Tuesday afternoons in the local cafe reading – because they can. Then end up working more hours than they’ve ever worked in their life and never going anywhere near a cafe or a book.
What are your ‘project goals’ for becoming a freelancer? Make some ‘golden rules’ that will ensure you can achieve these goals. You’re in control now, so be proactive about it and make life/work what you want it to be.
2. Finding work: Build a good network, do good work
The best way to get good work is to make friends with other UX Freelancers who are good, get busy, and want to find a good home for work they can’t do.
Actually, I don’t get much work this way personally, but I pass on quite a bit and see several other good UX Freelancers doing similar.
The *really* best way to get good work is to do good work, and to have other people talk about your good work to others who may wish to hire you. I think this is how I’ve gotten most of my work over the years and I hope it continues this way.
(You may have noticed that I do not recommend contacting recruiters, not even for ‘safety’ for your first job. All evidence I have seen indicates that you are unlikely to get good/interesting UX work as a freelancer from recruiters and you are more likely to be paid less than you’re worth.
Although, I have also heard evidence that recruiters over charge for UXers, this has only ever come from someone looking to hire, not be hired. If the only way you can get work to start your freelancing career is through recruiters I’d be tempted to re-think freelancing altogether).
3. Be visible.
Being a secret freelancer is not a good strategy. There are several different ways you can be visible, choose the one or more you find most comfortable. Options include but are not limited to: write a blog, be active on Twitter, speak at conferences & other UX events (large and small), attend events and talk to people, contribute answers on UX related email lists, forums, Quora etc.
When being visible, the best way to do so is to contribute to the body of knowledge of your UX community. We don’t really want to hear how fabulous you are (I’d rather hear that from your previous clients or colleagues). We would like to know what you’ve seen that’s interesting lately, why it’s interesting, what you learned from a project etc.
You don’t need to be a massive self-promoter. I’d advise against blatant, unhelpful, self promoting, but being visible (particularly being digitally visible, Google-able with positive and relevant search results ensuing) is important.
I find that by sharing my work, my process and my learnings (as much as I’m commercially able to) I negate the need for preparing and maintaining a CV or shiny portfolio. Your mileage may vary.
4. Position yourself.
If I know what kind of projects you really like (and are really good at doing) and I hear of a project like it, I will think of you immediately. Apply the same approach to positioning yourself as you would to your projects.
Don’t try to be everything to everyone, think about the kind of work you’d rather do and let people know that’s what you want. You might end up doing all kinds of different things, but you’ll become a go-to person for your particular niche, and that way, stay top of mind.
5. Don’t take work you don’t really want to do.
It is really hard to say no to work when you’re freelancing. Really hard. It takes a while to believe that work will actually come to you when this project is over and that you will be able to pay your rent/mortgage etc. Don’t panic and take a project you really don’t want to do. There are two reasons for this:
Firstly: It’s really hard to do good work on a project you don’t care about. The quality of your work is critical to your future success as a freelancer. You can’t afford to do a bad job (not if you can possibly avoid it).
Secondly: It is a little known fact that the universe conspires against freelancers who ignore this tip. Just as you’ve become contractually obligated to work on the most boring, tedious project ever for weeks into the future, you will be offered the Project Of Your Dreams. And you’ll have to turn it down (or, at least, you should – skiving out on projects at the last moment or worse, when you’ve just started, because you’ve got a better offer is pretty bad form). I can’t begin to tell you how awful this feels.
6. Don’t overcommit.
See above re: it’s hard to say no to work. Also, projects always take longer than you think they’re going to. This can lead to working every hour god gives you. This is not good.
It is not sustainable to work ridiculous hours indefinitely. You will probably have to do it sometimes, don’t make it a way of life. Your mental health, family/social life and the quality of your work will all suffer. Even if you say ‘screw my mental health and family’, the quality of your work is the indicator of both the volume and interestingness of your future work. Don’t do anything to jeopardise that. (Like, say, working at 3am on a Saturday morning when you’ve already clocked 80hrs or more that week).
Try to over estimate the time you’re going to need to do a project (then you may just get it done in time) and do allow yourself some downtime to remain sane and relatively fresh.
7. Don’t over complicate the legal/financial aspects.
When you’re starting out (in the UK at least) all you need to do is register as self employed. You don’t need to register for VAT immediately (although it does feel weird charging no VAT and clients do ask questions), you don’t need an accountant or a limited company immediately. Take it easy and scale things up as you need to.
Do make sure that you are tracking your time and your invoices properly. There are millions of options for this. I have used FreeAgent since I started out because it allows me to do estimates, invoices, time tracking, maintain a client list, and automates a lot of my tax and it comes with a pretty delicious user experience. It’s not the cheapest option but it has worked well for me (and now that I have an accountant, they can log in via an ‘accountant login’ and get everything they need automatically). Paired with an iPhone app called Out Of Pocket which integrates to FreeAgent and lets me capture my expenses on the fly, I’m much better at my accounts than I ever thought possible. Accounts are almost fun.
Except for the tax-paying bit. (On that note, don’t spend your taxes, or you’ll find tax time rather painful. (Speaking from experience here)).
Get Professional Indemnity insurance. Hopefully you’ll never need it. Some clients will require it.
Don’t stress out about contracts, stress out more about choosing the right clients and managing their expectations by communicating well throughout the project. You *really* don’t want to get down to enforcing a contract and in most cases, the cost involved in pursuing things legally outweighs any financial benefit.
I probably shouldn’t admit this but the only time I tend to sign a contract with a client is if they have one they want signed. Most projects I do without a contract. I work hard to make sure my client understands how we’re going to work together and what they’re going to get – almost invariably this changes as we get to know each other and our project better.
If things start feeling dodgy, in any way – stop working and start talking. Invoice regularly, make sure you are going to be paid. If you don’t think a client is going to come good with the cash, ask for a payment upfront (again, this is something I do rarely tho’ I know it is standard for others), and put them on short payment terms. Or better still, don’t work with them. Writing off invoices is very depressing.
Be aware when invoices are overdue and don’t be shy about chasing them up with a friendly but timely email.
In my experience, if you choose good clients, you don’t need to worry too much about getting paid.
8. Value yourself appropriately.
When analysing the recent UX Freelancers Rate Report data, the thing that most struck me was how apparently random our dayrates are.
A lot of really good people are charging a lot less than they should and a few are apparently charging more than they’re probably worth. Now we have some idea of what we’re all charging – be informed and charge yourself out appropriately.
Once you’ve set your rate, keep track of how many people simply accept it and how many wince and complain at the rate. (Exclude recruiters from these calculations). If more than 1 in 4 wince, you may need to lower your rate a little. If fewer than 1 in 4 wince, you may need to put your rate up.
9. Don’t do freelance work and look after small children simultaneously.
See above re: overcommitting. I’ve tried it. It’s horrible for everyone involved (you, your client, your kids). Get childcare (and curse that it’s not a deductable expense).
10. Take the lead.
When I think about the (thankfully only occasional) projects I’ve worked on that didn’t go as well as I’d like them to, it was almost invariably because I was looking to my client to take the lead, to tell me what they wanted to do, and then for me to act on instructions. In every case, whether the client *thinks* they know what they want or if they haven’t a clue, you should be proactive in setting out the process or project approach that you think will give the best outcomes and make the best use of resources.
Your client is almost always paying a premium for your services as a freelancer – this may be because they’re desperate and this is the only way they can get the UX work done, but hopefully it is because they are looking to you to bring some specialist skills to their team. Give them their money’s worth and make the most of your time with them by being proactive and helping them use you well.
So, that’s it. Almost everything I’ve learned about UX freelancing that I can remember today. Let me know how much of this resonates with you or not, what I’ve missed (I know there’s lots!)
This week sees the release of Drupal 7 – a big event for the Drupal community and also individually for myself and the team at Mark Boulton Design as we worked together with the community on the D7UX project which aimed to significantly evolve and improve the user experience and usability of Drupal.
I’d like to start by congratulating the community on coming together to once again significantly improve Drupal and give it all away for free. Let us never forget what an amazing thing open source software development is.
The last couple of years have been interesting both as a participant and as spectator (because I do feel as though I occupy both of these roles, as incompatible as they may seem… many others who have attempted to participate as a designer in an open source community can probably empathise). It has been exciting to see Drupal embrace the idea of design and user experience as vocally and visibly as it has. I think this visible and actual (financial) commitment has really paid dividends although – as ever, the numbers will ultimately tell that story.
There have also been some fairly significant frustrations. I hope that as we raise a glass to celebrate the release of Drupal 7, we also take some time to resolve to think about how we can make design work even better in this community (and all open source software communities).
To that end, here are some challenges I’d love us to attack:
1. Designing participation for designers
Issues queues and IRC are the traditional communication environment for open source development. If you want to be involved in design for an open source community that’s where you need to be.
During D7UX I was there all the time. Since then – not so much.
I have no idea how people keep track of what’s going on in the issue queue – on it’s own, it doesn’t work (unless I’m doing it all wrong?). You need people to ping issues at you in IRC (or elsewhere) to make sure you know what’s going on.
Being on IRC 24/7 is just not an option for me – much of my work is done away from my computer (sketching, running workshops, doing research) and when I’m at my computer I need to be focussed – IRC is not good for focus.A culture of participation that is designed around IRC and the issue queue is not compatible with getting designers to participate in design problems at the right time (that is, toward the beginning, not at the very last moment).
We need to come up with a way that is more proactive – that goes out an pings designers who might be interested in participating, rather than relying on them coming across something in a timely manner.
Yes, this means changing the way the system works because designers have special needs. Do you want good designers to participate in a meaningful way?
Deal with it. (And yes, we’ll help you design this change. Happily.)
2. Recognising participation for non-developers
At this point I’d like to give the accessibility team, the security team, the documentation team a shout out and congratulate them for their brilliant work on Drupal 7.
I regret that there are probably more people whose lack or recognition I am currently perpetuating, because in Drupal, if you’re not listed in the commit message, your contribution, literally, doesn’t count.The Drupal community subscribes to the saying ‘talk is silver, code is gold’ and there’s been no better demonstration of this then the various thank you pages that have been posted recently using the list of commits to Drupal 7 as an indication of the amount you have contributed to the project.
This means that someone who, in a few hours here and there, submits a handful of minor patches is more recognised than someone who spends hours every week taking all kinds of flak from the community trying to educate them on the importance of accessibility, or explaining a design pattern, or reviewing Drupal.org and organising the design and content work required in preparation for the product launch. For many of us (and in fact, probably for developers as well) there is a whole lot of thinking and talking and sketching and research that happens before any code is written – actually writing the code is (sometimes) the easy part.
We need to change this culture. We need to make non-code contributions much more visible and recognised. (And this can’t be achieved by simply sitting in IRC 24/7 having a presence and ‘gaining respect’).
Yes, again – people who don’t write code have special needs.
If we want more of these people we need to change the environment because these needs will not change.
3. Maintaining coherence without ‘owning’ design
Design ideas in the Drupal community need a maintainer, just like core or a module or any important piece of code.
How is it that the Drupal.org homepage can be radically changed within the space of a few hours without any consultation at all with the people who did the research and design work behind it? Or even any adherance to the style guide that accompanies it. (Not to suggest that a style guide is capable of providing specific guidance for every possible outcome).
Of course design needs to evolve as the community and product needs evolve. Of course designers need to respond to the competing requirements of end users, developers, and everything else. This is not about design being precious and permanent.
Just because you *can* change the design, doesn’t mean you should be allowed to – not without a ‘maintainer’ of the design giving approval or at least feedback that you can then act on or against. There is no point investing in good, thoughtful design and then not making any effort to preserve it. Especially when the designers who have done the work are around and more than happy to contribute.
This is not about ‘special needs’ – this is about crediting designers with some ownership over their own work. Not wholesale ownership, just a little. Enough to warrant the opportunity to participate and be consulted.
4. Design leadership in open source communities
Reliance on the current model of participation (issue queues and IRC) means that leaders in the design/ux community currently emerge by virtue of presence – being available on IRC and active in the issue queues. You can’t ‘commit’ design in the same way that you commit code, so you can’t build your reputation in many other ways than being there and participating. (The relatively recent movement toward designed distributions is possibly starting to shift this a little, although still relies on code).
This is good because it means that these people are passionate about design and UX in Drupal and show commitment to the project. It is bad because it naturally privileges people who have more available time and who tend to be less experienced. Designing for Drupal and in the Drupal community is a challenging prospect. UX and product design considerations impact an ever increasing audience who rely on Drupal for ever more critical capabilities.
We need to find a way to allow experienced designers (and in this I include UX/Usability people) to play a proactive, leading role in shaping design in the Drupal community at a strategic, not just tactical level, without requiring them to be on IRC every hour of the day and night and having to respond within minutes.
It is not an acceptable response to say (or think) that there are no designers or usability people out there who are interested in participating or that they just don’t have what it takes to stick it out. There’s no shortage of people who would willingly contribute time and expertise and many who, over the years, have attempted to contribute much more.
I’ve been reading a lot about change management lately and one of the keys to successfully making change is making the environment conducive to the behaviour you want to achieve. That’s our challenge moving forward.
I think this is possibly the most important consideration in my list.
5. Defining our value proposition
I’ve said it before and I’ll no doubt say it again – you can’t meet the needs of the wide range of activities of the incredibly broad Drupal audience in the one interface. Not well. Drupal 7 via D7UX is – hopefully- a better experience for both newcomers, content creators and, in some ways, developers. It is nowhere near an optimal experience for any one of these groups, because they have conflicting needs, behaviours, and characteristics.
Drupal is just like most of the clients I’ve ever worked with who are seeking growth – struggling with their value proposition. I’m not saying we need to abandon any one of our audiences, but we need to address them in different ways, not through one incredible interface. Thankfully I’m now able to stop just talking about this and actually do something through the Project Verity theme work Mark Boulton & I are doing together. (It’s really starting to come together now – stay tuned!) We need to define a UX strategy for our key audiences and then optimise the environment for people to design most effectively for them. We need to do that before we start designing Drupal 8.
It has been a great honour to have worked on the D7UX project and the Drupal.org redesign and, through that, to have had the opportunity to work with some of the passionate and talented people who contribute – in many ways – to Drupal, it’s current and future success.
I look forward to having some kind of continued involvement in the community – exactly what that is will depend on how seriously the community takes some of the issues I’ve outlined above. Regardless of that, I’m here – you want some help, you know how to find me.
Cheers Drupal – Congratulations!
Here’s to the success of Drupal 7 and beyond.
I’m thrilled to be attending Drupalcon Chicago in March – I’m even doing a pre-conference training session called What Users Want that I think will be really fun and which is focussed on teaching people to do what I do (UX research and design), especially those who have never done it before (managers, developers, marketers, I’m looking at you!).
Want to talk about this stuff in person? I’d love to see you at Drupalcon. It’s a great conference and, with Jared Spool, Clay Shirky, Mark Boulton, Jeremy Keith, Russ Unger, Karen McGrane and more coming to share their experience, it’s almost a design conference with added Drupal – hooray!
My name is Leisa Reichelt. I am the Head of User Research at the Government Digital Service in the Cabinet Office.
I lead a team of great researchers who work in agile, multidisciplinary digital teams to help continuously connect the people who design products with the people who will use them and support experimentation and ongoing learning in product design.
If you're interested in working with me or would like to talk more please email me