Long ago when I was in college, I had a course called “Advanced Jazz Improvisation.” As a musician, studying music in college, I did not start life as a designer. This course explored many ideas on improvisation trying to stretch our musicianship.

One day we showed up, and the professor told us we would be doing “limited equipment day.” As the title was a bit baffling, we didn’t quite understand what we were going to be doing. Were we going to play with a high hat and a snare? Just a snare? A kick and a cymbal?

As drummers/percussionists, the professor explained to us that the entire world can become a canvas upon which we can hit, scratch, tap and bang. Our instructions were to play anything in the room... except drums, cymbals and rims, nor any traditional percussion instrument.

While this opened up a new world of possibilities, this limited us from using our normal bag of tricks. We had an entirely new palette. We had to start to think of wall switches, chairs and even someone’s skull as a new percussion instrument. Even though oftentimes I would have preferred to have one arm tied behind my back and use a drum set, we still had our sticks and our brains, which were our most important assets.

I bring this up because the design equivalent of “limited equipment day” is the design of 3rd party application. As designers, oftentimes we are used to having our design tool of choice and a blank canvas onto which we can create unique solutions that are tailor made to our application or user experience. However… once you are told you will be designing for an application that is not yours, but rather a product that your company is purchasing, it can feel more like “limited equipment day,” than business as usual, where you would rather design with one hand, versus use the tool you were given.

The limitations on the system, the vendor or the technology quickly can turn into a nightmare project where you are simply fighting the system, and spending insubordinate amounts of time to get any little tweak you want, and it can be frustrating. However, we still have our mouses and our brains, so we can still design something great with the help of our vendor partners.

What follows are my tips, gained from many hours of beating my head against the wall, and designing for 3rd party systems for the past 15 years for working both with very flexible systems (such as Salesforce or even web builders such as WebFlow and Squarespace)and very limited systems.

The principles remain the same and the steps are the same as well:

1. Understand the experience — where it lies, and what it needs to accomplish, and what it needs to integrate with.
2. Understand the limitations and strengths of the tool— which can range from Logo, font and 2 or 3 colors, to a fully customized implementation that is seamlessly integrated with the natively developed applications.
3. Create a prototype (hopefully within the actual tool) — much like a “spike” in Agile, we create a test version to work out the kinks and see what the end result will look like.

Understand the experience you need and where it lies

So the best thing you can do to start is to block out where the experience is within your flow, and understand what the purpose and goals of the applications. If I am using an application that will interact with other experiences — i.e. a new window link from a web app or a website embedded into a mobile app — by applying as close of styles and layout as possible, I will make sure the transition is as seamless as it can be.

If the application is stand alone, you will have an easier time of keeping consistency. In both cases, it is definitely critical to use the same strategic techniques you would for any application or feature. Where we will start to deviate is in the solutioning.

While this step might seem like a “no-brainer,” prepping and making sure you understand context and requirements will help you ask the right questions when you get to limitations of the system.

Get your hands on a demo asap!

One of the first things I do is to get a sample setup of the application. I usually will get access to both the development panel (despite whether or not I will be doing development), as well as a sandbox environment to see what a sample app will look like. I try to see what components are out of the box, and exactly how they work, as well as get a sense of how the application want you to do the basic flows and use component.

Almost all systems have been designed to “do things their way,” and the quicker you can assess how that works, and how the basic app functions, the quicker you can get a grasp of what can and cannot be done without a ton of trial and error.

Figure out what can be done

Once I have a demo site, I am looking to assess a few key items that will help with figuring out the limitations of the system:

1. UI framework or component library: If you are working with a strict system, this might be just the framework the developer uses. In a more feature rich tool, you will have a component library that you can drag and drop into the WYSIWYG editor. I will take some screen grabs and use that as reference when designing.
2. Global Branding & Font : When playing with the global settings, just about every application will allow you to set one or 2 global colors and fonts. Once this is in place, try to get a sense of what this will and will not affect. Also how and where a logo could be placed
3. Copy and content: This intersects with layout, but you want to get a sense of where you can edit and place copy, graphics and content. In some systems this may be EXTREMELY limited, and you need to design around this. However, in my experience in most cases, you can pretty freely add graphics, copy, and typesetting at will, and these will be the areas you can use to control the experience the most, when the other parts are not as flexible.
4. Organization and architecture: Just like the components, typically there are flows, navigation and architecture that the vendor has created as a base. We need to start by seeing what those are, and any options we may have for navigation layouts, micro-flows, etc
5. Data: What data can get into the system, and what cannot. If we have the data in a feed, however the system cannot accept or integrate, we may be out of luck.

Figure out what can’t be done.

The following is a list of items that may or may not be possible depending on the application:

1. Integrating custom code: These may be full on services or javascript, or even a simple HTML box. The more custom code we can add, the better our options for customization.
2. Modifying styles on widgets: Those widgets we inventoried in the first step might not work for what you need. Ideally we could use those as a base without recreating them, however a lot of applications make you use them wholesale, or you have to recreate them on your own.
3. Assigning custom styles: You may have little individual styling you can change on a component or on a layout. I was working in a recent very inflexible application, where we had a top and bottom bar that were fixed and taking up 1/2 of the screen real estate on laptop screens, and we just could not remove those and target the style. We wound up having to live with it and work around it. Some systems allow design tokens to help with customization, and those are great first steps, but that may still require customization that may or may not be achievable.
4. Layouts: You may have a choice of multiple layouts or a drag and drop interface, but you also may be stuck with a layout, where you can only affect the dynamic areas on the screen. Check and see how the application handles layouts,

Focus on content and flow

The best tool you have in your quiver is copy and content. Just about every tool allows you to have pages and/or boxes that you can add copy. These can help to unify the application visually, but also can help fill any experience gaps that are created with the default flows.

When enough is enough and you need to… customize

When you have done as much as you can do within the normal bounds of the application, and there are areas that need customization, first rule is try not to break anything and do no harm!!! There will be additional releases and patches, and it is best to choose customizations that are going to stand the best chance of future releases. These can be self contained features or code.

If you have to edit or customize the base code, just know what you are doing. I think there are definitely cases for doing editing base styles. However, this may break in the future and the team has to be aware of that.

Make sure to work with the vendor on customizations. They can guide you on things you can break or customize with little impact, and how others have customized before.

If all else fails, using your own CSS sheet might be a good alternative to customization. This is also prone to breakage here, but when you get to the end of your rope, you might need this one.

Create the prototype

When you are designing, you need to choose how you will create a prototype. As in most cases, I prefer to create a wireframe or paper sketch, and then build a prototype in the tool. I find that with mockups, I can wind up doing a lot of work that is not possible, and it causes a lot of back and forth.

In a best case scenario, the tool is easy enough to use to create a very rough prototype. If not pairing with a dev and using fake data can work in a pinch if you need to test it, In a bind, recreating the tool in Sketch/Figma/XD will work, but I definitely recommend it as a last resort. With screen mocks our interaction design will definitely drift, and has a good chance of setting wrong expectations if you are not careful. You can design interactions that are not possible.

Wrapping up

Designing for 3rd party applications can feel limiting, however with a solid technique and a plan, you can set the team up for success. Just remember that setting expectations and understanding the limitations as soon as possible will be key. Play with it, and see what you can spin up to get a better sense of what it can do. If you can and need to customize, choose your customizations.

How have you been able to customize 3rd party apps? What are your tips and tricks?

Designing the best testing, most usable solution is not always the best answer. In fact, oftentimes, it is not.

Now, before you go leaving a bunch of angry comments, let me explain…and I would like to challenge how you think about design and possibly approach it a little differently. I have certainly changed my approach to the topic over the years, and it has evolved to where I am now.

Eight or so years ago, if you would have asked me to design a platform or an application, I would have delivered to you, a thoroughly thought out researched solution that would meet the needs of the user. I would have had the developers and product managers thoroughly on board. We investigated the design, and gave it the old, “We can build this.” However, over the years of actually building these solutions, things happened that were beyond our control. Sometimes, projects were underestimated, or the business often had less patience than we anticipated to get things released right. Corners were cut, bugs were released, and the overall result was often not always one we were proud of. The team understood what our strategy was, we had a roadmap, we had great ideas, good user feedback, and a usable design…so what went wrong?

