DEV Community: Thandi

Enterprise Design: Anything but Typical

Thandi — Tue, 18 Aug 2020 09:04:24 +0000

If you’re anything like me, you started out your design career at an agency. In an agency environment, the kinds of projects you work on are things like brand websites, marketing campaigns and occasionally an interesting business problem – interesting, but generally discrete and short-lived.

I moved from an agency into product, client-side, as they say, and it’s a different ball game. You own or work on a small part of a larger product, and the challenges include consistency across teams. In my case, there was an excellent rhythm of design and feedback, and though I was focusing on a small slice of a large (banking) application – it was deeply focused rather than at a high level. I was able to chat to end users each week and gained a real understanding of their needs and challenges.

At Sonalake, I design B2B and enterprise level software. The design challenges in this space are unique to it and certainly different from those I encountered in my previous roles. In this post, I want to share some of the challenges, and some of the things I’ve learned along the way.

The Customer is Often Not the User

Our clients’ customers are not their users. Considering they’re B2B (Business to Business) and not B2C (Business to Customer), this might seem like a silly distinction, but it really isn’t. When your business is selling to another business, the users’ voice is easily lost. There’s at least one additional category of stakeholder to consider.

If you step back and look at it; from my clients’ perspective, they’re doing all the right things and being customer-centric; they’re defining requirements collaboratively. But remember, that the client is not the user – and the account manager/vendor manager/business development manager is not the person who spends 8 hours a day using the software.

Everybody thinks that they know what the users need, but they don’t. The ugly truth is that decisions are made based on personal opinion, biases, ease of implementation, and cost factors.

As a software partner, this is challenging. We provide a service to our client – and they provide a service to their clients who, in turn, maybe be providing a service to their customers. The users (employees) that rely on the software are generally not consulted. But they’re the ones best positioned to help improve efficiency, speed or service delivery with their insights.

Investing in up-front user research, and testing throughout the design process, results in a far better product for the actual users. Realistically, there are no shortcuts through design practice, but there are sources of information that can help steer the direction and inform design decisions. The following describe some to consider.

Customer Care Staff

It would be remiss to overlook the role that your support team plays as a source of valuable insight. They are on the front line, answering questions and helping customers and often have the best idea of where users are struggling with the software. A good place to start is to analyse the queries or complaints care staff receive and identify common threads and themes. But remember, not all people who use the software are calling in with problems. So taking the themes from customer care is indicative, rather than diagnostic.

In a similar vein, you could analyse the responses from your Help / Contact us sections of your service; if you can identify a pattern, or patterns, in feedback or complaints then it might point to something that warrants deeper investigation.

Analytics

Your analytics can give you great insights, but its value depends on what you’re measuring. Useful sources include user flows, common errors, time spent by users on steps or tasks. Analysing which form fields are most, and least, used can also be valuable in helping optimise flows.

A/B testing

A/B testing is the practice of randomly providing users with one of two variants of parts of an application user interface. By analysing how users interact with the software it is possible to make an assessment of which variant provides a better user experience. You can measure the interaction in many ways, but speed and accuracy of task completion is common.

Visual Hierarchy and Information Density

Another distinction between B2C and enterprise software is in the way they look, and, in particular, how much information is packed into individual pages. In the non-enterprise world, simplicity is the main aim. Designers strive for clean pages and use white space, not only for aesthetic reasons, but also to prioritise legibility and readability, clarify relationships, draw attention.

Not so in the B2B world. It’s not because we don’t love that aesthetic, but it’s got to do with practicality. A hard lesson I have had to learn designing enterprise software is that everything I valued before – padding, visual hierarchy, focused steps don’t have the same relative importance in enterprise software.

Information Density

Imagine you work with some software and are processing customers daily, many times over. Now imagine that every process is 10 steps long, and within each step there are ten things to do; for example, check, click on, fill in. This isn’t an unusual number of interactions in the enterprise world, and the only thing more annoying than a long process is having to do this over more pages than necessary, or with more clicks.

Counting clicks is not as important in B2C software, because the processes are generally not overly complicated. It’s common practice within B2C to build sparse workflows; think about how many apps you know that filling in your name and your email address are on different pages – it’s a common design pattern.

With enterprise though, there is so much data to capture and process that splitting up the process up into too many steps is frustrating. Enterprise users cannot operate efficiently when only making one choice per screen; between load times and the fact that there are often 100+ choices, it would just take too long to complete an end-to-end process.

So I’ve had to embrace things like “action button bars” that present multiple options, designing for keyboard navigation, and concealed details that, for example, show on rollover for example. I’ve also had to accept that body font can’t be as large as it would be on an app or public website and things need to be closer together, in general.

Navigation and Visual Hierarchy

As you can imagine, when there are multiple tasks to be completed on a screen, the order and flow of those things is very tricky to get right. I’ve been told many times that “there is no particular order” and that’s a strange concept for me to internalise and design around. What it really means is that despite there being a seemingly natural user journey, it can also be used in ad-hoc, difficult-to-predict ways.

