Hello, glad to see you back! In the last blog post I introduced the key design drivers and the high-level design concepts for a new “Graphene UI” for SDL Tridion Sites. I also explained how it could address the workflows, needs and requirements of agile marketing teams running global web projects.
For this post, I will dive into the design concepts through which we aim to address the challenges and needs of our tech-savvy implementation and expert user community. So, let’s have a look into BluePrinting, Content Management, Content Mashups and Channels, and how to configure and set up Tridion DX in the new Graphene UI.
BluePrinting makes SDL Tridion Sites as powerful and successful as it is, so we would like to expose and integrate it in a much more pervasive way. The example below shows a small example BluePrinting hierarchy in it's current outlet in the UI, the BluePrint viewer. It allows advanced users and implementers to define and manage a large number of content publications, including their mutual relationships to each other.
Our design direction takes this current visualization approach and embeds the BluePrint hierarchy more seamlessly into the context of work, right next to the content a user is editing or managing. An implementer might need it when setting up and configuring content publications, an editor while deciding to either edit the "parent" of an article component in a lower BluePrint level, or to better localize it and break the inheritance. For both cases we integrated the BluePrint hierarchy as as an alternative “view” on the list, so you can display any selected item in it's BluePrint context at all time.
From an implementation perspective, we think that the exact visualization of the BluePrint hierarchy should remain flexible through the use of modern, interactive, browser-based visualization methods and frameworks so it can be extended and adjusted as needed.
There are so many different visualization techniques for data and information, why stick to one? Implementers should be able to define and plug-in their own if necessary and appropriate. As a start, we experimented with scalable hierarchical tree-type visualization that scale well, can be zoomed, and through which users will be able to interact with the nodes as an alternative way to manage and set up the BluePrint. See some examples from the D3 community:
And while we are talking about visualization techniques for data, think about other lists, items, relationships, etc. in Tridion Sites that could be visualized too. See some examples below to spark your imagination.
We as humans evolved into incredible pattern recognition machines over the last millennia, something we are still much better at than our new AI colleagues. Visualizing data in different forms and formats will allow us to make use of this ability and spot trends and patterns in data and content in Tridion Sites.
For example, this visualization could show click paths, broken links or “where used” content relationships.
This variation could list all publication content and show usage, references, and semantically related content.
This visualization could break down your content by publication, language, country, site, team, etc.
And this example could inform you about page visits by personas or adaptive personalization results.
But enough about visualizing content, let’s talk about managing content and how it’s supported in the new Tridion Site Graphene UI.
The “Content” section in the main navigation will address all tasks around setting up, managing, moving and localizing content etc. It assumes a basic understanding of the way the BluePrint hierarchy is set up, how the content is structured, and how Tridion is set up for the individual customer implementation.
To improve content “findability” and reduce number of clicks for regular content management tasks, we came up with the concept of content “Collections”. Think of collections as a “saved search” or a “virtual folder” in Tridion terms, but preconfigured and provided out of the box. Collections could be “smart”, so they learn and adapt based on the user’s individual behavior or on the aggregated usage patterns across all users.
Collection quick previews provide an indication of what or how much content sits behind a collection at a glance. In addition, any search you perform and save will end up here. Because Tridion DX will go across Tridion Sites and Tridion Docs, results will include both marketing and structured content. The objective is to provide the user with quick access to relevant content, minimizing the need to navigate the actual content hierarchies as much as possible.
To ease navigation and search, the content manager explorer UI will include the following features:
By default we have chosen for a mobile design pattern to navigate the content structure (tapping into a folder and going back to parent level via back button). This is required to ensure the scalability of the UI to mobile form factors and enable touch interaction.
For desktop environments featuring big screens however, we will provide the option to switch to a traditional two-panel setup (tree on left, with list next to it). This empowers implementors that have to browse and switch publications a lot during system setup.
The list would also allow for alerts, change indications, or inline updates. The example below shows how an alert could be exposed in-line, notifying the current user that the parent item for a localized item has recently been updated and requires review. Selecting the item will provide more details about the alert in the preview panel on the right.
As before, each individual content (e.g. a Page or Component) item will be shown in a separate screen, relying on native browser tabs for multi-document scenarios. Our design goal and challenge for every individual item screen is to radically simplify and improve them, the example below shows a component.
As already described in the recent Tridion DX announcement, Tridion Sites can be run in a variety of “headless” or “Content API” scenarios. In such scenarios, content will be managed in Tridion Sites, but published to a variety of different delivery environments, contexts and mashups.
In this case, Tridion does not manage the web page to which the content is published. This requires some level of “omni-channel preview” to enable editing and previewing several applicable contexts and channels. The example below shows how such preview could be integrated into a typical content component screen, allowing accurate and nearly accurate previews for several publishing contexts.
Form views in Tridion Sites will be radically simplified with clean form design, appropriate sizing of fields and UI controls, and a smarter and more contextual exposure of actions and functionality. We hope this will make the content editing experience using form views much more effective and easier to use.
A design strategy we defined around editing controls (e.g. when editing a rich text field) is to use the same controls for the same field type across form views and in-context editing in Experience Manager. This means the editing experience is consistent regardless of where it’s done. Functionality and options are also shown “on demand” to not “clutter the UI” if not necessary.
The “Channels” section in the main navigation lists all destinations you will be able to publish to from Tridion Sites. It contains all kind of content mashups (e.g. if you are publishing web content to an eCommerce or marketing platform), your Tridion Docs publications, and of course it will contain your Tridion Sites. Creating, managing, and localizing sites will be possible via a sites grid/list. Sites are represented as cards or in a list view, containing relevant information (e.g. available languages), status, and actions right there.
From here, users will be able to navigate to a specific site (either on staging or the live site) to see it in context. If users navigate to the staging environment of a site they will be able to preview and edit content in context using the experience manager user interface.
Our design strategy for Experience Manager focuses on improving known issues and shortcoming while radically simplifying the editing experience. The content will have the center stage and Tridion Sites UI and overlays will only be shown if necessary. Regions, drop zones, borders etc. will all be there too – but hidden if possible to keep the users focus on the content as it really looks and feels.
The Ribbon toolbar goes in favor of more embedded, contextual controls. Default tasks, such as adding content, will also be triggered from the region or location on the page where the new content should be added. There, it will reveal options for content types that can be added in the first place, and exposes a content browser to find the actual content after.
Browsing content will use the same navigation screens and principles as discussed earlier in context of “Content Management”, but in context for the specific task. We believe this will make the editing and navigation experience more consistent, seamless and integrated between in-context and out-of-context editing. This general design approach for in-context editing will allow us to expose an “embedded experience manager” together with a region and related content in content mashup scenarios. More about this in a later post.
Last topic in this Tridion Sites UI design preview, but nonetheless an important one, is the reorganization and simplification of system settings. Tridion grew over the years and was extended from version by version, so did the possibilities and formats to set up and configure it. The new Tridion UI will have one “Settings” section that is accessible via the main navigation. For business users, it might only contain their personal user settings and preferences. For systems admins, it will provide full access to all settings around Tridion Sites, Tridion Docs, User and Group management, and a section dedicated to Integrations and Connectors.
Extensibility of Tridion Sites is a very important topic for us and I will provide another design update dedicated to that. Our aim is to provide a simple and guided way to browse apps and extensions from different sources and stores (e.g. SDL App Store or Alchemy App Store), install them easily via the UI, or even preselect and approve individual UI extensions on a user by user basis from a centralized location. More on this topic soon!
That summarizes our preview of the broad design concepts and the new Graphene UI for Tridion Sites. The first post focused on the overall design direction and what’s in for business users and content teams. This post highlighted concepts and strategies aiming at our technical expert user community. We at SDL are super excited about this project and I personally hope that through this Blog I was able to share a bit of this excitement with you too.
As development teams are gearing up to lay the foundation for the new UI and bring all API’s in shape and form to start building it, the UX design and product management team is in the middle of validating and testing the above concepts and designs with customers. It’s iterative, so what I described above will change and evolve based on feedback we receive and the things we learn along the way. Do you or your organization want to be part of this process? Reach out and let us know! We are eager to evolve those design concepts in every iteration in real world scenarios. That's the only way to translate a pretty idea into a usable and valuable product!
And finally, we can only learn and evolve if we hear from you and understand you better! So please leave any feedback or questions you might have below this post and continue the conversation there.
SDL’s User Experience Design Team!
It’s been a while since you’ve heard from us here, so let’s change that! By ‘us’ I mean the user experience design team at SDL; a small group of design thinkers, prototype tinkerers and interface artists. Rest assured, we haven’t been lazy or out surfing. We’ve been working hard on a variety of exciting projects and products.
One of the projects we’re really excited about is a new user experience design for SDL Tridion Sites. It’s still early in the process, but far enough to get our community to validate and provide feedback. And that’s where you come in! :-)
I’m sure you’ve seen the recent announcement around SDL Tridion DX, which harmonizes SDL Tridion Sites (former SDL Web) and SDL Tridion Docs (former SDL Knowledge Center) into one suite. If not, check it out here! We think this is excellent news as it allows us to rethink and redesign how these products work, look and feel. So, how do we start?
We know that each product serves different user communities: marketing departments for Tridion Sites, and product and support teams for Tridion Docs. Both of these communities often work on content that eventually ends up on the same web pages, whether that’s a marketing campaign, an interactive product configurator, a shopping experience, or a support article.
Through our ongoing research, we have made a lot of friends in both communities, and recognize that in many organizations these content teams are still quite separate. But we also see that organizations can no longer afford to operate in silos. Today’s rich and engaging customer experiences require efficient and integrated solutions in which collaboration and transparency are key.
Scenarios involving content mashups and content API use require many moving parts to coordinate and (inter-)operate. Content needs to move through a content lifecycle process in an efficient and directed manner. We think we can support that very effectively by aligning and evolving the user experience and user interfaces of both products, Tridion Sites and Tridion Docs.
I would like to share the results of the first iteration of this design process in this and the next post, providing the broad strokes of our experience design direction, including many concrete and visual examples to make it as tangible as possible. Consider it a minimum viable concept design which we build to learn. So please stick with me, even though it’s a bit of a long read, and provide your feedback in form of a comment below!
SDL’s user experience design team works across all SDL projects. We are a small but well-connected community, so we exchange our work and learn from each other, even though we serve entirely different markets and domains.
The new Tridion DX interface paradigm originated in a different domain, for different user needs and requirements. In the last few years, we launched a variety of services for professional translators with our Language Cloud offerings. The challenge was to design new user experiences for individuals and small teams who would review and assess our offerings on a public website, comparing us against other online services.
This meant that all of the flows and interactions needed to be engaging, relevant, valuable, and most of all, self-service. While subscription plans and trials make it easy to win subscribers, they are just as easily lost if they don’t see value or dislike the user experience. The marketing messages, visual content, sign-up and onboarding all had to be simple, intuitive, modern and appealing.
This context informed a new user interface design language, which we later called the Graphene UI. This is the result:
Our previous product UIs followed the ‘Carbon’ metaphor: a strong material for highly specialized applications in enormously complex and demanding circumstances. This metaphor reflected our enterprise customers’ day-to-day reality, so this was a good UI metaphor at the time.
The Graphene UI also follows this ‘UI materials’ metaphor. Graphene as a real material is considered the material of the future: truly two-dimensional, 207 times stronger than steel and bendable. It conducts heat and electricity efficiently and is nearly transparent… think what you can build with that!
Graphene is the perfect metaphor to describe our ambition to create a new class of user interfaces at SDL.
This new UI design language should be state of the art in terms of aesthetics and visual design, it should firmly carry the SDL brand, it should be robust and strong enough to carry the weight of highly complex enterprise implementations, and it should be flexible enough to adjust and adapt to the variety of digital channels, contexts and devices our customers use today and tomorrow.
Our journey towards this new design language started with Translation and Localization Management products, including SDL Trados GroupShare and the SDL Language Cloud Translation Toolkit, which have already been released with a new Graphene UI. Others are currently being worked on.
From these products, we learn and actively collect feedback to further inform the development and evolution of the Graphene UI. Now we have started translating the Graphene UI to Tridion DX, starting with Tridion Sites. It’s a balancing act, maintaining the level of simplicity and usability that inherent to the promise of Graphene, without compromising the flexibility and extensibility of the Tridion Sites product.
But what would a design challenge be without a good set of constraints, right?
We started the discussion on how to design and build this new user interface across the various Tridion Sites design, development and architecture teams. From a UX design perspective we assume a full responsive user interface, that seamlessly scales to a variety of different devices and form factors.
While we are not yet taking a “mobile first” approach, as this does not represent the context and the preferences of the majority of our user base, we will ensure that all screens are fully designed for touch interactions and gracefully scale to mobile.
The below screen gives an idea how a typical Tridion Sites “list screen” translates to the new Graphene UI. It’s simple and clean, gently exposing our new corporate brand identity, with much more white space and a clear focus on relevant and applicable information and controls.
However, we know that changing the look of the UI, and making it responsive and touch friendly, does not radically alter the overall user experience.
The Tridion UI was built on the hierarchical content structure that sits at its core. For implementers or admin users who know their way around the setup, this poses no difficulty and makes this structure quite intuitive. However, for business users such as content owners, copywriter and web designers, this poses an unnecessary level of complexity, distracting them from their main focus and passion: the content itself.
Improving the user experience for these users can be achieved by abstracting the complexity that comes with each implementation to a business process level. These business processes revolve around content lifecycle management and deserve a prominent spot in the user interface and overall information architecture.
Taking into account the Tridion information architecture and the need to make the experience and task flows more intuitive led us to these questions:
Of course, every company is a little different, works in a different way, and has different goals and objectives, so we had to generalize and idealize. We applied the Jobs To Be Done (JTBD) framework as a tool to map the individual “jobs” every company needs to get done and for which it would “hire” products.
We followed a typical content lifecycle process and clustered jobs into main categories, drawing an idealized flow from planning through to archiving and retiring content.
This categorization and flow is more aligned with a business user’s mental model of Tridion Sites. We used it as the basis for the overall information architecture and navigation setup. We are also very conscious of the needs and requirements of our technical user base as well, since both users need to find their way through the UI quickly and effectively.
We chose the main navigation sections to correlate with the roles and job profiles within our customers’ organizations. This will allow for hiding or deemphasizing navigation options for different groups of personas to ensure individual users will see and use options relevant and necessary for their workflow, allowing for more focus and providing implicit guidance for the task at hand.
In addition to the structural change, we changed the visual representation of the main and sub navigation to be visible at the top of the screen and not hidden away in a slide-in menu.
When you enter your office or home you would like to be welcomed and feel comfortable. Why should this be any different when you enter a web content management system? We took this analogy to work on the Tridion Sites first touch and onboarding experience.
Like the lobby of an office building, a first time a user will be greeted on a welcome screen, like in the lobby of an office building. After logging in for the first time, the users is provided with all the information needed and wanted, such as a general or personalized video, step-by-step guides, quick access to learning material and documentation, prompts for required setup activities.
Of course, this also includes the ability to adjust and change the login experience to the individual needs of a user as she grows into and expert and more experienced user. The idea is that the UI grows with the individual user, becoming more sophisticated as the user requires more expert functionality.
The example below shows this behavior of the user dashboard which transforms from a general welcome screen to a more personalized and advanced dashboard.
Please consider the startup screen as an example. We want to improve the out-of-the-box character of Tridion Sites altogether. The goal is to provide a standard setup that comes with good defaults so that customers can use it from the start and do not necessarily require extensive configuration.
The "Dashboard" section is the “home” of the main navigation and where you would enter Tridion Sites. Dashboards will provide a powerful and flexible way to quickly access data and any kind of information in a short, visual, summarized format.
We also expect dashboards and their information to become the key screens that users will consume most when using mobile devices ‘on the go’. For this interaction, we will continue to follow the “better out-of-the-box experience” principle, providing a handful of relevant preconfigured dashboards, including the “cards” and connectors that come with them.
This individual user dashboard will provide a personalized view on tasks, notifications, shortcuts and key metrics. The data and cards on this dashboard will vary depending on the user’s role, behavior and preferences.
A content reports dashboard could also come out of the box, providing a variety of information and metrics directly related to content stored in and managed by Tridion Sites. This type of dashboard would not be personalized but would show system and content metrics. In addition to the mobile device ‘quick peek’ example, use cases for this type of dashboard include kiosks and large screen displays in physical team spaces, as a live view on what’s happening in Tridion Sites.
Our main strategy for the dashboards relies on the experience, competence and creativity of our developer community and implementation partners, who are closest to the needs and characteristics of any specific customer implementation.
These professionals have a deep understanding of the type of data and information which should be represented as dashboards. So be assured that your support, guidance and documentation towards developing and connecting new cards, connectors, whole dashboards and more will be as essential as developing the dashboard mechanism that will come with the product.
When analyzing and categorizing the jobs related to content lifecycle management, we see that in reality many organizations use a small core of Tridion teams that run multilingual websites, globally distributed and working on multiple projects at the same time.
Most organizations run a form of agile, meaning processes keep changing and evolving, so static or inflexible workflow models won’t work or help. This is where the previously mentioned abstraction layer around business processes will enable a much larger marketing audience to run and contribute to content lifecycle projects while at the same time managing the underlying content in Tridion Sites.
This layer will manifest in a new navigation section called “Activity”, dedicated to everything around tracking tasks and getting work done. It comes with “Updates” which provides a simple and personalized overview what happened in Tridion Sites since the last login. The stream would allow for filtering updates for a specific project, product, publication, country, language, team, event, workflow status… you get the idea.
Although the actual business processes our customers deploy and run are all different and unique, they all contain the concept of “projects” in one way or another.
A Tridion Sites project could have its own updates stream, a list of collaborators, deadlines and milestones (e.g. for content review, translation, publish and unpublish content, etc.), tasks and assignees, translation jobs, and related content or placeholders, which has to be created and published.
Providing project managers with the ability to create and manage web projects, assignments, deadlines, milestones, teams, tasks and placeholder content at a publication or folder level will allow team members to focus on content creation, review, optimization and publishing tasks. It will alleviate the need to be concerned with the actual BluePrint structure, which can be overwhelming and sometimes unnecessary for an inexperienced user.
Besides “Updates” and “Projects”, you will also find “Workflow” and “Translations” in the “Activity” section. Workflow provides familiar access to all workflow activities on your or your team’s name. They are listed independent to the project they belong to. This will allow users to track tasks across multiple projects that run in parallel.
The new Graphene UI aims to provide this information and representation in an integrated and in-context way. We aim to avoid pop-up windows as much as possible to account for seamless mobile and tablet experiences. Lists of items, for example, will include several different “views”, allowing items (content, tasks, projects, etc.) to be represented in all kind of formats and visualizations (besides typical grids and lists).
For workflow and translation jobs we are exploring a “Kanban View” so you can represent your team’s tasks on a typical Kanban board and use it in your daily team standups. For “projects” which also have a time dimension, we are exploring editorial calendar views and Gantt chart representations for project planning and resource allocation.
In-house linguist reviews of returning translation jobs will also become a seamless experience as we will be using our SDL Online Editor, a web based translation editor and review tool, which already adopted the Graphene UI and will plug in seamlessly.
You could argue that “Dashboards” and “Activities” including “Projects” will be all what marketing and content creation teams need to get their work done. They might not even require access to the additional navigation sections and as a consequence would enjoy a radically simplified user interface.
But obviously, somebody needs to do the “heavy lifting” and those personas need efficient access to the deeper layers of Tridion Sites including all its complexity.
This will be subject of the next post on this space. How the Tridion Sites Graphene UI will address the demands and expectations of our tech-savvy implementation and expert user community, and how the new UI will look and feel for them. So stay tuned for Part 2!
We are curious what you think! We can only learn and evolve if we hear from you and understand you better! So please leave any feedback or questions you might have below this post and continue the conversation there.
Even if you are a member of Mensa International or a professor in rocket science, I believe that I can confidently say that you are probably very bad at reading someone else's mind. If you want, you can give it a try. Look at the person closest to you and focus. Focus on what they might be thinking about right now and then check with them if you were correct or not. And? You were miles off. And now try and do the same for someone that you don't see or don't even know personally. And? Even worse.
So if we're all so bad at reading someone else's mind, why do we often assume we know what people want, need & think when we make decisions about what products to build for these same people, what features they need and how they use the products we just sold them?
In most situations, the answer is probably that “we know that we don’t know but we have to make a decision so we just guess and hope for the best”. And in most situations, that means that you’re building your companies’ future on chance. And the chance that you are wrong is a whole lot bigger than that you are right.
At SDL, we don’t pretend that we can read minds but we definitely try and reduce the ‘not knowing’ part and thus reduce the chance that we’re wrong about what people need or how they’re using our products. We call this data-driven design. This means that we are always seeking data about what people need, how they work, and how well new designs and features match their needs and whether they can be used by them.
The SDL UX group uses a wide array of methods and tools to gather this type of data to help ourselves and the teams we work with to reduce the amount of guessing we do.
As people are very bad at talking about what it is they want or need, we prefer to go out and talk and observe them as they perform their regular work activities in their own context or during usability tests (also called qualitative research). This gives us the opportunity to learn from what they do as well as what they say. Personally, I always compare it to how hard it is for someone to explain to me how they ride their bike. Because they’ve automated most of their actions to the point where they don’t even have to think about them anymore, it is difficult for them to explain what they do but it is very easy for them get their bike and show me how they ride it.
We are also working with the R&D teams to implement technology that will help us understand how people use our products, which we have called Telemetry. This is something that is very common on regular websites but we don’t have this (yet) in most of SDL’s products. The quantitative data we get through this method will tells us WHAT people do and if we then combine it with qualitative data, gained through interviews and observations, about WHY they do them, we have a fairly complete set of data to help us inform what we should and could do in the future to improve our products and services.
So, in summary, we are constantly generating data through qualitative and quantitative methods to help us make the right decisions. To be able to do that, we are always interested in getting into contact with you, our users, partners, developers, implementers and general members of the community. If you’re interested in helping out, post a comment below and we’ll contact you.
In the last post I introduced the UX team at SDL and explained our general motivation with this community group. In this post I will describe “What we do” in more detail, so the services we offer and how those map to the UX roles we have in our team.
The services the UX team at SDL offers can be broken down into 4 main pillars:
1) Strategic UX describes the collaboration of the UX team with the business, and more particularly with the product management teams. This includes all kind of activities that help defining, validating, and shaping the definition and direction of a product or service. Typical activities include design thinking & service design workshops, ideation sessions, concept validation, and the definition of design goals and success metrics. These activities ensure that UX has ownership in defining and prioritizing new features and capabilities, and influence product roadmaps with the users in mind. Strategic UX is about asking the right questions, framing design problems, and setting a design direction without jumping to solutions. For new initiatives with a high level of uncertainty, we added some lean UX methodologies to our strategic UX toolbox. This involves formulating assumptions and hypothesis about outcomes and impact, which we then can test and validate. To cover Strategic UX activities at SDL in a structural manner we introduced the “UX Strategist” role with great success.
2) User Research helps us understand the context of our customers and users including their individual goals, needs, and business objectives. Our primary research goals are to answer specific design questions, inform our overall UX design process with data, and continually increase the understanding of our users within our cross-functional development teams. Most commonly we perform qualitative research which mainly means visiting customers at their desks. There we perform contextual inquiries, conduct user interviews, or run informal usability tests of products and prototypes. Typical research deliverables include user personas, use case scenarios, user journeys, and a lot other design artifacts that describe the complexity and the challenges our users deal with on a day to day basis. We are also making progress in collecting more and more quantitative data describing how our products are being used via what we call “Telemetry”. Stay tuned for a blog post dedicated to this very topic!
3) Interaction Design represents the work most people in software development traditionally associate with “UX”. It focuses on the usability and usefulness of a design solution. It is all about iteratively working out detailed designs for a stated problem which then can be tested. For this we use design prototypes that simulate the anticipated end user experience as good and realistic as possible and necessary. This allows us to test and validate designs before a developer writes a single line of code which is necessary as correcting a wrong assumption is way more difficult and expensive ones it is being build. So ones we are confident that a design addresses the actual problem and will work for its intended audience, we start working it out in all necessary detail. This also includes the support of the development team with the implementation. Interaction design deliverables include scenarios for key personas, information architecture diagrams, screen-flow charts, sketches and wireframes, low- and high-fidelity prototypes, as well the detailed user interface specifications including colors, typography, spacing, behavior - everything that is needed to build it.
4) Digital Experience Design is closely related to interaction design but focuses on the desirability and “lovability” of a design. Its goal is to delight users, not only to give them usable solutions. If successful, digital experience design can stimulate positive and memorable experiences that users will associate with SDL as a brand. To craft such experiences, we carefully experiment with visual aesthetics, subtle nuances in typography, look at minimal but consistent use of product branding, and add illustrations and graphic design elements to our interaction designs. Digital experience design deliverables include detailed visual designs for screens and controls, sets of icons, illustrations, and “micro-interactions” (animations and transitions). All deliverables are documented in form of libraries and design guidelines to ensure consistency across products and services.
We currently distinguish 3 different roles in the UX team including UX Strategist (UXS), UX Designer (UXD), and Digital Experience Designer (DXD). The graphic below illustrates how the roles map to the four services as described above.
To complete the picture of “What we do”, let me add a description of my own duties as the UX Director too. My primary focus lays on managing the UX team at which I carry the responsibility that the team can be effective, efficient, and has the right focus. This includes finding the right talent, facilitating team growth, defining and evolving the team’s structure and processes, providing appropriate tooling, enabling team communication and collaboration, and balancing the need for design in the organization with the available resources.
I am also representing UX within SDL’s leadership team and the wider organization. In this function I am aligning UX with various adjacent disciplines and stakeholders. As an evangelist for UX and design thinking in the wider organization I am promoting a holistic customer-centric perspective across our internal teams and organizational silos. The commitment we made towards delivering great customer and user experiences across all touch-points of the customer journey requires a rigorous outside-in thinking from all stakeholders involved. Working with them all on coordinating and aligning our combined efforts is part of my personal mission at SDL. Finally, I am also representing UX design to external, this includes various activities as for instances setting up this community group with the aim to show that SDL is serious and passionate about UX design.
In the next blog post I will continue the introduction to UX at SDL, covering “What we work on”. I will describe how we look at customer experience from an outside-in perspective and how that defines our scope. If you subscribe to our feed, you can both join the discussion and be sure not to miss anything. However you choose to follow us, it would be great to see you back soon and often!
It has been quite a few years now since User Experience (UX) was introduced as an important success metric and an internal discipline at SDL, solidly embedded within its software development and operations organization. Ever since, UX at SDL grew. In terms of size, organizational maturity, internal influence, and impact on the success of the business. UX earned the trust of the various teams it supported, the customers it engaged with, and ultimately its seat at the table.
Why This Community Group?
As UX professionals, we take the role of user advocates when it comes to research and development in the organization. To do this successfully, we are leaving the office as often as possible for customer visits, user interviews, usability tests, industry events, and more. Those interactions are crucial for us to understand the goals, needs, and contexts of our users. By creating this community group, we hope to broaden the scope of our interactions, conversations, and discussions with users, customers, and partners alike. We aim to increase transparency, share how we work, show our ongoing projects, collect feedback from outside our team early and often, and engage in discussions about everything UX related to SDL.
As designers, we also feel strongly connected to the design trade at large and strive to be closely connected with this professional community: We already visit and present at conferences, join and host design meetups, and attend workshops. We follow countless blogs, Dribbble artists, and Twitter feeds. We connect with other designers and design teams, learn what keeps them awake at night, and exchange thoughts on how to bring design to the next level. With this in mind, another aim of this group is to facilitate and intensify the exchange within the broader design community. We will be sharing our own stories and ideas, approaches and processes, as well as failures and successes to inspire or help other designers and to stimulate discussions on how we can all get better together.
UX design meetup at SDL's Amsterdam office, April 2015
Audiences For This Group
The first audience we hope to reach with this community group are our users, customers, partners, and anyone involved with the services and products SDL offers. We are curious about your customer and user experience. What are you already happy with? Where do we need to get better? Do you have feedback on the usability and usefulness of our products? How well do they help you to get your job done? What is missing? We are also interested to hear your ideas, suggestions and questions concerning design at SDL in general. By engaging in the discussion with us, you can help us do our work with you in mind!
Second, we hope to reach other UX professionals and design teams working in similar contexts and facing similar challenges. We are curious to hear how you “designed” your design organization, which approaches and processes work for you, and which ones do not. Which though nuts are you trying to crack? Are you designing for complex, cloud-based enterprise scenarios? Growing a design team and wondering how to best structure and position it within the organization? Are you looking for best practices to improve collaboration with globally distributed design teams? Figuring out how product roadmaps, lean UX principles, service design, and agile software development fit together? Or are you interested to hear which tools other teams are using and why they love them? We think there is plenty to talk about and we would love to do so with you!
We will be active here and intend to react to all questions and discussions in a timely manner. If needed, we will also involve our colleagues from product management, development, support, or other teams to provide appropriate perspectives and feedback. Nonetheless, please keep in mind that this community group is new for us, too. We are learning as we go, so please bare with us in the beginning.
One last thing before we jump right into the conversation: Let me take a moment to introduce the UX team at SDL.
Introducing The SDL UX Team
At SDL, we have a dedicated in-house UX team that is part of the product development and operations organization aka “DevOps”, headed by our CTO. We are a fairly diverse, globally distributed team of 13 UX professionals, covering seven nationalities, spread across four different offices and time zones. Our backgrounds and trades range from strategic thinkers, design researchers, data nerds, user advocates, prototype hackers, micro-interaction lovers, to pixel-perfect UI artists. Collectively, we share a hunger for innovation, design thinking and creative processes, always striving to make our products and services better. And as most designers out there, too, we hope to make the world a little bit better with what we do. So when I talk about UX at SDL, I mainly refer to the UX team. But we are not alone! We are at the core of a larger customer experience community within SDL that is dedicated and committed to delivering great service and product experiences to our customers and users. This includes, but does not end with, our support teams, market research, professional services, product management, research and development, technical writers, testers, and cloud operations. I am sure that many of them will join the discussions and conversations on user experience in this community group, too, contributing their own perspectives and opinions where they fit best.
In the next blog post, I will continue the introduction to UX at SDL, covering “What we do” and describing the services we offer as a UX team to the rest of SDL. If you subscribe to our feed, you can both join the discussion and be sure not to miss anything. However you choose to follow us, it would be great to see you back soon and often!
Welcome to SDL's User Experience Community!
This is a space for SDL's UX design team and SDL's customers & partners to engage and discuss topics around user experience and design. Learn more about the UX team at SDL and the objectives for this group in this Post: The UX Team at SDL - Who we are. If you subscribe and become a member of this group, you can both join the discussion and be sure not to miss anything. However you choose to follow us, it would be great to see you back soon and often!