What I found out, was that the design had elements, which were agreed upon were going to take longer than we anticipated, and I didn’t do everything I could in the design to make it easier to produce. I was not 100% sure about what data we had, and what we did not have, and I was sort of informed about how the API returned information. I was not aware of how some of the key elements in the design could be removed and released with unacceptable issues due to the pressures of business. The result was often what I call the “Swiss Cheese Effect” — a product with lots of holes that the user is asked to fill until we can build it.

Once this happened, I began asking questions and I found out I was not the only one this was happening to. Beautiful designs in Sketch files left on the server to rot, only because the design wasn’t able to be built within the scope of the project, which was always significantly less than we needed to create a great experience.

Fortunately, I’ve also worked in start-up environments with no resources and very large appetites for features as well. In this situation, every last interaction, animation, API call, etc. takes time and resources, which are in short supply. So I started to investigate and experiment.

I thought about what would happen if I just tried aligning my ideas with the technology that exists, instead of trying to redo everything to make it unique.

As I experimented, I had many developers school me in the ways that these systems are created, and how I needed to understand their world better if I wanted to get things built. I learned that I can work with the systems and get creative with language, layout, etc and keep a lot of infrastructure standard, and get “better,” and creating work that was easier to implement.

We get closer to “ideal” from a series of “better(s).”

By releasing “better”, we can see if metrics improve, which will dictate investigation of a more fleshed out solution. Working with what you have allows you to get that solution out faster and benefit the user.

So here are my tips for designing to build. Even if you know that there is an ideal solution out there, it takes maturity and restraint to say, “We know how we can solve the problem in a delightful, innovative fashion… but we’re not going to do it right now, because we just want to make something better and complete, versus undone.”

Understand Your Zoom Level

The first thing to determine the necessary level of understanding is your level of zoom in your project. “Vision” projects require a very different approach vs a “story” project, so we will have different requirements in terms of understanding.

Vision projects by their very nature are at the highest level of zoom. These are by their very nature very big picture and require less validation of current state technology, because we hope to create a fundamentally better experience.

The “reality threshold” is the percentage of your design that you know could be built today because your team actually validated what needs to be done.

For sake of argument, a vision project can be from 0% to 60% reality. Because the reality threshold is very low, you don’t need to know about every piece of data, but you should be able to discuss what it would take to create the UI, bring in the data and make adjustments. Once the vision design makes it to first release, it may be more like a 80–100% reality threshold using almost all technology that exists. This all depends on your business as well.

At the other end of the continuum is the story level zoom. Design at this point requires a much higher reality threshold because you will be designing what will be built. You will need to understand the intricacies of the data when you design, and how that might impact overall performance and timeline in general. Understanding this will help you decide on what you can add safely, and what you should make the decision to remove proactively.

When working with zoom, ask yourself:

• Am I at a production level of zoom or a vision/concept level of zoom?
• How far off are we planning for this vision to be reality?
• What level of reality threshold is necessary at this point to make sure this is produceable within that timeframe?

Knowing How Components Really Work

With the rise of design systems, almost all organizations are working with some sort of design system or component library these days. This, in general, is a good thing, however, there are a few caveats. Design system components rarely plug and play. Components almost always need some sort of adjustments or customization. Knowing how they behave will help you determine whether to break the component (not desirable!), where to break the component if needed(not desirable!), or possibly considering an alternative (much better!).

One example of a well-designed component library/design system is Salesforce Lightning. I wrote an article on how to work with Salesforce Lightning, because I’ve run into the issue of designing with those components. I’d use them in context only to find out that a lot of what I wanted needed to be custom. I would inevitably drop a standard component into my design, and alter the data points, and the developers would tell me “ This is nice, however, I need to break the component and customize it,” which means that any further updates are isolated—(not ideal for the long haul). So I thought differently, using the parts that we had, and the parameters that were customizable, what could we do to create a usable design which is buildable.

So, when working with any design system or component library ask yourself:

• Do I know how all the data gets into this component? Can I change the attributes? How?
• What design elements can I change? Type, size, color, scale? How does this break the component?
• If I have to break a component in order to make it work, can I try something elsewhere so I don’t have to break or customize a component?
• How would it look with the out of the box component even if it is not ideal?
• How does that impact LOE and delivery time?

Working With Data Points

One of the biggest challenges when it comes to UX is having the right data in the format that is digestible by the user. Now, ultimately it is up to the engineers to get that data or not, however as designers, we really need to understand what data exists, and what does not in order to make good decisions.

When we create comps with data points that don’t exist, we have to understand that there are can be 3, 4 or more layers across teams who need to be involved in order to get that data. While you are designing part of a larger initiative, you will inevitably encounter data that does not exist, however, stay clear of introducing new data at the center of your design when you do not know how it will be getting into the system. Assume that data that does not already exist will not be there, and design accordingly.

There is no one size fits all rule for bringing data into a system. Sometimes, especially as part of a larger initiative, the business just needs to create the data, and it will be included in the project. Other times, having that data there can delay delivery, and increase complexity unnecessarily. Take into account your level of zoom, and judge the likelihood of that data showing up at release time. If you can work around it, do so.

The other thing I will mention on data is that when you do your best to design with what you have, you can get improvements built that might otherwise be delayed. “Better” is always a win. If you can set up your project to get something built, and then incorporate additional data as a progressive enhancement, that’s a win in my book. That is working software, which is better than Sketch files.

When working with data, ask yourself:

• Do I know if we have all this data?
• Do I know how it is formatted? If data is to be converted or combined from that format, who will be responsible for converting? Front-end or back-end?
• Is the rest of the team aware of the data requirements? Does the entire concept hinge on that data being there?
• If we do not have this data in an API, do we have it at all?
• What is entailed in creating that data? Is that feasible or absolutely required for me to make this project successful?

Creating Interactions and Animations

Interaction and animation are now prerequisites for great UI. However, these add time to projects and are often considered the “polish” to a project and not the meat of it. While I fundamentally disagree with this, it is often the first thing to land on the cutting room floor when push comes to shove, and we are against the clock. The really cool transition of graphic into button may be integral to your design, but it didn’t make it out the door and left “Swiss cheese.”

When we talk about designing for build here, we really have to understand the level of effort to achieve the animation, and also who is developing the work. If you are working with full-stack developers, the HTML animation may take them a while to complete. If you have a design technologist or you yourself can create those as an asset, all the better chance of getting it delivered. The point here is to understand how much time it will take to create the animation, the value to the project, and a fallback that is acceptable should there be a time crunch. On the flip side, if you are in a situation where the product is being polished, then think about all the interactions in the design, and see where you can cut or simplify the interaction. If you can make some sort of cool animated transition become a simple fade, do it.

The other main consideration is reflow and scaling. One time I was working on a really large site, and I came up with a really cool reflow pattern, and the front-end developer came to me and said, “we’re not doing this.” I still thank him to this day for telling me “no,” for shutting this down early. While the design in Sketch looked great, and we could technically do it, he knew that we were going to have enough headaches, and this was not one worth creating. His advice (and this is my advice to all younger designers) was to make it simpler and use an overall framework that was well established. We were doing so many other innovative things, that this was where we really needed some predictability and consistency. I redid the layout using a common layout and scaling pattern, and used that. It was not as cool and innovative, and definitely did not look as great in my portfolio, but it was all about getting it built, not my portfolio.

Great design is all about getting it built, not about your portfolio. If a design solves a problem better, but the execution fails, is it better than a lesser design with a clean execution? I would choose the latter any day of the week.

There is a great debate on whether designers should code, and I think 100% “yes” designers should know how to code HTML. They may not be experts, but they should know how you might achieve a design or animation, and would be able to explain how they think a reflow or animation could be achieved. It helps you to better understand at a high level what is involved to create your comp, and if that is worthwhile. Otherwise, you may create a lot of interactions, complicated layouts, etc, and not really understand what you are asking for, and more importantly, how to come up with some alternatives.