At the same time, when the options are all equally weighted – there is virtually no visible hierarchy. Navigation is one of the most important and difficult aspects of any design, and enterprise software just doesn’t (and can’t) play by the same rules – it’s got a different use case, and has to be treated differently.

However, even within pages that have no particular input order, there are small things that can be done to keep the users’ orientation. For example, highlighting or emphasising the panel they’re currently on, and making sure that there is consistency across components helps a lot.

In some cases, you have to push back and/or dig deeper. Remember that just because something has always been done one way, doesn’t mean it can’t be improved. Questioning the necessity of fields or steps can reveal excess, and any trimming down is helpful. For example, capturing a landline, mobile phone and work phone number may not actually be necessary.

Configurability

I’ve not yet met an enterprise client that doesn’t offer different packaging or configurations to their customers. Sometimes this is role dependent, where different user roles have access to different features, but quite often it can be even more complex. For example, where customers can configure almost everything in the interface, to suit their specific needs.

This makes design extra difficult because it means that you have to think of design elements as pieces that can be composed by users in numerous ways. It also means that typical design tropes such as page templates are not really relevant – and without predictable page layouts, consistency is always at risk.

To address this, it helps to break the designs down into their constituent parts, for example text, buttons, icons, colours, cards, panels, making sure that each of these are consistent and can work together in a configurable way. What I’ve found helpful, and necessary, is to consider states for each: empty, error, filled (minimum), filled (maximum) to try and test whether the design of the components will fit into the sections in all their instantiations. Then, placing the various component states alongside other panels/components helps determine how pages will look in different scenarios.

There’s always a “worst case scenario” and a “best case scenario” – most of the time, the realistic use case is somewhere in the middle. All need to be considered though. Of course this means more effort upfront, but it helps down the line when new or previously undiscovered use cases are brought to light.

Conclusion

Enterprise design is unlike B2C design because typical guidelines around navigation, flow, visual hierarchy and density are simply not applicable and would do more harm than good. This comes down the most fundamental design principle: design with the user in mind. It can sometimes be difficult to do that in enterprise scenarios, so we need to find feedback where we can, but the other reason is because enterprise software is generally configurable, and so the user groups often have different expectations and experiences.

While it may be relevant in some products, configurability is often a cop-out. It’s seen easier than putting in the effort into understanding the users and their needs deeply. In reality, making software configurable exponentially increases the development complexity and isn’t always widely used. Investing in user research upfront (and throughout) results in much clearer requirements, like whether configurability is really necessary. Even where it is, the rest of the product strategy will be much more aligned with the users and that’s a win-win for all.

Battle of the Pixels: How we chose a new design tool

Thandi — Tue, 28 Apr 2020 07:45:35 +0000

Here at Sonalake we frequently review and update the way we work to match the evolving needs of our clients and emerging industry standards. Recently we had experienced some frustration with our go-to design tool, Adobe XD. Our team has grown, the sorts of work we’re doing has shifted and despite only using it for 2 years, our needs have changed – we need a tool that allows for better collaboration; both between multiple designers as well as with the broader team, and so it was time to evaluate our options. In this article, I’m going to take you through our journey of assessing and choosing our new design tool. I’ll also tell you how it has already improved our design process.

Creating and Collaborating

Product design is not limited to placing pixels on a screen. While that is a crucial function, there’s more to it than that, and it often requires the use of many different tools for a variety of tasks. There are a bunch of typical steps, including workshops, wireframes, UI mockups, and prototypes. We produce many artefacts and sharing them with clients is one part of the job, but testing them with users and handing them over for development is also part of the journey.

Traditionally, design tools focused on being able to “create” things. Designers would create shapes, add colour etc. Typically, the exports of these tools were Vectors – images, or slices of images that could then be coded around. This started changing when CSS was introduced. No longer did developers need images, but they needed values, like the Hex value of a colour or the specific size, type and fonts used in the copy.

Most design tools are adequate at the “create stuff” aspect. Not a huge amount has changed in that space for a while. But what has changed are tools that deal with the rest of the steps:

Prototyping
Testing
Hand-off
Version Control & Asset Management

