6

The requirements for the CMS needed to power a new website are often treated as technical requirements, and are therefore considered the province of developers or solutions architects.

On the other hand, the primary purpose of a CMS is to enable CMS users to easily keep the content on the site up to date. As such, the CMS is just another user interface, with its own usability limitations.

Even more than this, there seems to be an argument for solving both the front-end (content consumer) and back-end (content producer) usability issues at the same time, since the purpose of any wholesale rebuild of a website is for the organisation to deliver a better experience to its consumers.

What are the pros and cons for making this the responsibility of the UX team on a project?

Improve this question

6 Answers 6

Reset to default
2

I'm not sure this can be 'solved' by a Pro and Con list being discussed. There are at least 3 aspects that should be considered:

1. User Experience

Making sure the site is usable for both consumers as well as internal people. Very important and usually the domain of UX people.

2. Technical expertise

Making sure the CMS fits into the most likely existing landscape (think analytics and support tools, CRM, marketing tools) and fulfills more technical requirements URL structure support, SEO, security etc.

3. Budget

Usually there is a budget that can have significant impact on decisions, like time, ressources and solutions available.

Bringing it all together:

All of the above are important contributers to a successful project (even the budget as it forces to focus). UX requirements shouldn't be defined by tech people. But I think it's also unrealistic to think that UX could overrule everything else.

Every team or person involved should be aware of their strenghts and add them to the project, with the UX team indeed being responsible for UX decisions in particular. And everybody in the project should feel responsible to contribute to the project to deliver the best possible outcome.

Improve this answer
1
  • 1
    It truly isn't yes/no answer, as it is the sum of the parts that makes a successful implementation. If only UX team members write the requirements, you could end up having to deal with proposals from vendors that would cause a nightmare for dev to implement. If there is a sub class of CMS that would leverage existing IT skillsets, those requirements should be present. Just as features that allows for best UX practices should be requirements. Any 1 dimensional process is going to increase project risk.
    – Charles Wesley
    Dec 4, 2012 at 22:14
1

What are the pros and cons for making this the responsibility of the UX team on a project?

Pros:

  • end users end up with a CMS tailord to their needs
  • as such the CMS is tailored to the business's needs

Cons:

  • for whatever reasons, IT execs prefer to purchase SharePoint rather than create or research decent software. Potential arguments
    • It's usually budget related (which may be true, or complete BS at times)
    • buying 'off the shelf' software passes the buck to the vendor, rather than in-house teams (CYA model of management)
    • a highly customized UI/UX for a CMS often requires a highly customized code base which may have long-term maintenance issues (I find this the one valid tech-related argument against custom CMS tools in general).

All that said, I've worked with both off-the-shelf products and built custom products and I find that the custom solutions are always a) surprisingly quite simple compared to a total CMS and b) make the end-users happy, as they actually use it.

So, my argument is that unless you need the full suite of CMS features (and, IMHO, rarely does a group need the entire bullet list of features every CMS tries to sell), that creating a custom, pared down solution can be a smart solution.

Improve this answer
1

If the client will be using the CMS to update the site, then UX should certainly have a hand in creating the content management system.

Start with an inventory of all the content types your client will be using. From that you can write up a short list (5 or 10 items) of things that the CMS needs to do. Then do your research -- is there an existing CMS that can be adapted for the job? Your dev team may have a preferred platform; ask them.

If there isn't a CMS that really matches your needs, then you'll be creating a bespoke platform.

If you go the custom route, get the client to sign off on all the required features up front. Custom content management systems often suffer from feature-itis. A way of heading that off is to agree on a short list of features before the build.

Improve this answer
2
  • 1
    I agree, though also think that feature-itis can be DUE to a laundry list of required features up front too. I've built at least 3 CMS tools where, in the end, several of the 'required features' were never actually used (in fact, in more than one case, the CMS, was never used by the client as they ended up hiring out all the updates anyways).
    – DA01
    Dec 4, 2012 at 22:09
  • +1 for both the answer and the caveat comment. The easiest way to manage the two might be to distinguish OOTB features of a CMS - available from a range of the off-the-shelf products - from bespoke features. In other words, work with the tech team to evaluate the cost vs value of the features.
    – Justin
    Jan 2, 2013 at 23:10