When working with interactions and animations, ask yourself:

• Who is building this? Are they good with design details and/or animation?
• Can I use a standard reflow pattern and still achieve a similar result?
• Are the animations a progressive enhancement? If not, what will it take to create them?
• Can I create them myself?

Designing With Pre-built Applications or Plug-ins

Another shortcut to getting things built is to use pre-built applications and modify to meet your needs. A lot of times, you don’t need a custom UI that takes time to develop and maintain, and you can use a UI provided by the SaaS company to get something released.

The first thing is to do is get your hands on the software and see if you can prototype with the software or not? If it is possible, you may want to use pencil sketches, and build a prototype in the tool to test. That way you will best understand the limitations of the tool, and how it will behave with your design.

If not, you will need to rebuild the original UI in Sketch and modify it. Just like the above components I spoke about, you will really need to understand how the components work, so you don’t create components that will not be able to be produced. If the application has a UI kit, all the better!

When working with pre-built apps ask yourself:

• How can we customize layout, style, copy etc?
• How can we change the flow?
• Can we update or modify modules on a page?

Working With Start-ups

When you work in a startup, designing to build can be your best friend. You have extremely limited resources, and as much as you want to create amazing UX, being able to release a complete product is much more important at this stage. While getting data may be much easier to add to a system versus an established company, there will still be operational overhead. By tailoring your design to an efficient build, the team can spend the time needed features, or just a quicker release.

Get. It. Built.

By filtering ourselves to only deliver the solution that maximizes the best UX with only the most critical and easiest to build and format elements, we improve our chance of getting closer to the vision, and a more polished result.

I hope the above ideas give you perspective. I will be the first to tell you I have not worked at with the “Apple’s” of the world, and these principles may be different for companies who do large releases (“big bang” releases). Also, there are schools of thought that might think of this as limiting to building something “amazing,” and that is a fair comment.

However, in my experience, simplifying the design, adding progressive enhancement, understanding what is entailed in build has always helped get things developed faster and gave us more control over the outcome, versus trying to create a “better” design, only to have to make concessions in production, having the product be a mere shell of the vision.

Anything you can do to make it easier to produce in my opinion is not lazy, it’s creative. Being able to design something easier to produce will improve your chances of a better end result in the long run.

To use the old Agile build analogy, we want a build complete cake(cupcake -> birthday cake -> wedding cake). Even if it’s a smaller cake, I’d rather have a great tasting cupcake than a crappy tasting wedding cake.

I welcome your thoughts on the topic and whether designing to build vs building to design works at your company.

Usable, useful, desirable… and buildable? was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

A necessary evil… but nobody likes’em. It’s time for UX to look at the dreaded Interactive Voice Response System (IVR).

When was the last time you called a company and had a really great calling experience? I mean one that you raved about?

If you’re like me, the moment I know I have to call a company up to speak with customer service, I get a cold anxious feeling. I expect a long drawn out experience. I clear my calendar for an hour, I get in a comfy chair, pour something cold to drink, take a breath… and dial. I typically expect it to be pretty miserable — the transfers, the repetitive hold music, the mechanical voice prompts. Plus, you are never quite sure how experienced the person who picks up your call is going to be. It’s a part of the CX industry that, while there are some great experiences (I’m looking at you Discover, Apple and T-Mobile!), as a whole, it has been traditionally devoid of design.

One day, I got the call to work on an IVR. I was actually very excited. I had done some voice work in the past, and was eager to get my hands a little dirtier this time, by actually building something myself, versus doing the design and pairing. This project was going to be different: greenfield and no legacy technology was going to be used. ❤️

Prototyping

My first task was to figure out how to prototype this. After doing a bit of research, I landed on a tool called Voiceflow. It’s a small Canadian company, whose founders were very helpful in answering all my questions. The application hooks up to Alexa to create a skill that you can prototype or actually publish it via Amazon developer account. It’s an intuitive WYSIWYG editor, which allows you to visually create your flows and then test it. It will also connect to data sources, so if you have an API and some technical know-how you can do some next-level prototyping.

I started by determining the use cases, conditions and flows we were going to test. I worked with the Customer Care team to help determine all the common tasks that customers were calling about. We reviewed which of those could be automated, and marked the automated flows vs the flows that would need intelligent routing.

One of the challenges of creating an IVR is that customers have to make choices by using categories much like we would use in application or website design, only here, there are no visual cues like icons or colors to help customers understand what is behind each choice they make. So what happens is a customer may pick the wrong menu, and the system will direct them to the wrong person. As a result, more modern phone systems use the voice to route asynchronously, and to move into “microflows,” which are based on the utterances and intents. What you find here is that today’s phone systems behave exactly like Alexa skills, and the only minor difference is the ability to use the keypad to enter numbers and 0 to get a representative.

On the intelligent routing side, we were able to discern the key circumstances that a person would be calling about, and give them specialized information based on their particular journey. Furthermore, these people would be labeled with a flag, which was pushed to a CSR. The combination of better customer feedback and intelligent routing allows customers to get to the right place while prompting them to choose to act on a situation that is likely the reason they are calling, combined with the intents that they utter.

In addition to the intelligent routing, the intents are also important to map. Remember that task analysis? That came in handy while determining the intents that we needed to map. “Intents,” in case you are not familiar with voice design, are the intentions that a user has when saying a phase or keywords. These phrases and keywords are called “utterances.” When planning your prototype, you will want to list out your intents to match the key tasks, and then map all others to a “general” catch all bucket for miscellaneous. You will also need to list out all the utterances that can be said that will define an intent. There are lots of great intro articles to voice design that cover this, so I won’t go into too much detail here.

One last consideration on prototyping is the gender of the voice, and the use of TTS (text to speech) vs having a voiceover recording. In our instance due to time and other constraints, we opted to go with a Male voice, and TTS. We opted for a male voice because the brand wanted strength and trust, and a casual male voice seemed to fit better. We only did TTS out of simplicity, and to test what the TTS was able to accomplish. With Voiceflow, I was able to do some manipulation with the speed, pitch and pauses, however the result was definitely not ready for prime time in my opinion. There are several places that have voice talent, like Voice123, where you can send them a script, give them some direction on tone and character and they can turn around in a day or so. You take those voice prompts and plug them into Voiceflow, and voilà… IVR!

Language, Errors and Feedback

Once we have the key flows that we are going to map, a list of intents that will map to those, it’s time to start writing the flows, menus and script out the logic.

The language on the flows was also a consideration. In reviewing several key brands’ IVRs, there was a very large discrepancy in style. Just as there is in any creative, there is not a “one-size-fits-all” voice and tone for VUI. Voice and tone need to fit the brand. Some are casual and verbose, and some are friendly and simple. Each style will have its pluses and minuses, and will convey different things. Remember though, even if you do get casual and verbose, you still want to get to the point. We want people to get where they are going, and have a pleasurable experience.

There is one other issue within the language: menus. Typical old school style menus which would make you want to commit Hari Kari, would say “Press 1 to get a monkey, press 2 to get a giraffe, and 3 to get a lion.”

These menu systems are not very human or pleasurable, nor are they efficient. Add to that the fact that the person on the end of that phone call is most likely not calling to say how good of a job you are doing, and you have a pretty good reason to make sure you get the menus and navigation right. The IVR’s that are best in class though give you menu options in the form of a question:

“ Are you calling about product information or to make a purchase, iTunes or App store, have a Technical support question, or are you calling about a recent iPad order?”
—from Apple support prompts

While we are on the topic of language, we need to make sure to cover errors and feedback. In a voice UI, remember it is a time based medium which is linear. Because it is linear, we will need to make sure that users get multiple points of feedback that indicate the choice they have made. This can be done by reiterating their choice “OK, iPads, are you calling about product information…” As you see in the example above, they are also using the prompts that reiterate that the system understood “iPad”— “Are you calling about a recent iPad order?” In order to minimize errors and confirm the direction of the user, good feedback will incorporate both techniques to let users know where they are.