^{Courtesy of Scale Venture Partners: https://www.scalevp.com/blog/design-in-the-enterprise}

For each task in the design, there are countless tools. And within the industry, there is a lot of competition. Not all design tools are relevant for each kind of team though, and we were looking for a tool that did more than our current one.

One of the biggest gaps we face is Hand-off – where we handover the designs to the developers who will bring them to life. Over the years this process has become less manual – products were introduced to handle this. The most famous is Zeplin, which “reads” the designs and outputs the values. But the problem is that it’s another tool, which means another licence.

Another requirement is the need to manage design libraries and account for version control. This is a challenge that developers solved ages ago, by using Git – which is a way of merging different streams of code into the same base.

As products grew, so did design teams and the software couldn’t always keep up. When teams of even 2 are working on the same project, managing the “latest” can be tough: having loads of versioned files, and needing to keep track of many changes to many elements and components can be a full-time job.

Thankfully, tools started coming out to manage this. The most well known is Abstract but, again, it’s separate and requires another licence.

We found ourselves in a spot where we wanted software that helped with the gaps, but preferably didn’t want to have 3-4 tools to deal with a design flow.

“I’ll Just Leave This With You”

We started off by narrowing it down to the 6 we thought showed the most promise – either because they’re popular or because they’re well funded.

Then we looked at their respective functionality. Looking at this, you’d think that Sketch is the least useful. It’s not – in fact it’s the most popular tool out there, but where it falls short is that it’s not an all-in-one tool. Rather it works with other tools (like Zeplin and Abstract) while it’s slowly growing into an all-in-one. It also doesn’t support Windows.

Noticeably, XD deals with Design as well as Prototyping. But where it falls short is that most other tools – including ones that deal with version control or handoff don’t support XD files. This is a major downside to XD, and it’s not their fault. XD is expensive though, and that is always a consideration.

So we knocked Sketch and XD off the list early. We then knocked Modulz off, because it’s not available yet. They’re only going into open Beta now and we needed a tool sooner rather than later.

The final showdown

Finally, we knocked UXpin out. While, in theory, it offered all the functionality we needed, it didn’t “feel right”. It had weird navigation and didn’t work in the same way as other design tools. So because of that, we are left with just two: Webflow and Figma.

The biggest difference between them is that Figma is a more traditional Design Tool, while Webflow is a visual code editor. Webflow sells itself as a way to develop code, but using design software. It exports code rather than vectors or images. Figma is more traditional. But what it sells is the ability for collaboration and design system management.

So I set myself a test to see which would yield the best results. I went for something fairly simple – redesigning Sonalake’s home page.

On Webflow, I spent the better part of a week watching tutorials, thinking that I’ve totally got this. And… mustered up about half a page worth of content. Honestly, it kicked my butt. Because it mimics the structure and features of HTML and CSS, it was difficult to pick up as a designer.

This tool seems more suitable for people who already have a foundation in front-end development. Even with a decent understanding of code structure, the metaphor on which it is based is too far of a jump for me. I’d be interested in continuing to improve my use of the tool, but it doesn’t come close to the speed and ease I need everyday.

And the winner is…

I then moved to Figma and got out a full homepage within half a day, including some time for basic onboarding and exploring. So in that sense, because of the comfort of “knowing” the tool and the speed at which I could work, it was the clear winner.

But there are some cool things within Figma that also contributed to the decision. Multiple people can work on the same files at the same time. That doesn’t sound super useful, but often design files get pretty large and multiple screens are involved. So sharing the load, traditionally, was very difficult. We’d have to create copies of files, and then copy over the work into a Master file. Sharing the latest components or elements between distributed files is a massive pain, and is one of the reasons we wanted to explore new tools to begin with.

The other big feature is that you can create and share design libraries for the team. This means that not only can we work on the same files, but we can create multiple files for different projects that share a library – useful when you have multiple projects for the same client.

In Figma, you can just directly add a component to the Team Library and that becomes the source. So if you change the component in the library, it updates everywhere. Equally, because it’s a separate file, it makes managing the design system easier. This has removed the need for an extra tool like Abstract.

As a company that works with different clients and multiple projects within each client, the hierarchy that Figma uses matches ours entirely. Within a Company, you can set up teams and projects. Within Projects, you can create multiple files as well as a Design System. So, you’re not just creating one design system for your team, but multiple design systems. This is exactly what we need.

So far, Figma has been a great tool for Sonalake. For projects both client-based as well as internal, we have been able to socialise the design work far more widely. All stakeholders/clients now have access to the relevant files, and because of the permission levels, can comment or ask questions where necessary. It also means that the files are only in the hands of the designers 😉

No Silver Bullet

The UI Development team are happy with it – the details they need are there, including spacing and size values alongside the usual colours and fonts. This has already reduced the need for extra tools, like Zeplin, which would also have previously needed updating and maintaining. At the same time the product owners can export the latest directly from the tool to share with other stakeholders, or just make comments on the work. This has made communication easier since we’re always talking about the same version.

No tool is perfect, and there are two noticeable downsides to Figma. The first is that the prototyping features are very basic – it only caters for basic click throughs which means to show a flow with many microinteractions or states, you have to duplicate entire pages and make changes (as opposed to UX Pin, where the layers of interactivity are separate from the main artboard).

The other con is that it is very heavy on memory and CPU. This may make large, complex projects tricky to manage, and we may need to find ways to mitigate that.

There are loads of features and tricks that we will need to still learn and a roadmap of updates to come, but so far Figma has ticked all the boxes for us because of how it has simplified our process and made collaboration simple.