1

I've worked on a few projects recently where, for whatever reason, the decision was made to move away from integrating with an existing CMS and instead to design management interfaces and processes as part of the project.

This is great in theory because you have the opportunity to design something that meets the particular needs of the project. However, you do need to bear in mind that you are effectively working on two separate projects with different audiences and requirements. I've noticed that unless you have two separate teams focusing on the two areas, the admin side tends to be treated as low priority and suffers from a lack of attention to detail and the inevitable UX issues that result. Without a standard CMS, you also risk reinventing the wheel each and every time you develop a website.

Improve this answer
0

Short Answer YES, absolutely YES, take up the responsibility, but sit close to the developer to continuously review what is possible and what is not. Dont allow developer to code php to make changes. Small css changes are ok. Document all change, and test all the changes after a upgrade/update.

Long Answer CMS's although promise a whole shit load of flexibility, agility, configurability and features, dont deliver to it. They primarily depend on plugins and themes developed by a bunch of developers out there. Each developer creates a plugin/theme, based on what he/she understands best. And frankly, like any software development project many of these fail big time. The ones that pass (fast) have the following in common

  • Most probably the first one developed to solve that problem
  • The summary is well documented from the list when a search is performed
  • Screen shots clarify exactly, nicely the most important parts of configurability
  • Features are listed in a nice and clear manner
  • The plugin is being developed, fixed and bug fixed regularly

Ratings take a hell a lot of time to build, if there already have competition. A few bad ratings in the first can kill growth.

So a CMS along with the plugins that you will use needs to be understood very clearly by Experience Designers / Architects. If not, you have to be very patient and flexible to what your developer finds to use straight off. You "wont" get exactly what you need, but you will get close. Dont expect too much customization on the plugin/theme used, since with updates, you can loose your changes.

So CMS, comes with its own set of challenges. If you customize the css, on a update you need to test all those "customized changes".

If your developer does not get a plugin that you need, then you have to look at the options he may have. So you need to be close to him, not remote across the world.

If your developer changes php files, and css files. Oh man, are you asking for trouble. Since you are using a CMS for just that reason, to avoid coding right ? Reasonable changes are ok, but dont go overboard.

And trust me, small changes that architects/designers ask for can have crazy impact during updates, upgrades.

But dont shy away from CMS. The benefits surpass all the above pitfalls. For example, you can manage the content very easily, and not have a developer involved after you deploy. Visit (www.mcruiseon.com) made completely using Wordpress with Graphene theme and S2member plugin (just listing the essential plugin, there are a lot more). To understand more about wordpress as a CMS, visit here.

Improve this answer
1
  • Why -ve vote on this ?
    – Siddharth
    Dec 11, 2012 at 17:14
0

While the ease of use of a new CMS will have tremendous impact on the overall project success, I would hardly think it is the UI teams domain.

First of all, when implementing a CMS, most of the times the project will be built on existing CMS, and those have their own UI teams working on the CMS's useability concerns.

In case the project customizes and existing CMS or a custom CMS is created for the project, there are aspects of the CMS that certainly can profit from some serious UI design input.

However, all in all the strength and weaknesses of a CMS lie elsewhere, and thus do the responsibilities:

  • How adaptable and extensible is the CMS?
  • Is the system solid and reliable technology?
  • Are the features on the admin side a good fit for the company?
  • ...

I feel it makes no sense to say the UI team should be responsible for drawing up a list of requirements to the CMS, when in fact many UI concerns of a CMS are a mere implementation question and the real questions determining the choice of CMS lie elsewhere. The UI team's responsibility is to suggest customization to an existing CMS to fit the needs of the project. At the same time I think that usability concerns overall should be taken into account and addressed for an wide success of any redesign utilizing a CMS.

Improve this answer
1
  • We're talking UX, not UI. Minor point, but important. Also, I don't think the second paragraphs is universally true. I do not believe all CMS products have UX teams that are allowed to truly make the UI a better user experience. To take but one example, SharePoint. It's a product where UX is an afterthought--if it's a thought at all. The success of CMS roll-out relies heavily on how well the users take to it, an that's heavily dependent on the UX. In fact, I'd say some of your bullet points are actually UX related already.
    – DA01
    Dec 7, 2012 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.