Error handling can be handled in many ways, however, it will need to cover back, repeat, and main menu options. Once a user has made a selection and the feedback has confirmed that indeed the selection was incorrect, there needs to be a voice prompt that is global or local to correct the error. Global correction would be something like:

“At any time, you can say ‘main menu’ or ‘previous’ to go back.”

Another concept in error handling is knowing when the system to use fallbacks. NLP systems can get very frustrating when they fail, or misunderstand your intent. Imagine talking to a person, who doesn’t understand you, but with a machine the patience level is much less. We need to know when is enough. My rule of thumb is 2 error failures on a particular prompt, and you should be transferred to a live person. Figure out what the threshold is for your system.

When handling errors, you want to make sure that you are progressively enhancing the error experience in order to get the user to make the correction. For instance on the first menu you might say:

“I’m sorry, but I couldn’t find that account. The account number can be found at the top of your electric bill. Please say or enter your account number. ”

However on the second one, you might try something like.

“I’m having trouble. Let me get you to someone who can help.”

We have the recognition that the system is at fault —”I didn’t quite understand that”— and then the progressive enhancements to the error correction — where you can find the information and then transfer to live assistance at the threshold for transfer.

Mapping and Deliverables

After figuring out the language, we needed to make sure we had deliverables that were intelligible and that could demo the flows and that stakeholders could follow and give appropriate feedback. I started the flows in Sketch and used Invision for collaboration. I had to split a few flows into subflows — that translated nicely into Voiceflow — which I could reuse and maintain.

When breaking out the flows, you will want to keep in mind that a voice experience should have a beginning, a middle and an end, and your documentation should match that. The beginning — starts with authentication, the middle — choice of topics and automation, the end is when they get to a person who can answer their question.

1. Authentication: Each flow will most likely start with an authentication piece. Just like the web where the first screen you reach is the login screen, an IVR will need to identify you. This can be an order number, social security number, date of birth etc.
2. Main Menu: Once you have been identified, you are prompted with your main flows. From this main menu, branch out flows for each section of the app.
3. Automated services: For those services that can be handled automatically, there will be flows associated with them
4. Customer care transfer: Once a person finally needs a live human, we will need to make sure we have the appropriate routing information, and hopefully offer conveniences like auto callback or choice of hold music. This is a good time to mention the recorded line or add a survey opt-in.

Once I mapped out the flows, the flows were mapped in Voiceflow, and delivered to an Alexa device for review. The stakeholder team could open the Alexa app on their phone and open the skill. Note: you will need to get the email address associated with their Amazon account in order to add them to your beta test.

Testing:

While this work is ongoing the plan to test in on the Alexa app or through the browser via Zoom. Voiceflow has a web interface that can emulate the skill, however, it behaves differently than the skill itself on an Amazon device. My recommendation on testing then, is to have the user speak through the computer and put the Alexa device close up. If you have the luxury, you can add them to the beta testers and they can test on their phone, but that does not seem as if it would be foolproof. You can also try the web, but a user has to hold down the space bar for the mic to pick up, and it is easy to screw up.

I hope this has been helpful. IVR now fits very nicely into the repertoire of voice designers at this point, and hopefully more voice designers will try their hand at designing an IVR system. While I will not profess to be an expert on this — there is a lot of literature from people who have done this for years— this was a very interesting exercise, which shows me that there is room for designers to try their hand and improve it. Some of the best customer service brands have done some really nice work, and it really is a great challenge to bring a design lens to those projects.

As Enterprise designers though, I want to stress that this is the top of the funnel — the proverbial “garbage in” — which we hope to fix by empowering users to get them to the correct customer care rep. However, the next piece of the puzzle is the information that is pushed to the sales rep on the computer in order for them to assist properly and close the loop… but that is a story for another time.

Using Alexa and Voiceflow to prototype a telephone system was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why Enterprise design is important, and why you should care.

How many hours do you work a week?

For most of us it is 40–50 hours a week. And…if you take the 168 hours per week, minus 49 hours for sleeping 7 hours a day, that means about a third of our waking hours are at work, so work is pretty important.

While I realize I’m not the first to make these calculations, the point is many of us do use software in order perform our job. In a 2016 study by the Brookings institute, they found that 90% of all jobs require us to use some sort of software to perform our jobs. And that number is constantly increasing. How well we do at that job, how much we are able to accomplish, and how we feel about our job, is tied to the software we use. It either enhances or detracts from our capabilities. So, as a result, how we feel about our experience of using software, tools and systems, can have a big impact on our lives, and those who work for the companies we serve.

There is new research available that shows that the ability to be able to use technology is related to overall job satisfaction. For instance, in a study done by Aruba (a HP company), found that employees who work in fully-enabled digital workplaces where new workplace technologies are in widespread use are 51 percent more likely to have strong job satisfaction, and 43 percent more likely to be positive about their work-life balance than ‘Digital Laggards’ who have less access to workplace technology.

The inevitable consumerization of Enterprise technology

“The consumerization of the workplace is a very real movement. Employees are consumers and we bring consumer expectations with us to work,” says Janice Le, chief marketer for Aruba. “The workplace is getting smarter and therefore, employees are working smarter.”

People who work also use consumer apps, and are used to the great design and usability of apps by tech giants like Amazon, Apple and Google. Workers use these apps at home and then bring this bias to the office, expecting the company CRM to be as beautiful and well organized as the Netflix app they are using at home. What we find is there is a big disconnect between the two, and a lot of this has to do with the process of the design and build of these applications, which can lead to unsuccessful launches and adoption of the software. For the past 40+ years, the way Enterprise systems were built was to collect requirements, design, document, and build. Over the past few years, we have realized how this methodology misses the opportunity to prototype and iterate, as well as deeply understand the human element, which leads to successful product design. BTW Waterfall is from 1956 guys…#justsaying.

According to a 2017 McKinsey report on the success of enterprise software implementation:

“…too often, this team does not include people whose day to day responsibilities involve the use of the software. The result is a technology that only accomplishes some of the goals that the team using the product needs to be successful.

As UX Designers, it is our job to make these tools usable so that people can get their jobs done, minimize errors, reduce repetitive behavior, as well as reduce overall cognitive load. We understand the people, their environment, the business goals, and restrictions, then we build stuff and watch them use it and iterate.

It’s a pretty simple but powerful concept.

With movements like Lean UX, Design Thinking, Agile and the like, we have matured the process of creating the smallest testable item, testing it and iterating, until we have something “good enough.” However, these methodologies are just now starting to make their way into Enterprise, and it’s an exciting time as the industry realizes the need for designers.

Workers use these apps at home and then bring this bias to the office, expecting the company CRM to be as beautiful and well organized as the Netflix app they are using at home.

Change is on the horizon…

As of late, large companies are starting to realize that a big part of the “Customer Experience” depends on the “Internal Experience…” and they are putting money against it.

How do you expect a Sales/Customer Service/Processing rep to do her job well and effectively, without usable tools to assist them?

Seeing as workplace information systems can be extremely complex, we are in need of a new breed of designer to help sort them out. The clock is finally running down on the lifespan of the outdated applications that run large companies. As a result, there is a need for a new breed of software designer required to reimagine these systems.

They will need to be doing a better job of understanding the people and context, which then lead to satisfaction and adoption of the software. In “Corporate America,” we now find our selves in the middle of a glut of outdated applications, with massive technical debt, and user complexity, which are in desperate need of updating. It will no longer be good enough to simply “add a field here” or “add a button” there. We need a way of handling these issues that borrows from the past, and incorporates the future into their development and design.

While there is a large amount of designers entering the UX field, (adding an additional 10% over the next five years), I firmly believe some of those UX jobs will be in addressing workplace design.

And why not? The area is of prime importance to business, and of the workers themselves. In my experience, Enterprise UX is where Consumer UX was 5 to 10 years ago. It is still not considered a “revenue driver” and more of a cost center than a profit center for the most part. It is traditionally considered an “efficiency” play versus a bottom line necessity. However, with companies like Salesforce and Zendesk creating enterprise apps that are easy to use and can help companies be more productive to improve the bottom line, company leaders are now at a place that they need to improve the experience meaningfully for the people working at these companies.

