Source: Unsplash.com

7 MORE Things To Prepare For As An Interaction Designer In Enterprise Software

When I first wrote 7 Things to Prepare For As An Interaction Designer In Enterprise Software, I was in the early stages of a multi-year project that impacted all areas of a large Fortune 500 company. Since then, a lot has happened:

  • Our team has embraced user centered design
  • Our project champions are now aligned with our design goals
  • Feedback has been encouraging: users find our software to be easy, intuitive and SIMPLE (three words that are hard to come by around here)

Because of all the positive feedback I received from my first article, I thought it would be nice to put together a second list of items that should be considered before diving head long into designing for enterprise software.

1) Your organization may have an internal usability team that nobody knows about

There is only one reason why no one cares about your project: it’s internal facing. Sure, your organization may have an external UX team, but they cost $$$ and are reserved for projects that touch customers, not employees.

What you can do about it

Do some research. It’s possible that your organization has an internal group dedicated to usability and UX that costs nothing for your project. Reach out to them and set up a meeting. It’s possible they could offer a full time team member for your project depending on their size.

I recommend this approach for a few reasons:

  • You can do more with your bandwidth. If you are able to manage/work alongside a highly trained team, you can spend more time on strategy and collaborate on low level details.
  • Second set of eyes. The (very tiny) downside of working so close to the requirements is that you start making assumptions around what’s best for the business — leading to shortcuts in research and testing.
  • Clout. Having a set of internal ‘experts’ working alongside you gives your research and work more credibility. They can rag on you for advocating UX if it isn’t your primary role, but they can’t rag on a seasoned professional hired by your orginization.

2) The majority of your users are still using IE7

This. This right here sucks.

What you can do about it.

Manage your expectations. Pat yourself on the back. Keep it simple. Keep it minimal. Less is more.

3) Most business analysts know nothing about software design

My project recently took on a third BA, and during one of our initial conversations, I mentioned that she would have the opportunity to collaborate on designing wireframes for the requirements she had collected. After a few minutes, I come to find out that she had never heard of a wireframe nor how it related to an application. When I pressed her as to why she hadn’t come across this in her training, she replied that she never tried learning because ‘she wasn’t creative’ and ‘didn’t know the first thing about design stuff.’

What you can do about it

BA’s tend to come from technical or business backgrounds, and their engagement with software revolves around what a user WANTS, not HOW a want should be displayed or experienced in a digital environment. It’s possible that the BA(s) you are working with have never been exposed to design thinking or user centered design.

If you are in a position to do so, have a few training sessions and create a small curriculum for your team. Cover the basics and relate them back to your project. BA’s have not caught on because they are unfamiliar with the subject matter, not because they are actively avoiding it.

Here are some great resources to get you started:

ZURB’s design triggers

ABOUT FACE 3

The Design Of Everyday Things

4) Executives are using iPads

The organization I currently work with has a small subset of employees that use iPads. Many of them are high up in the organization and have a significant impact on project definition and scope.

So, it would surprise absolutely no one that my team started to receive design requests from project sponsors a few months after our first major release. They wanted to know why our software didn’t look like all the other apps out there!

What you can do about it

Leverage this for your evangelism. MANY of your project sponsors are using devices that are light years ahead of what your technology is capable of. Once they realize what it takes to design something within their realm of expectation, they will start to get vocal and press your project leads. Soon, members of your team will take these requests seriously. Even if the motivator is fear, it’s a good start.

(This was a special gift awarded to me by the UX gods. Movement in this area really took off once the executives and project champions started advocating for better design. )

5) Stakeholders can be territorial

My application rolled out to over 1500 employees in January. How many people do you think I interviewed for requirements? Around 7 to 10.

Now, by design, these 7–10 stakeholders were all part of a single group — the group responsible for governance. In reality, there were 15 other groups, but the governance team ignored our request to gather feedback from all of them.

The result? We had to go back 5 months later and redevelop key areas of the application because a large majority of the user base was not represented in the final design of the application.

What you can do about it

While the saying ‘there are too many cooks in the kitchen’ is accurate, it’s still important to include key stakeholders in your process. All to frequently, key stakeholders responsible for supplying business requirements actively exclude stakeholders they do not considered ‘key’.

Do your best to include all stakeholders in the requirements gathering process. If a group you are working with wants to actively exclude another group, I recommend you sit down with them and try to persuade them otherwise. If that doesn’t work, I recommend you disregard their feedback, use your judgement, and reach out to whomever you feel is necessary to adequately conduct your research.

If you are working with multiple groups with conflicting priorities, rank each group in order of priority/size/whatever metric you wish and weigh the requirements against the values you’ve assigned.

6) Your hard work and research will be nothing more than a suggestion

At the end of the day, you have no control over how your research will be incorporated into the final build. I work with a team overseas, and my experience is that all the requirements and design work gets thrown into a box and assembled based on a number of factors that I am not privy to.

What you can do about it

Many overseas teams do not read documentation you supply with your requirements, and many onshore teams do not have to follow your research because the majority of projects are driven by technology initiatives, so there is no pressure for developers to do ‘non-functional’ work (as they like to call it). We at my project take an approach that has its pros and cons:

We have wireframes with a big red disclaimer that reads ‘THESE ARE CONCEPTUAL’. This allows us the freedom to make changes after they are unveiled and realign them with our personas and design research. Every project is different, but without this, we would not be able to have a discussion after the unveiling and it would be disastrous.

The downside to this approach is that our wireframes are merely suggestion. That being said, my experience is that my wireframes are hardly followed anyway — so best to get it out in the open and use it to your advantage.

7) If you are persistent, your team WILL come around!

Every team is different, and there are some situations and projects that will make it nearly impossible for you to have your team incorporate a UX workflow…But if I could get my team on the bandwagon in 6 months than so can you!

What you can do about it

Think outside the box.

What has worked for me:

  • Align yourself with powerful stakeholders and educate them WITHOUT going over anyone on your team.
  • Give stakeholders low to medium fidelity, clickable prototypes before ANY development takes place. This is outside of most project workflows that are waterfall or some hybrid of agile/waterfall. Not only will this save time and money down the line, but it is also powerful evidence for why the work we do is so important. If executed well, stakeholders will feel validated, part of the decision making process, and they will respect your judgement moving forward.
  • Don’t let up. I became know as that annoying guy that constantly asked stupid questions like ‘What about the user?’ and ‘Where did that button come from?’ and ‘Why am I just finding out about this now?!’ Sure, I was picked on from time to time, but my passion ultimately persuaded the team and project champions to consider my approach. It also showed I had conviction, so that’s nice.
  • Document your work. This may sound obvious, but document negative user feedback and tie it back to your research. If your suggestions are not implemented and a change request or some redevelopment is initiated, show the direct cost of not designing to what you obtained through your research (whether that cost be monetary, time, or user satisfaction).

Since my first post, I’ve received messages from experts in the field expressing that they too come up against similar issues on a daily basis. So, I ask you all, what do you deal with when designing for enterprise software? How do you resolve what you are dealing with? Does it involve some sort of in-office therapy? Outside consulting? Banging your head against the wall? I would love to hear!

All The Best,

The Happy Product Strategist

Show your support

Clapping shows how much you appreciated Dan Simerman’s story.