Ten reasons why work on Enterprise UX matters

Here are 10 reasons that I switched my career to focus the Enterprise side of design and have not looked back:

1. Projects are complex and require collaboration across disciplines. This complexity is fun and challenging. You will need to decode business rules, unpack operations, and work with several teams on execution. The applications often have many user groups and complex tasks, which can make it a fun design challenge to create a usable experience for everyone.
2. It will challenge your IA skills. You will really need to understand data relationships in order to do Enterprise software. There is a TON of data… and this data will need to make sense to humans at the end of it. This means object and attribute modeling chops, as well as an understanding of data technologies, what data is available, and what is not as well as the reliability of the data. You will be a data ninja and you will love it!!
3. It will help you learn how to think flexibly no matter what you design. In an Enterprise system, you cannot create “snowflake functionality” — tailor made flow or patterns for every flow. There is so much to be done, and so many micro interactions, that you will need to develop the ability to see how a pattern or module can be used in multiple contexts and as flexibly as possible. A lot of times it’s not ideal for every individual situation, but that’s OK. You will learn to leverage scale. Take a look at the Salesforce Lightning Design System and see how they use the modules, sections and components and reuse them.
4. It will challenge your service design skills. Enterprise Software is almost always integrated with a service that will integrate across the operation. This means several groups will be involved with different needs, and it will be your job to unpack the operations visualize them, and see how the application can support those operations.
5. You get to help the people you directly work with and see their satisfaction. I think one of the best parts of my job is when we create something, and see people using it. With consumer apps, there is always a layer of abstraction between the business and the customer. The experience improving a conversion or improving engagement can be satisfying, but to me it often feels more like playing a video game or a puzzle, where you trying to rack up points versus tangible improvement in people’s lives. With Enterprise , you get to interact with the people who use it every day (unless you work for a software company that makes software for purchase or SaaS). And you get to know them, and understand their issues, and their needs. And it drives you to create something better for them. They are the people on your team. I often feel a deep sense of responsibility to be their voice when designing tools for them.
6. You have a large pool of users at your disposal to test and iterate with. Honestly, this is one of my favorites things about working on internal software. If you are working on a user test for consumer software, it can be time consuming to get users, collect feedback, recruiting and scheduling, and getting payment approved. With internal users, you can iterate many times over, and getting real users to test or give you feedback at any time. It’s priceless! I just walk down the hall, grab someone and start asking questions.
7. There are not a lot of us out there… While I can’t seem to find data on this, anecdotally, I keep running into hiring managers in Los Angeles that require Enterprise or SaaS experience, and they are having trouble filling those positions. I’ve also noticed an increase in job listings for Enterprise UX designers. As there are more and more apps being created, and internal teams get built out, the need will be greater. Furthermore, as UX and Service design grow, I can very well see an opportunity to use our skills on an “Internal Experience” team, which integrates with culture, HR and Technology to take care of our teammates holistically.
8. …but there is a ton of need. Honestly, most large scale Enterprise apps suck. Buggy. Hard to use. Repetitive. Tons of data in various places. There is so much fruit on the ground, that you can make tangible improvements pretty quickly. A lot of apps like Salesforce and Microsoft Dynamics, are typically custom implementations, however those applications may not be configured right based on the user needs. It is a lot of work to understand and design for a system holistically plus have the discipline to keep it well organized.
9. Enterprise software has the capability to really help people do great things. When scientists do research, they use software. When Space-X astronauts launched into space, there was software. When Amazon delivers your fuzzy bunny slippers in two days, it uses software. And someone designed it. While it is very important to generate revenue to help companies keep afloat and use it to fuel important world changing projects, the world changing projects happen by giving our workforce the right tools to make the change. Whether its visualizing data, monitoring a rocket, or helping a customer spend 5 minutes less on the phone, this efficiency is where we make a difference as designers, which means you can be part of that cool stuff!
10. You can become the next unicorn. While the typical UX unicorn is UX/VizD/Front End Dev. There is a new type of unicorn = Product/UX/Business Analyst. As you get deeper into Enterprise UX, you find that those disciplines start to merge, and you very well could find yourself in a position to handle them all. Which can mean you have more control on the projects, and you can define and design a solution.

Ten reasons you should think about designing for Enterprises Applications. was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working with Salesforce can be a challenge for designers not used to working with predefined system. The ecosystem is large and products on the platform are different. We’ll discuss how to navigate designing with Salesforce.

Salesforce is now one of the largest CRM platforms available. According to a study by Gartner, spending on Salesforce related implementations outnumbered the next competitor (SAP) by over 2.5 to 1. The benefits of Salesforce are outstanding. You have a very flexible, customizable platform combined with a pretty good out of the box design system and components. Plus, the ecosystem is so rich that you can run your entire business on it (which several businesses do). It is used for Fortune 500 companies and small businesses alike.

Because of the growth of the platform, there are more opportunities for designers to get involved in designing for Salesforce. As I explained in my last article, Enterprise UX is now a thing, and Salesforce is an important part of that ecosystem. In this article we’ll break down the ecosystem, the benefits and challenges of working with Lightning, and some tips and tricks for your next project working with Salesforce.

The ecosystem

First we have to start with the different parts of the Salesforce ecosystem. While the “CRM” (Lightning) part of Salesforce is what started the company, the system itself is comprised of several parts and functionality, but they all integrate together.

Lightning Apps:
All of the below apps work within the “Lightning” framework — which uses the Lightning design system, and allows the team to add functionality to the application. The Lightning framework works very much like Google Material and Google Apps, whereby they are all united by a unified architecture and design system, where you can switch “apps” and views depending on the products you have enabled. These apps have the same design system, and use the Lightning modules. If you are working on the Service Console, this is the system you will be using,

• CRM/Sales Cloud
  This is the heart of the system which allows sales teams to operate. Pipeline, Customer CRM, Leads, etc.
• Service Cloud:
  This application gives you the ability to create cases within Salesforce. It also adds a Knowledgebase to the functionality.
• Marketing Cloud:
  This lighting app has journey builders, email and marketing automation

Mobile Apps:
Mobile apps are a native version of the Lightning system. These modules are different than the desktop version, and the patterns will be different as well. The native mobile modules are often different than the responsive version of the browser based cloud apps. This is based on the idea that mobile will have its own set of tasks. These are built in the mobile app builder. As of Winter 2020 release though, the mobile application resembles the Lightning Console much more.

Communities
While the initial intent of Communities initially was for intranets, partner portals, and customer self service, Communities is now being used for portals and websites of all types to give a branded view experience, leveraging the same core data to an additional audience.

You get native integration with all the functionality, however, this application has an additional set of native components, not all of which are available on Lightning are available in Communities (visit the component reference and filter by “Lightning Communities” which is a mix of Aura Components and Lightning components). Also, if you are not doing a custom layout, the layouts here are different from Lightning, as well as a lot of the design patterns. This includes special blog and forum post content types that only exist in Communities.

Here is a list of experience builder’s features to customize:
Brand and colors
Layouts

Commerce
This is both the front end and the service end of the e-Commerce platform that integrates with Salesforce. Like Communities, it has its own subset of components, although the builder is the same as communities, so it is much more like using Communities versus using Lightning.

In this article we will only address the Lightning apps using Salesforce Design Lightning System (SLDS). If you are working on Communities or Commerce, there are a different set of out of the box components that are specific to those platforms, as well as the builder tools.

The layout & navigation patterns

Global Navigation —Scoped and modular tabs.
Salesforce global navigation has 2 main patterns — scoped tabs — which has all the top level items listed out, and modular tabs, which keeps a closable tab open for each record, much like windows in a web browser. Most applications use the modular tabs, with the scoped tabs being carried over for late adopters.

There are a few main layouts that are reused across the system for efficiency. There are a few variations on these, but these are the main ways that the Lightning system wants you to create a layout. While they are context independent (you can have a customer record in any context), the detail layouts and the middle level list layouts are consistent with themselves.

In addition to the above, there are additional Lightning Page Templates that can add further customization to your layout and still work nicely within the Lighting System.

Working with custom and out-of-the-box

When planning your work, you will want to get a sense of whether you will need to use the Lightning Web Components or you will be doing a custom application. In many cases, using Lightning will be the best bet, simply because of the maintenance and dev work it takes to create custom components. This also keeps things consistent, and you can leverage the design system they created. If you are tasked with using Salesforce as the backend system for your app and are going to use the API’s to pull the data, you will have more flexibility, but it will come with a significantly higher level of effort.

If you are going to use the Lightning System, you will want to keep a few things in mind:

1. Use the Lightning way of doing things first
   Much as using any other design system, Lightning has its way of doing things — layouts, modules etc. One of the things Lightning wants you to do is reuse the modules in a variety of contexts. Modules such as Jabber or Communication, can be used at the Case Level, Record Level or User Level.
2. Views often come with defaults that can be modified.
   For instance, the default on the list view, has a bunch of filters, all of which are easily customizable within the default parameters.
3. Many components are customizable, but that makes them more prone to breakage in future releases.
   While the modules have parameters that can be adjusted, a lot of times you cannot change a module — such as take a layout of a timeline component and put your own data types in it. If you want to change a module’s data that is not a parameter, developers will have to customize it, and can be more prone to breakage.
4. AppExchange
   If you cannot find a default Lightning Web Component, you may be able to find something on the AppExchange. This way you can skin or modify an existing module.
5. Be purposeful about creating a custom component
   If you find that you need a custom component, remember that custom components will have to be coded, and maintained. Salesforce makes 3 releases a year on average. Each time there is a new release, it may break your custom component. Plus with Lightning Components, you get the benefit of enhanced features as Salesforce develops them. In addition, working with custom components can introduce additional bugs in the system to fix. If you can do good UX with a Lightning component and make it work, the experience will benefit overall.
   Moral of the story: Custom components OK, Lightning components better.
6. Get a Sandbox and play
   If you create your own developer sandbox and see how the modules and layouts work, you will quickly understand how they work.

Modifying the visual assets

While you may want to use the modules and Lightning Design System, you may not want your app to look like “Salesforce.” Salesforce Lightning comes with a set of design tokens, which are variables on which the system is based, such as spacing, density colors, fonts, etc. If you modify these items, you can easily make Salesforce look less Salesforce-y.

Also, Salesforce has a complete list of icons. Icons are used EVERYWHERE, and are tied to components and context. There are 5 types of icons:

• Standard: These are the icons used everywhere which help label modules.
• Action icons: which are tied to an action
• Custom icons: which are for adding custom to layouts and modules, but are not part of the defaults
• Doctype icons: which represent different file types
• Utility icons: Which are attached to modules and are the most common

Colors are another way to customize lightning. Lightning does have a very robust color system, with all types of hues and values, Most brand systems don’t include this level of detail. The colors are all editable, however be careful about changing hues and values — because they are often tied to the meaning of the interface and the balance of the UI in general, so swapping out a dark blue for a medium yellow may have unintended consequences during development. Colors are also linked to a data object- Lavender is a contact, Koromiko is Cases, Activity is Salem, etc.

Prototyping solutions

As far as prototyping, if you have something simple, or are just demoing some layouts, you can use the Sketch, Figma or Framer X template with the SLDS that you can use to customize. The file is set up very flexibly to use and modify the modules. It has Lightning, Mobile, Builder and Wireframing components. It is a lifesaver. You can design in Sketch and prototype in Invision, Principle, etc, or use Figma or Framer to prototype.

However, if you need to do more in-depth user testing, you may want to consider either:

a) Building in a prototyping software that can handle variables, multi-state objects and inputs — such as Axure or UX Pin.

b) Consider building a prototype in Salesforce or working in a sandbox. I know this option might seem daunting at first, but if you are using out of the box functionality mostly, this will save you a ton of time. You can fill in your custom components by placing graphics in modules to represent custom modules. You can get a much more realistic experience this way, and if you are going to be working in SF for a while, this may be a worthwhile investment. I have included a link to a Trailhead so you can learn the basics of creating your own Salesforce layout. It is much easier than it sounds.

Resources

Lightning component reference: https://developer.salesforce.com/docs/component-library/overview/components

Sketch file for SLDS (Saleforce Lightning Design System):
https://github.com/salesforce-ux/design-system-ui-kit

Figma kit for SLDS: https://www.figma.com/file/5dgFdCHB6FGjfOPAZEDNVK/Lightning-Design-System-Components-for-Web?node-id=0%3A1

FramerX kit for SLDS:
https://github.com/salesforce-ux/design-system-ui-kit-framerx

Trailheads for customization of Lightning (learn to prototype in SF):
https://trailhead.salesforce.com/content/learn/modules/lex_customization
https://trailhead.salesforce.com/en/content/learn/trails/lex_admin_implementation

Data Objects:
For those of you who are heavier into information architecture, here are the object models for the different Salesforce domains:
https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/data_model.htm

Lightning Page Components reference:
https://help.salesforce.com/articleView?id=lightning_page_components.htm&type=5

Special thanks to my friend Jon Cline, for contributing his expertise to lend some background on this information.

UX/UI design for Salesforce Lightning apps was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Enterprise Applications, the discipline of Enterprise UX, and where the differences are between Enterprise and Consumer and how to approach the complexity.

The term “Enterprise UX” is a hot term. It returns about 53 million results on Google now. The fact is, that after many years of working on Consumer applications, businesses are starting to see the ROI that companies achieve by investing in the internal applications that their employees use to conduct business.

I remember asking a former boss about whether a tool was an “Enterprise class” application, and her response was “Enterprise class just means ugly and hard to use.” While I laughed at her response, the hard truth is at the time, she was right.

While that was back in 2012, many Enterprise applications are still ugly and hard to use, because of the complexity, the age of the applications, lack of global perspective, and ad hoc requests. Historically, Enterprise implementations have been disjointed and cluttered, and hard to use, in addition to the “ugly” factor, which not only contributes to an increase in “eyesores” (MY EYES!!!!), but also cause legibility, scanning and comprehension mistakes that are often more costly to fix than to get right. As a result there has been a renaissance in Enterprise UX with several companies doing an awesome job of creating great Enterprise design, such as Salesforce, Intuit, and Microsoft.

These applications are often very process and business rule heavy, and often require a ton of flexibility and customization features. This is typically in contrast to a typical “Consumer” app, where consumers expect to have a simple intuitive experience for the lions share of the features. This means the Consumer side applications are skewed toward the first use, not the 1,000th, whereas he Enterprise app needs to be prioritized for repetitive use, and geared towards a user who will inevitably be a subject matter expert, well versed in prioritizing their workflow and understanding of the application architecture for goal completion.

In addition, Enterprise applications will almost always have a Service Design component. A person uses the software in the service of his/her job in order to accomplish a specific task with which the technology assists.

Some examples:

• A Customer Service rep needs to access orders in order to see where the order is at, and then needs to place a note on the order for the production team.
• An Inventory Management team is managing the inventory and communicating with the order team when products run out.
• Sales team member needs to track sales, follow up with leads, and keep track of his pipeline.
• A Project Manager needs to see what tasks are assigned, who is working on what, communication on the tasks, and the progress towards completion.

These are all services, where the technology facilitates views of the status and data within the system, notifies people within the system of jobs to be done, and automates some of the work—essentially, monitoring, data entry and reporting functions for the end user.

Another part of the applications are the large data sets. Enterprise applications are often working with 10x the amount of data that a customer actually sees. For example, a customer might see their name, address, telephone, email as part of their record, whereby the users of the Enterprise system can see those basic demographics in addition to clicks, pages visited, lifetime value, projected sales, etc. The customer needs very little information in comparison to the Enterprise user, plus Enterprise users need to be able to see and manipulate all the data behind the scenes. Also, when they cannot fix the issue themselves, they need an efficient way to let a team member know what to do… at scale.

These data sets, typically housed in a central database, are pooled from multiple applications within the platform. Within this data, as an Enterprise UX designer, we are tasked with making sense of all of this for the various user groups. There are various data objects (User, Order, Item, Communications, etc) with relationships to one another. A Customer may be the central object in our system, but has contact information, email communication, sales, etc, which are attached to that customer object.

Each of the objects come with “attributes” — such as address, city, state, cell phone, etc — that have historically been developed and formatted to match the business rules and system architecture, versus the humans at the end of that data. As a result, it is up to the designer, to make sense of all the business data, and make sense of it back to a user, in an organization that makes sense to them, and displayed at a time in their flow that they need it. Without clarified relationships of objects, applications can become messy very quickly. With the advent of big data, and systems that are able to house every click and interaction, the amount of data we have becomes very daunting to the average human to digest.

Plus, an Enterprise worker has 10x the amount of functions that a consumer app has, and has to integrate toolset, processes and information seamlessly. The result can be very complex and hard to use to the best of users — leading to poor job satisfaction, increased error rates, and lost efficiency and productivity at the very least—if not well thought through and executed. At the worst, it can cripple organizations from scaling their business.

As a result, organizations are now taking the user experience of internal applications very seriously and applying traditionally consumer focused methodologies, such as a user centered design approach to determine feature/function priority and look and feel.

What skills do you need to design for Enterprise Apps?

For sake of argument in this article set, I am going to assume you know how to do “Consumer UX design”— you understand how to research and identify needs, create prototypes to test, and develop thorough solutions for development. There are several great treatises on those subjects, so I will avoid them.

These skills will be foundational to the techniques discussed further. If you are not familiar with design, development and research, I would start there. This is definitely an advanced topic, as it builds on foundational UX domain knowledge — in addition to the fundamentals of User Experience design.

An Enterprise UX designer will need deeper competency in:

1) Interactive Design/Prototyping (including Research and Analysis)
2) Information Architecture
3) Service Design, Ecosystem and Service Blueprinting
4) Business Rules and Requirements or working with a Business Analyst (BA) if you have one.

While number 1 and 2 are part of a UX designer’s T-shape toolkit, 3 & 4 may require some additional experience. Even if you have experience in all 4, there will be some new ways you will need to figure out how to use them together. The interaction design will be much more complex, prototyping state based prototypes with inputs that pass data and variables, telling a story in your prototype in order to test it. This means Invision, Principle, Figma, Sketch etc may be insufficient for handling the job alone, if those are your primary tools.

I‘ve done Enterprise projects in Invision that have over hundred screens for a singular flow and if someone made a mistake, I had to reset the test and I think hurts feedback without the input data and variables to see where users get hung up on inputting information. In my experience, there are better tools for collecting usability feedback (aside from a concept test—which I will get to in upcoming articles).

In addition, these apps can require an advanced grasp on Information Architecture. This does not mean simply the organization of articles and content, but also organizing the data objects and attributes. In order to visualize how all this data works together, it will be helpful to make concept models of how all the data objects relate to one another. Then you can put them back together in a way that makes sense for the tasks and the user group. This is often one of the critical steps in organizing information in a way that makes sense and is digestible. Once you have a concept of how objects relate, you can make sure it aligns with the users and their needs. By making sense of the data objects in a model, it becomes easier to reconstruct them according to the users mental model.

In terms of Service Design, being able to visualize services in operations flows to see how the application will help to see how the technology integrates with the service. User Journeys work in a very similar fashion to Service Blueprints, however, a User Journey is for one user and through the lens of the user and the Service Blueprint is through the lens of the organization. This allows us to understand the needs of the system and make it work for more efficiently, not just the singular user. When working at the organization level, seeing how the whole service comes together, helps you better understand all the requirements, and the effect of your design decisions, and how the different user types might use the same flow.

This leads to point number 4 which is being able to document these business requirements visually in enough detail to design a solution. Most projects I have been on have a Business System Analyst (BA or BSA) on your project. You will both be working together on this, but the BA will be the owner of the requirements, and your tightest collaborator, working on features and analysis of the system.

Designing Flexibly vs Tailor Made:

Often when we are designing for a consumer flow, we design a tailor made solution for a particular group, anticipating every need. When you get into Enterprise, you need to think flexibly because the amount of work it will take to create unique solutions for every user group. In addition, if you are working on a SAAS or cloud product, you need to accommodate for all different types of implementations and customizations that each organization will want to make. Different people need different permission levels within a product necessitating varying access to functions in an application. In addition, the flow of tasks is often fluid and changing, and often in different order. Systems like Microsoft Fluent Design System and Salesforce Lightning are designed flexibly to be used in any context and can be applied by an administrator without dev help.

Designing modules and components that can work in multiple contexts, will make it easier to add and manage the module in the system. For instance, a communication module — which shows all the emails, texts and communication with a customer — may be used at a customer level, an order level or a user level. Developing flexible modules decreases level of effort, and increases reusability and consistency. Modules in an Enterprise system typically take a bit longer to develop in Enterprise due to the complex nature, so if you make it as reusable as possible, it will save time and development effort in the long run, just like any design system.

The challenge then becomes figuring out where in a nonlinear flow a user may need entry into the particular task they are trying to satisfy. I like to think of it like the difference between a categorical taxonomy and a tag system. A categorical taxonomy implies that an item lives in one place, and is organized by drilling down to the item. A tag based taxonomy implies that an item has multiple facets and can be accessed from multiple avenues. Think more like “tags,” less like “categories.”

So we think of quick micro tasks that make up a larger task, and add entry points. For instance, if a customer service rep is looking up a customer name, looking at their history, reading notes, and then creating a ticket and sending an inquiry. This is all one “task,” but there are several “micro tasks” that you can evaluate a design for one by one once you have identified where the issue lies.

Access to the micro tasks are key. You may have the same button multiple times in various places, and it is cluttering and duplicating the action, and you may be right. But in Enterprise apps, due to the multiple entry points might make sense to approach it this way even if it does seem like duplication. Users in Enterprise apps often need to be able to enter a workflow from various points because their workflows are variable.

Different types of Enterprise applications

With all of this “Enterprise” information, there are different types of Enterprise projects, and they all have different needs. If you are working on a SAAS or cloud application, it will be implemented by a company, and thus will need a great deal of flexibility in implementation. An internal CRM will have a 360 view of a customer linking to other internal systems to all the central data.

As a common thread, we will stick with the definition of:
“A complex piece of software with lots of data, various distinct user groups, and several non-linear complex tasks that workers use to get work done.”

This covers all types of Enterprise applications, both internal and 3rd party. SAAS and Cloud products, CRM’s, Enterprise platforms, Analytics packages, Accounting Software, Email programs, and the like. As a result, there are set “classifications” that the average Enterprise will have.

While this is no means an exhaustive list, these are some of standard ones I have run across in my travels. Many of these apps are platforms that cover multiple categories, however, for this exercise, I have simplified them based on function and main class of the application. This is a mix of SMB and Enterprise Apps. For simplification, I am including both, because the SMB apps are usually more “consumer like” and can provide inspiration for a better experience.

These applications may be:
• Internal : Applications developed internally
• Purchased : Purchased software or SAAS product
• Customized : Off-the-shelf apps which have a different or modified
presentation layer.
• Combination : part Purchased, part Customized, part Internal

Examples of typical classes of Enterprise applications:

CRM (Customer relationship manager) — houses all information on a customer, primarily used by Sales and Customer Care teams to understand customer context and history. Typically in integrated with communication, ticketing, reporting and/or marketing platforms.
Examples: Pipedrive, Sugar CRM, Insightly, FreshSales

ERP (Enterprise Relationship Program) : These are large complex platforms that incorporate elements of all the different applications into a singular suite in order to customize an implementation and have all the pieces integrated. Modern ERP’s have a complete set of modules and a design patterns, which you can leverage to create solutions quickly.
Examples: Microsoft Dynamics, Salesforce Lightning, NetSuite, Zoho, SAP

CMS (Content Management Systems) : A system for publishing content or creating HTML pages or emails. typically used by content and marketing teams to publish content on the web, applications and social media.
Examples: SharePoint, Drupal, WordPress

Calendar and Scheduling : Apps that show you when events are, and often the ability to schedule one or multiple people.
Examples: Calendly, Time Trade, GCal

Analytics/Reporting : These apps can be Sales, Behavior Tracking, Reporting or visualizing any type of data. They are typically used by the entire organization, but will have different views depending on the user type — For example a view for the product team with details, and a view for Executives with less.
Examples: Tableau, Google Analytics

Productivity Suite : These apps are very straightforward — the swiss army knife that allows any user to create content for work — Word docs, Spreadsheets, etc. Typically integrates with communication for sharing.
Examples: Office 365, Airtable, G-Suite

Accounting/Invoicing : These applications are for keeping track of sales and orders. There are typically more specialized software the Accounting team will use to keep track of sales and money, especially for tax purposes, but this can be used by all parties to track the details of a sale.
Examples: Xero, Quickbooks, NetSuite, Acumatica

Support/Ticketing : These are for tracking defects in a system. This can be a Support application — whereby Customer Care Reps enter tickets to keep track of customer errors, or a bug reporting system, and/or tech support. They often have “cases” or tickets as a central object in their system, which are issues that need resolution, which are assigned to people to solve.
Examples: Zendesk, Jira

E-Commerce : Applications that allow companies to create inventory, sell products and often run reports. May also integrate with a POS system.
Examples: Magento, SAP Hybris, Shopify

Intranet/Wiki : Applications that companies use as a hub for all employees to find other team members, communicate with others, find out policies and benefits and access other software.
Examples: Sharepoint, Confluence, Igloo

POS (Point of Sale): Think of this as a complex cash register. Employees at a physical location ring up items — can be food or retail purchases — and then take payment.
Examples: Swift POS, SquareUp, Vend

Communication : These apps are to communicate internally or externally and have many different forms — chat, email, messaging, etc. They all have some sort of “thread” and someone is able to send a message and notify another user of the message where that user can send a response.
Examples: Slack, Email, Text, Facebook Messenger, LiveChat, Intercom

Project Management : A list of tasks and status of a “project.” This can mean anything. When I worked in the Real Estate space, and we considered a home sale a “project” — whereby you had documents that needed to be completed within a period of time, and we needed to track the progress towards done. If it has tasks, deadlines, scheduling, and a goal — it’s a project.
Examples: Asana, Wrike, Monday, Microsoft Project, Trello

Automation: These applications can be anything whereby the user creates an automation, and then is able to monitor and get reporting on the system. This can be a marketing automation or a process automation or data transfer. If you can create a custom flow and have the computer do all the work then it is an automation software project.
Examples: ServiceNow, Salesforce Marketing Cloud, Autopilot

System Monitoring: These are software that lets a person see how a system is behaving in order for them to make adjustments. This could be an airplane cockpit, a heartbeat monitor, a supply chain management or a telephony app. The idea is to let the human at the end see what is happening, and if there is a problem to make it known.

Specialty Apps: A specialty app is used by a specific group, for a very specific task. While specialty apps may combine a few of the above into a specific context, the difference here is that it is typically for a very technical specific audience, which has little or no need to communicate the details to the rest of the company. Think of your design software falling into this category. While there are ways to “export” the designs to be consumed, Photoshop is definitely geared toward the designer to get work done.

As you can see, these applications are combined together to create an “experience” and workflow for a worker. A sales person might use the CRM to keep track of his/her leads and sales, but will use a Reporting modules to see sales and Communication modules to email information. On top of that, a salesperson is also doing these things in tandem to try and accomplish something bigger than the individual task. Furthermore, the salesperson is not going to get a specific “sales” CRM (although they do exist).

Each of those teams will have several people doing very different things with the data. A Customer Care rep will look at the customer information only to validate an identity and then look at orders, whereas a Salesperson will want to see when the customer’s birthday is in order to send a surprise. As thus, you often have several different groups which need to use the same application, often with different needs. However, we need a singular app or platform with views that accommodate each particular user need to mold to the task at the right time.

We need to balance the organization of information, action buttons, and pacing to match the needs of the user.

Another critical piece of information on these software pieces, is that often they are not purchased by the people who use them. So, if you are using a SAAS software the app needs to “look impressive” for the purchaser, and perform impressive to keep the team happy. The SAAS software also comes with the challenge of needing to be customizable for various types of users, which means that customization on these types of projects will be key, for sales, support and performance of the software.

Integration and the evaluation of the whole experience.

Now, the challenge becomes distilling this down to something digestible, but there is one more topic to cover: Integration. With Enterprise applications in particular, there needs to be integration points and consideration of the whole experience. As stated above, the Enterprise applications are very rarely used in isolation for a specific task, and more often than not are used in tandem.

Think about the Salesperson example above. We need to not only consider the application we are working on, but also how the network effect limits or prohibits productivity as a whole. If I am creating new orders, and my order system and my CRM are not connected, then I have segregated data, but I also duplicate the work by reentering the contact information. We want to be able to look at the entire experience to see how the tools interact with one another, so as not to create work silos that tank productivity and extensibility of the data.

When we are thinking of evaluation methods, we will want to be able to create artifacts to review the following in order to evaluate the experience:

1) User Journey and Context

2) Service Design and Operations Flow

3) Data Objects, Application Ecosystems and Relationships

4) Task Analysis and Opportunities for consolidation

5) UI Flows and Usability

Break the experience down to the level of zoom

1) Organization/System level — The highest levels of the software. This will involve understanding all the different user groups at a high level, task analysis and prioritization across all user groups, and data analysis of high level objects.

2) User Level — This level involves breaking down a specific problem into its tasks, and understanding the issues that affect productivity. While you will need to understand data objects, in this case, they are typically a smaller set, and be able to organize the attribute level to organize the information. The journey of that particular flow and where there are problems within that journey are of greatest interest to pinpoint for deeper investigation, as well as the service pipeline that might affect your design.

3) Task/UI level: Analysis at these levels occur when there is an application that is up and running well, but needs to be fine tunes. This is going to be actual usability testing for a flow, combined with contextual understanding and interviews with the user(s).

These levels are cumulative, and in order to get to UI level or execution level details, you will need to work your way down. For example, I was on a project, and my creative brief from my boss was “Salesforce… take a look at it.” Seeing as her request was very broad, and had very little detail, I had to start at the organization level, and work my way down, by starting with identifying the issues that were the biggest across all the user groups, then finding out which of the tasks needed to be improved. After that I was able to tackle the UI pieces that I was responsible for myself in execution. To get from organization to UI takes a few rounds of refinement, but due to the complexity of the system, it helps break it into digestible chunks.

When you are approaching a system, if it is too big to digest in one round of work, you will need to break it down. You need to get down to the tasks or goals for you to solve first before you can solve. This can be a little different than Consumer level design, whereby the tasks are often simpler and linear, and you are usually solving for less complex user types and needs. Enterprise apps typically have lots of business rules, and complex user types doing lots of different functions, and it takes time to understand those, and decide where to start, therefore, the approach really should be multi-level.

In my experience of working on an internal applications and customized applications in particular, I have often walked into an organization where systems has been devoid of UX for a long time — which means the system needs to be analyzed starting the organization level and worked down to UI. The Enterprise product and tech teams were fielding requests, and collecting business requirements, and problem solving with the business owner directly. This typically means “add this button here so I can do x while I am on this screen.”

As of 2018 survey by UX Pin of 3,157 UX, Product and Engineers, only 26% of teams have had a UX practice for more than 5 years. In this same survey, the no 1 problem teams were working on was consistency. This can be due to the historic nature of other disciplines owning UX in pieces, but not looking at the entire experience.

Enterprise software can be an exciting new challenge for those designing consumer apps who are looking for new challenges. Hopefully, this article has given you a place to start when you have to get a handle on a large app, and form a plan of attack on approach.

Enterprise UX Design: Breaking down an evaluation was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.