Blog

biTools

Limitations of BI

Everyone loves a good dashboard. To be perfectly honest: dashboards can be stylish, dynamic, and inviting. And we have all heard many times that products need dashboards to bring that “cool factor.” But are dashboarding solutions really that useful? 

The term of art used is “visual analytics”. Dashboards allow someone to visually understand their data by leveraging human perception instead of cognition to process the relationship between a bunch of raw numbers. The emphasis on visual analytics has spawned an entire industry vertical of dashboards and Business Intelligence (BI) tools. But while these tools have helped users visualize their data, they often seem to feel lacking when used in practice. They seem to just fall short in solving real-world problems.

This article will focus on how BI-tools have limited utility for empowering knowledge workers to take actions. As a result, we need to start thinking about solutions that help us create products faster; where any visualization of data are there to provide context, and is in service of helping an end user to take actions.

But if you ask end-users of BI solutions, why do they dislike their visual analytics tools, they cite the inflexibility and complexity of use (even when they know what it is they want to do), or the difficulty in setting up a new BI project. And while those are all valid concerns, they do seem to run surprisingly close to the adage attributed (or misattributed) to Henry Ford:  “If you ask people how to improve their transportation, they will ask for a faster horse”. 

And this is what makes finding an effective dashboard solution so hard. When you only have a hammer (reporting tools), every problem looks like a nail. That hammer will never be the tool to deliver what they need.  

So given the frustration, do teams really need a simpler/better reporting solution or is the problem really something else?

So let’s take a step back… why do we need to understand our data? Daniel Rosenberg, design professor at SJSU states in his new book “UX MAGIC” that:

A dashboard visualizes summary information for a family of related objects. The information selected for placement in a dashboard must support decision making. If no decision is facilitated by the dashboard, then it is just artwork to impress executives, not real [Interaction Design].

Clearly, visualizations and BI are not an end in themselves. The GOAL of every user workflow that involves visual analytics is making a decision and then taking action without having to use a separate tool thus doing something with the new understanding, context, or conclusion. The visualizations are needed in service to the end-user learning or knowing what steps to take (and identifying which actions are required). Any attempt at visualization must be in service to supporting that action selection and decision. If you reach that decision to impact your business via any BI dashboard today, you must use one or many other tools to affect that change.

Example Use Case

We all have received that call from our bank, where there is a suspicious charge on our credit card… These calls come from the Financial Fraud Detection team, who monitor suspicious activity and take actions to respond. 

The job responsibilities and workflows that they need to accomplish consist of 3 main activities that result in taking action:

    • [context] monitor holistic views of the bank and its accounts
    • [understand] Identify compromised or suspicious activities/account(s) ASAP
    • [understand] Drill in to understand the context
    • [take action] Immediately take actions to remediate suspicious activity…in real-time

Notice that, like all applications, the monitoring and visualization-heavy workflows are only there in service to enable the Fraud Analyst to take an action. The use of visualizations (over a large and complex data table) is to speed up the analyst’s understanding by switching the human memory burden from cognition (which is slow) to visual perception (which is lighting fast) and get him/her to take appropriate action rapidly and accurately.

In this example, if all the Fraud Analyst had was a written report on the data at hand, the effort required to drill in, identify the problem and remediate it would be extremely difficult. The desired action would be separated from the context.  Success would depend on the chance that the analyst had exactly the right slice of data in front of them at this particular instant in time. Such a report (or such a constrained dashboard) would not provide the right context.  Beyond that instant, it is also unlikely that the report/dashboard would seamlessly fit in the workflows needed to come to an effective conclusion.

Thus we can see that “understanding a problem and then taking the right action” is the edge of BI provides. It is the first step in providing a useful application. The goal of such an application is to make an ACTIONABLE system. Any B2B product you buy will have visualizations, dashboards, or other visual workflows to help inform the end-user and guide them to take a step, make an action, move the needle. 

And this is why team after team is frustrated with BI and dashboarding solutions.  Whether or not the users can articulate their underlying pain point, they are looking for the application to support them in doing something actionable. Visualizations and dashboards are hit-and-miss.  If you are lucky, the action required is extremely light-weight. But just as easily they can confuse the user by throwing data together without providing a clear and simple actionable step to resolve the discovery. The need for visualizations is the symptom of the problem (data is very complex), not the cure (diagnosing a problem and coming up with an effective action/solution). The cure is to identify the problem that fits the domain of the business, to determine a solution that concurrently supports both the data and the business workflow, and finally to take actions that solve the problem and improve the business — Is it any wonder that the end-user often cannot articulate their frustration?  They have been given a hammer so to them every problem looks like a nail.  They need an entire different class of easy to use and affordable tool that does not yet exist until now.

Cover Image by Edho Pratama on Unsplash

needUIUXautomation

Why we need Automation for UI/UX

Getting good UI (the visual presentation) and UX (workflows) into production is hard. In many cases it is an order of magnitude harder than getting traditional software deployed. Hence, in the zero-sum game of engineering resources, many UI/UX efforts never get the necessary time or resources, and a lot of  usability efforts never see the light of day. Organizations simply give up on developing good UI/UX to drive their products and customer experiences, relying on their underlying technology (e.g., great data science, great hardware, or access to great data) to make a sale.

From what I have seen running a B2B software design studio, a fundamental blocker preventing the creation of UI/UX at scale is the absence of automation that can translate vision into code. Some low-code/no-code solutions (either programming meta-languages that procedurally generate UI, or drag and drop UI builders) have emerged that have attempted to solve the process of building UI, but these tools still require the user to translate objectives into structure. The yawning chasm is the lack of intent-based automation that does that heavy lifting for the development team.

This blog post discusses why the industry needs to solve Automation for UI/UX, and the unique challenges that stifle efforts to get front-end creation (both design and engineering) operationalized and launched into production. It goes on to describe the vacuum in the current low-code/no-code ecosystem.

Website creation

Thinking back to 20 (or even 10) years ago, companies would go through a multi-million dollar process to develop their website. Websites were mostly custom written projects, with designers, copy-editors, and engineers working long hours to get even the most basic web-presence. Geocities websites just wouldn’t cut it if you were a B2B corporation, As a result, businesses would either form large in-house teams, or contract out to specialized firms to design, build, update and maintain their website. 

Then in the mid 2000’s along came website Content Management Systems (CMS). CMSs ranged from highly customizable (Wordpress and Drupal) to end-to-end platforms (Squarespace, Wix, and Shopify). Regardless of their approach, CMSs managed a common thread of pain points. Most websites had a common set of use-cases, and through templates, the company’s marketing team (or even a single marketing person) could design, update, and maintain their own website.

The advantage of the template-based approach is that while most developers, marketing teams, and executives do not know how to create good UI/UX, the template ensured an acceptable minimum quality of consistent UI (and to a lesser degree, a reasonable UX) for both the website creation process and its use by customers once deployed. This was another reason why templates were so safe and effective (for product managers and development leads)..

This fundamentally changed the scope of the engineering work. Previously, engineers were responsible for creating everything down to the smallest button as well as developing unique content. Now, companies were able to focus their limited resources on creating custom content, running web-campaigns, and responding quickly to their customer’s needs and challenges.

employees are 125% more productive when inspired by high value work

– Time, Talent, Energy By Michael Mankins and Eric Garton

Some key benefits of CMS 

  • Marketing/Product-Management owned the website. They were empowered and ultimately responsible for what website is in production. This sense of ownership generally increased quality, as well as timely website updates. Decisions of when and how to create “custom” elements could be planned, discussed, and iterated on — thus improving quality and predictability.
  • Teams were able to iterate rapidly. No more chafing under the imposed slowness of months-long waterfall cycles. Most changes could be handled in minutes or hours, instead of days or weeks. Larger efforts could be telegraphed weeks or months in advance; customer feedback could be solicited and integrated; even A/B testing became possible for most companies.

Today, the CMS website based approach is the default for many (if not most) B2B companies.

Complexity of Web Applications

While templates and drag-and-drop editors (also known as WYSIWYG or what you see is what you get) work quite well for websites, they fail to deliver for web-based applications. Even though they are also displayed in a browser, web-based applications are a different beast.

Webpages are primarily for information and marketing, allowing a potential/existing customer to understand what the company offers. The available options for interactivity are generally low, often including  search functionality, pricing/payment or form completion.

Web applications, however, are full-fledged applications in their own right. They allow an end-user to perform tasks that are a critical part of their job. Users (especially business users) depend on complex workflows that contain stateful information across multiple screens. They must investigate, configure, troubleshoot, monitor, and visualize data to make critical decisions for a business, hospital, or infrastructure. Unlike websites, application usage must:

  • Allow users to discover and access data at multiple levels of granularity
  • Cross-link data to follow trails of information
  • Provide support/help systems for when users get stuck
  • Configure complex systems
  • Maintain state to reduce their cognitive load

Further complicating matters, the variation between products and the uniqueness of the information being presented to users means that web application templates are not up for the job. It is not that they haven’t been tried. There are tons of websites that sell web-app templates. Yet their adoption remains low, and the reason for that is plain to see. Unlike websites, where simply providing a variety of colors, pictures, and text is typically good enough, each web application is unique: their data, workflows, and use-cases cannot be addressed by a one-size-fits-all solution.

The complex relationships between constantly changing data and the evolving workflows to be executed means that static templates could never hope to keep up with all the possible paths and interactions a user may need to have. 

This degree of interaction and data complexity also limits the utility of drag-and-drop/WYSIWYG tools. Information hierarchies, workflows, layouts, and data visualizations (to name a few) must be carefully designed and considered. So even someone can drag and drop whatever they want, they still must decide WHAT to drag and WHERE to drag it to. Using these tools, a creating user can produce a “compilable” UI but through lack of expertise, time, and/or planning their design can violate basic UX and workflow principles.  As a result they are likely to be left with a poorly designed outcome. Thus, the adoption of this class of solutions has also been relegated to (at best) simple applications.

For teams to deliver high-quality products, the UI/UX must be deliberately designed and the UI must be carefully implemented by hand, using highly-skilled, highly-paid designers who have expertise in the architecture, creation and implementation of a quality user experience. This does not scale well.

The Promise of WYSIWYG

All the limitations above being considered, WYSIWYG tools are reasonably effective for one particular UI/UX use-case: the creation of limited or focused UI. In data science or natural language processing (NLP), these techniques work better when the data set’s scope / vocabulary is limited. For example, it is far easier to build a system that can understand only legal text or doctor’s notes (each of which has its own constrained structure/style), than a general purpose system that can understand any kind of unstructured text. By limiting the types of words, and the way those words can be used, these types of algorithms can be trained and optimized for more rigid and structured real-world usages. As a concrete example, medical dictation software (something that sounds like it should be a more recent solution) was used even in the 1990s simply because of the limited and constrained nature of doctor’s notes.

The same is true for WYSIWYG product UI creation. Consider data entry builders. These are helpful tools that allow people to create solutions for data entry; forms, basic summary statistics, and raw-record browsers (think spreadsheets). Likewise, tools that do basic data lookup and presentation (e.g., recipe finders) can also be designed and implemented with WYSIWYG. The behavior, layout and tasks of these applications are so limited in scope that these tools can constrain creating user behavior sufficiently, and, hence, can ensure a successful outcome. This is especially true when the UI layer is almost a mirror of the data layer: for example, form apps, that read and write to a basic relational database, so that their visual presentation is nearly identical to the underlying database schema.  In short, WYSIWYG can empower many users to build applications – but the scope and complexity of those apps (to ensure high quality UI and UX without having expertise) is limited.

The Consumerization of the Enterprise Experience

A new era is emerging in the B2B product space: the Consumerization of the Enterprise Experience. This is a combination of:

  • the proliferation of high-quality consumer software solutions;
  • the migration of tools from consumer into enterprise; and
  • some companies putting a premium on designing great UI/UX

These trends have resulted in a massive shift. Time and again, we see companies with fewer features and less (or no) history come in and dominate existing players. Disruptors like Box, Meraki, iPhone, PagerDuty, Gsuite, and Slack have supplanted and disrupted the existing markets simply because their look-and-feel, usability, and overall end-user experience felt like a well-designed consumer product (not like enterprise software). Employees expect and demand that their required business apps should be as useful and flexible as those they use at home on their computers, smart TVs, or phones.

To achieve this level of usability, these new applications have required a fairly significant upfront investment to set up, although once properly established, good UI/UX empowered these companies to leapfrog the competition.

Unfortunately, this is an extremely difficult strategy to execute on. Companies have limited resources: time, people, and budget. Even worse, there are increased talent shortages (lack of skill, high cost, and unrealized outsourcing help), broken internal processes (handoff delays, long development cycles, slippage no user feedback), and siloed solutions (existing tools are segregating teams) exacerbating the problem.

Access to developers is a bigger threat to business than access to capital
– Stripe

[Projects] experienced cost overruns of 150 to 200% [and] experienced time overruns of 200 to 300%
– The Standish Group

Even the most ardent supporters of good UI/UX simply may not be able to find the budget and people to successfully execute on time.

 

The Future is Automation

Templates don’t work. WYSIWYG won’t work. And manual efforts do not scale. Yet companies need to avoid being outmaneuvered by their competition. 

But take heart, help is on the way! We are Kleeen Software and we are leading the way to a revolution of how B2B companies design and build UI. 

As the tenets of our revolution, we have taken 3 key pillars:

  • Build More, Faster – even if you don’t have the UI/UX/Eng expertise
  • Make Stunning Designs – with usable, high-quality code
  • Free Up Your Resources – take your time, money and talent and put it towards developing your differentiating product features and showcasing your unique value proposition

Doing more with less, freeing up resources, and having reliably good output is the hallmark of the automation movement. 

And this is why the future for UI/UX is so bright. Numerous technologies under the very broad umbrella of “AI” have characteristics that could help turn the art of UI/UX into a repeatable science. Imagine a solution that could help teams plan, design, validate, code and deploy a product’s UI (with a compelling UX and workflows) – without creating a non-functional mockup or writing a line of code? How could multiple automation technologies come together to accelerate that process? 

Please watch this space for upcoming announcements as we (in stealth for now) work closely with a few design partners, helping them get their UI/UX visions into production at scale. 

If your team is working through similar challenges and are interested in joining our hands-on pilot, we’d love to chat.

Cover Image by Edho Pratama on Unsplash

forget

Tickets to Never Forget

Our last blog post discussed the “dreaded demo,” (integration, testing, QA, etc) and that its creation should define a sprint’s status as “complete.” 

But this is not the only thing that teams fail to account for when scoping a project or sprint. Those blind spots, the tasks that are not tracked, are the focus of this article. What is the work that must be done but is often either forgotten, not documented or not officially accounted for – thereby leading to sprint overruns or quality issues. Even worse, what are the assumed implicit tasks that end up being overlooked/un-discussed – leading to major visibility issues, ultimately, to incorrect assumptions (to assume makes an ASS out of U and ME) regarding the ultimate goal of your team.

Meetings

There is a movement to eliminate or minimize meetings (and meeting duration) currently ablaze on social media. But independent of this movement, most teams still have scheduled or predictable conversations that are part of most sprints/quarters/cadences. These can be sprint-related (planning, scoping, retrospectives), architectural planning to unify a direction, customer discussions/emails, reviews, company wide meetings etc. These all take time. And often, there is prep-work for each meeting. 

All of these interactions should be documented in tickets (JIRA, Gituhub, etc). If there is an Epic for a new feature, there should be a Story that is a planning meeting. And, there should be  another ticket for any prep work or research in preparation for that meeting; maybe a 3rd ticket to record meeting notes (or maybe one story with 3 tasks – the construct doesn’t matter). Just as the “trendy” fads for meetings (discussion of 30 minute meetings only, or no-slides, or send notes before hand) are capturing aspects OF those meetings, so should any ticket. If the meeting is 30 minutes, make sure the points for the meeting is corresponding. Prep work before hand/after should also have a ticket. And if that ticket wasn’t created at sprint planning, add it after – so that the sprint DOES REFLECT what actually happened  (and maybe why things ran over becomes clear). Consider adding a TAG for tickets made after the sprint started, to capture unexpected additions (not to assign blame but to uncover where work is coming from to make future predictions better).

People often leave these out as they feel secondary to your “real work” or because the point/hour system make them seem unimportant and therefore “invisible” in the broader scale of points.  But don’t let that fool you. These tickets don’t need to be large, or have high hours/points – but pretending they don’t exist is a big problem because that impacts productivity. Even company wide “all-hands” or an “off-site” takes time away. 

We are not advocating for MORE meetings or LESS all-hands…. But if your velocity is 65 points (or whatever your unit of measure happens to be), then if there is an all-day meeting or if monday is your retrospective/planning day, make sure you account for the time spent on those activities and to any foreseeable meetings (e.g. a design review, or architecture designing) that are part of the tasks assigned to a given sprint.

Debt

Deadlines exist and they are an inevitable like death and taxes. While we all would love to design and build n the most robust solution,sometimes we must use metaphorical duct-tape and spit to get out the door. These stop-gap measures lead to accrued technical-debt or design-debt and this is often forgotten once the deadline is met. To prevent the debt from getting out of control,  for every major release (of a product or feature) we create an epic called ABC-Debt. Every story in this epic is created when someone makes a short cut such that we all remember to refactoring and refinement later on. 

Therefore, before that team works on feature 2.0, we make sure to take technical debt off the backlog. If a team-member leaves (because there are other good jobs) a record of each  limitation exists within an annotated ticket and let the team know about blockers This isn’t perfect, and sometimes things are missed – but without recording your debt, you won’t know where there might be a hidden bomb in your product that could easily turn the next great feature from a 4 week project to a 6 month quagmire.

Project Management and Backlog Grooming

Someone always has to clean up the mess around the house. And every sprint the team makes a mess in the backlog. And just like the dishes, if you leave them dirty for too long they develop intelligence, invent fire, and start working against you.  Controlling that chaos is something that must happen every sprint.

 

In theory, every team has a project manager whose sole job is to run sprints, manage the backlog, etc. In theory, that person is using sprints to manage their own time as well. But we have found that most teams lack a project manager, leaving this work for the team leaders, so this tip applies to team leads as well. Set aside time for grooming every week (minor upkeeping) and a larger task every quarter (for a really deep clean). The Project-manager/team-lead will see things that slipped through fingers, find un-finished loose ends, and most importantly, keep abreast of all of the work your team HAS accomplished.

To validate that this clean-up has occurred (and wasn’t just ignored or paid lip service) ensure accountability. Team-leads/Project-Managers should report the current roadmap/schedule/delays to the VP of Product and/or Engineering at the end of every sprint. And at the end of each quarter, this should be reported to the CEO/GM. This hard-accounting is vital visibility that leadership needs to make decisions, and assures that that when the CEO says “hey when is X coming out” that prep work was (at worst) done 7 days ago, and is ready to surface right away (instead of hours of scrambling to answer a seemingly simple question).

Documentation

We were all taught in school to document our code and designs. Use good variable/layer names. Be consistent, and if anything, document first code/design after. Then we got to the real world and getting products done is the primary  task. But 9, 12, 18 months later (or if you are successful 5-10 years later), the team is unlikely to remember how a random function works (or the motivation behind a given design). That documented/written personal and/or group knowledge is invaluable and allows a team  to make changes faster and fix bugs more easily s even if the original author is no longer part of the team .

I know justifying documentation isn’t the point of this article, but seeing documentation fall by the wayside because it “was not a priority,” simply cannot be an excuse. When you are creating your projects, make sure to add some stories for documentation. Explicitly set aside time to annotate and explain what you created. Then when sprint planning occurs, or leadership wants to know how long something will take – you can look at the epic and say “this is a 2 sprint epic” and know that at the end of that sprint, it will be working AND be able to be supported.

In other words, start looking at sprint management as team management. It should capture everything your team must do to build and support your product – now and in the future.

CONCLUSION

So lets summarize some key take aways of things to ALWAYS track to better manage your company, more accurately predict releases, and ensure high-quality product creation:

  • Add sub-tasks to tickets for PRs, testing and integration as part of every ticket to amortize this work [from prior article]
  • Make internal live demos happen at the completion of every sprint [from prior article]
  • Make documentation of code and architecture happen (and track as tickets) as part of every sprint – and a completion criteria to prevent loss of tribal knowledge and allowing better collaboration between team-members
  • Add Sprint/work/ticket related meetings as tasks in your management system to track the full scope of how much time it takes to complete a project
  • Add company-wide meetings as part of your management system to track its impact on available points/time
  • Have a repository epic for technical debt (to be cleaned up) from the current release/feature as a method to track future work, and ensure it is picked up and resolved at the next opportunity
  • Every sprint AND quarter grooming should occur (and be tracked as tickets) to ensure a clean and organized back-log
  • To ensure visibility, better predict release schedules and make sure grooming occurs, present backlog and velocity information to VPs and CEO on a semi-regular basis

Cover Image by Fabrizio Frigeni on Unsplash

new years

Happy 2020 from Kleeen Software

Happy 2020 from Kleeen

From everyone at the Kleeen Software family to yours, we wish you a wonderful and successful 2020. 

Looking back at 2019, KS has had quite a year. Our company secured pre-seed funding, grown to 14 full time team members, 1 part-time, 2 interns, and a distinguished and accomplished board of advisers. We have launched our podcast series Kleeen Talk, and our blog series on how to better create mange and build b2b enterprise products.

Thank you to everyone (especially our friends and families) for making 2019 a year we can be proud of, and we look forward to 2020 bringing new challenges!

Cover Image by Roven Images on Unsplash

dreaddemo

The dreaded demo?

Nothing is more scary than the words “live demo.” As developers, designers and product managers – we all focus on how they fail. But what if –  and hear me out – we thought of demos as the mechanism by which we succeed? Whether you are presenting a new feature or in the development process, demos should be thought of as the forcing function to highlight what your product CAN do, and if done right, can be the way your team is brought together.

Let’s take a step back. What makes the live-demo occur? 

  • A customer wants to see the first iteration of a new feature that just was pushed out.
  • A product manager or upper management asks to review the latest build (which may or may not be stable)
  • An investor wants to know what you are doing with all their money

All of these demos make the assumption of a completed “something.” The demo is thought of as a culmination of some work, effort, and time. And, in many situations, it is the ONLY manifestation of  various components coming together.

During the panini press of a product, the team uncovers challenges with integrations, missing testing, edge-case checking, scripts and use-cases that have not yet been considered. Teams often find out that, yes, the spec could have been better, and yes communication with testing could have been better – but they weren’t and it wasn’t. Inevitably – unfortunately sometimes with some sleepness nights – these issues do get resolved.

Now imagine that instead of the external requirement for “live demos”, these were integral development process steps. What if every sprint’s goal was a fully integrated, front-to-back, live demo? This may mean that at the end of the sprint, your team MUST show a widget, for example, working in a real flow. If you are in middleware, the UI must consume your output, and you must handle real data from the backend. UI components must be able to be handled by someone that is not you. Back-end teams must handle real (not synthetic) data, with real parameters. And this must be done IN PUBLIC. This must be shown-off to both your peers and leadership.

Your testing and integration work has been amortized. People do not have (as many) sleepless nights. And your estimates for completion time now are more realistic as the explicitly factor in integration, testing, etc from the start. 

Jump 6 weeks in the future to the inevitable request to see the latest and greatest. You can dust off the latest build with confidence:you know it is stable, you know it is tested, and you know it will impress.

Cover Image Photo by S O C I A L . C U T on Unsplash

creativeNext

Creative Next Podcast Feature Article

Amy Yoshitsu, our VP of Design, was invited to participate on the Creative Next podcast series. Creative work is being disrupted by a seemingly unlikely force: automation. Each episode introduces you to a compelling innovator who offers a new perspective on critical issues related to our creative futures. 

Amy’s episode (SEASON 03 EPISODE 04) was entitled AI DESIGN FOR THE ENTERPRISE.

Amy Yoshitsu, a Founder and the Head of Design for Kleeen software, joins us to talk about their vision for using machine learning to automate a variety of design and engineering tasks for enterprise software.

Thank you Dirk Knemeyer for an engaging conversation and inviting us onto your program. 

designSystemChaos

Design Language System | Growth without Chaos

The arena of UX Design tools is growing – both in quantity and functionality – to empower designers to more precisely convey their creations to development teams. This expansion is driven by the increasing requirement to design and build visually pleasing products that allow instantaneous understanding of complex functionality. Consistency in component styling, micro-behavior, and page layouts are key to facilitating usability but they can also be challenging to maintain, especially as product requirements grows. To support the necessary clarity and thoughtfulness during the creation phase, more design teams are implementing design language systems. At minimum, these are libraries of components with documentation of the patterns and contexts that leverage the components.

While there are many possible tools for and approaches to building a design language system, this article will focus on tips when building upon an established component library in Sketch. In order to mitigate design language system confusion, of which teams can be at high-risk when rapidly iterating on mock ups and integrating new concepts and components, I have outlined three goals:

  1. Maintain component name consistency in library files so that they adhere to the constantly evolving vocabulary rules
  2. Allow designers to easily identify and customize subcomponents in mock ups (in Sketch, these are known as Overrides)
  3. Ensure designers are able to navigate the library files and have easy access to the most current version of each component 

While Sketch plugins (and products built to integrate with Sketch) will be the methods described below to achieve these goals, there are many other products that could provide the same functionality.

 

Maintaining Component  Names

As library components, known as Symbols in Sketch, increase in quantity and as their compositions change, vocabulary used in the names of both artboards and layers may need to be adjusted to more precisely describe categories and variant. No matter a design team’s naming protocol (clearly described in detail in design documentation, of course), groups of existing Symbols’ names will need to be modified. To do this, I recommend two Sketch plugins:

  1. 🕵🏻‍ Find and Replace Text plugin for Sketch by chriswetterman
  2. Rename it by Rodrigo Soares

Both plugins allow designers to use a Find and Replace functionality to update a string of text immediately for every instance; one-at-a-time per instance; or immediately for one or more selected artboards/layers. 

A few bonus advantages of each:

The Find and Replace Text plugin allows a designer to not only search at the page-, artboard- or layer-level, this functionality also applies to override values. This can be especially useful for updating placeholder text in nested Symbols. 

Find and Replace Text plugin can bulk modify override values.
Find and Replace Text plugin can bulk modify override values.

 

The Rename It plugin allows designers to not only add or modify custom text string prefixes and suffixes, but it also provides the option to integrate useful, dynamic values to artboard or layer names such as a layer’s width, a layer’s parent name or sequential numbering. 

Rename It plugin provides dynamic prefixes and suffixes.
Rename It plugin provides dynamic prefixes and suffixes.

 

Maintaining Easy Use of Overrides

Consistent naming and ordering of nested Symbol layers is vital to making sure that overrides are easy to modify during a designer’s workflow.  Often, it is useful for different Symbols to have the same names when they are nested in and layers of other Symbols, and when they perform the same semantic use in these Symbols. For example, different Symbols may be used for the purpose of ‘title’ within multiple, more complex Symbols, but, as a user of these components, a designer only needs to know in which field to input the ‘title value’ within the Overrides panel. Therefore, all “sub-Symbols” used for title-purposes, may have the layer name “Title”. Eventually, it may be necessary to change all nested Symbols/layer names from “Title” to “Header”. To do this, I recommend the Select Similar Layers plugin, by wonderbit, to instantly select all layers with name “Title”. (Without this plugin, the desired layers would have to be individually selected, which can be a tedious and time-consuming process especially when there are hundreds or more layers.) Then, either of the renaming plugins can do the rest.

Select Similar Layers by Name
Select Similar Layers by Name

 

Additionally, since the order of Symbol layers also facilitates better or worse usability for a  designer working with overrides, the Select Similar Layers plugin can also be useful in bulk reordering layers. For example, for designers immersed in cultures that read left-to-right, the overrides should be listed top-to-bottom based on the sub-Symbols’ layout order from  left-to-right or top-to-bottom. If a change to the library causes layers of the same name or properties to be out of order within multiple Symbols, the Select Similar Layers plugin can batch select to allow for a batch layer reorder. 

 

Ensuring Everyone is Synced 

Once all Symbols have been modified and organized at the artboard level and below, the page may have to be reorganized. The plugin Symbol Organizer, by Jason Burns automates this. It visually orders artboards by group level (identified by the “/” in each artboard name) as specified by the designer. By organizing the Symbol artboards, both in the layer list and visually in the main editing area, other designers should be able to easily navigate the library file.

Symbol Organizer plugin organizing artboards.
Symbol Organizer plugin organizing artboards.

For design teams larger than one, lone multifaceted designer, it is important to ensure that design language changes are accessible (as soon as possible) to all other team members. In order to avoid extra work or confusion that can be caused by using old or the wrong versions of components, there are now a growing number of tools that allow designers to sync, see a history of changes in, revert and see diffs between Sketch files; essentially these are “git for Sketch” tools. While there are multiple options out there, I have used Abstract and Versions by Sympli and they both provide the ability for designers to see all the changes to a file and access the most up-to-date “source of truth”. While version control is is an extremely valuable function to have when collaborating on mock ups, it is vital to the process of transparently and seamlessly scaling a design language.

Cover Image Photo by Erol Ahmed on Unsplash

valueOfDesign

The $$$ of Design

The battle cry for so many companies has been, “Design is so important—but we don’t have the time/money to do it.” And even for those who do find design resources, in nearly every instance they want a “quick mockup” so engineering can go build it. Validation, customer feedback, testing, and idea iteration are left to fall by the wayside. In this article, I am going to convince you it costs far more to not do design, then to include it.

Now, much can be said as to why software teams decide to omit design and design methodologies from their process (see our blog post on the Egocentric Intuition Fallacy); however, this article is not about the why. It’s about the actual cost. How much could/should it cost to include design—and how much to omit?

TLDR? - Click for the Infographic

By the Numbers

Let’s start by looking at direct costs to make one new “feature” for an existing solution, or an MVP to launch a new product/company. Everything presented herein assumes a very “lean,” albeit optimistic, execution.

$4.1k/week

Senior UI Engineer

$4.1k/week

$163k/year + benefits (~30%) = $212/year

$4.3k/week

Product Manager

$4.3k/week

$172k/yr + benefits (~30%) = $224k/year

$1.5k/week

Sales Representative

$1.5k/week

$60/yr + benefits (~30%) = $78k/year

NewCo’s Project

You are building a product, and you are super lean. So let’s look at the cost to build your UI. Since you are so lean, let’s assume you have only one UI engineer building your product. One Senior UI Engineer in S.F. (a very expensive market) costs $4,100/week. Engineers are notoriously expensive. 

As an aside, many companies look to off-shore engineering consulting firms as an alternative to reduce costs. In my own experience — both running my own firm and hiring others — with engineering consulting in US-compatible time-zones, such as Central and South America, you are generally going to pay around $3k/week per engineer. Most firms strongly suggest hiring more than one engineer, usually around three, so let’s say $9k/week. With an engineering firm, your higher costs come at the flexibility to scale up and down your engineering efforts as needed. Often, these firms, like the design firms, can bring on team members with specific skills to augment the skill sets of your current team. So given the increased costs, let’s assume you stick with your one FTE.

Your one engineer hits the ground running Day-0, and you tell them exactly what to build (no design work done). Being super optimistic, they successfully build your entire UI in three months. Wow! That is crazy fast—but good job! Your initial cost is $49.2k. 

You’re excited and you start showing off your product to customers; but, something goes off script. Your customers do not understand what your UI is showing them. They are confused. They misunderstand the data you are showing in your visualizations. They can’t figure out how to navigate your dashboards, let alone your product. You are spending many, many hours of your time, and your sales team’s time coaching your customer on how to use your product. And only then, after a week or two, your customers say, “Yeah, that isn’t what I want.” How much did this mistake just cost you?

Remember that cost is more than just money spent on a developer. It is also your time and your team’s time. So in this situation, your Product Manager has spent 10 hours a week for a month working with your customers at a cost of $4.3k, plus your sales rep adds another $1.5k for sitting in on those calls. You have thus spent $55k to build the wrong thing. But, it is actually worse than that. Your UI engineer has spent a month enhancing the very product that went in entirely the wrong direction. Moreover, it is likely something that you no longer need.  Consequently, you just added an additional $16.4k to your costs. Your running total is now $71.4k over 16 weeks, not including potential backend dev costs. This will be our benchmark cost for engineering without design.

Secondary Costs

If a cost loss isn’t a deterrent in itself, don’t forget to factor in your qualitative costs: lost time and damaged perception. Your company has spent four months going in the wrong direction, and you’ve lost four months to competitors. How much does this cost you? How much does it cost you to misunderstand expectations in front of your customers? You have misused your time, your company’s time, and you have wasted your customer’s time. To add to the hurt, you now appear less knowledgeable. Yes, you may have learned something about what to do, but it also demonstrates that you didn’t know what to build at the onset and you’ve expended your finite resources. This is a hard lesson in business, and especially for startups.

Quantifying these “losses” is not easy. But as a proxy, let’s factor in the added cost to fully rebuild your solution the right way (assuming you now understand both the question and the answer).  For simplification, we’ll put this cost at $49.2k for another three months of UI development. This may be overestimating the raw cost since some of the original work could  be salvable, but is underestimating the cost for lost customers or your competition gaining ground. Running total costs are now $120.6k—which took 7+ months to get the “right” idea out. And of course, if you again want to validate your next idea (and let’s assume you are correct) you adding another $5.8k. Bringing your grand total to $126.4k over 8+ months. You have now slipped your release train. This here is a major reason where and why companies have slippage. 

True Cost (Savings) of Design

Using the same scenario, lets now include design into the process. One User Experience Designer in S.F. averages $2,900/week. 

For contrast, the UI/UX/ENG consulting company I co-founded would put together a small/mid-sized engagement (with multiple team members) at around $14k/week. That is clearly more money, but the time/pay commitment is shorter and you get multiple, specialized skill sets. My consulting company is smaller, so larger firms (which I have worked with on the other side of the desk) may charge more than $20k/week. All-in-all, design costs money. In exchange for the higher cost, a design firm with multiple team members ensures more ideas are explored and iterated on, more designs outputted, and you will most likely have the best skills available for each stage of the design process. A design firm can also run user testing for a more objective analysis. 

$2.9k/week

UX Designer

$2.9k/week

$115k/year + benefits (~30%) = $150k/year

- vs -
$14-20k/week

Design Firm

$14-20k/week

small/mid-sized engagement

Let’s assume that it takes your FTE or design consulting firm 6-weeks to apply best-practices and design your solution. Had you hired an FTE designer, you would have spent $17.4k, and if you had hired a design consulting firm you would have spent $84k. Either way, throughout that 6-week window you would generally have a few iterative rounds, hi-fidelity mockups, and the opportunity for your sales team or PM to gather customer feedback before any code was written. 

If you then spend three months building what is designed ($49.2k) your cost would be $66.6k with an FTE or $133.2k with a consulting company.

Let’s put this all together

$66.6k + 18 Weeks [CHEAPEST]
cost for building the right thing once with an FTE

$71.4k + 16 Weeks [WORST OUTCOME]
cost for building (likely) the wrong thing and finding out it is bad

$126.4k + 32 Weeks [LONGEST]
cost for building (likely) the wrong thing and just building the (hopefully) right thing after

$133.2k + 18 Weeks [MOST DESIGN]
cost for building the right thing once with a design firm of multiple skills

Weeks Required

UI Eng only
UI Eng + Design FTE
UI Eng + Design Firm
UI Eng + ReBuild

Cost Required

UI Eng + Design FTE
UI Eng only
UI Eng + ReBuild
UI Eng + Design Firm

Now of course, if everything is perfect and you build the right thing first time out, fantastic. But Silicon Valley is all about “failing fast.” Which is faster? Failing two weeks into a project with mockups and reassessing, or seven months deep into building the wrong thing a singular time?

Additional Real-World Factors

Let’s now explore some additional real-world factors that only make the delta between design and no-design abundantly clear.

Longer Build Time?

Let’s hedge our bets a bit. Multiply this up to a six or nine month development cycle to create one new “feature” for an existing solution, or an MVP to launch a new product or company, and things look start looking even worse. Why? Design length does not map directly onto build length. Design costs are generally fixed. If it takes 6 weeks to design a flow—no matter how long it takes to build—it still only takes 6 weeks to design.  

If we consider it will take 6 months to build the UI, our engineering costs have now doubled to $98.4k, and the percentage that the design costs contribute decreases.

$115.8k + 30 Weeks
cost for building the right thing once with an FTE

$120.6k + 28 Weeks
cost for building (likely) the wrong thing and finding out it is bad

$182.4k + 30 Weeks
cost for building the right thing once with a design firm of multiple skills

$183.8k + 56 Weeks
cost for building (likely) the wrong thing and just building the (hopefully) right thing after

It is exceptionally clear that design adds a minimal cost and may be even cheaper than not doing design at all. And—perhaps surprisingly—is faster.

More Considerations

Now of course we can have UX researchers run user studies employing techniques to mitigate bias as to what customers need—not what they want—and testing ideas early. This has a force-multiplying effect to the above equations, as this type of work flow can happen in parallel, saving even more time for minimal costs.

But there is a whole other side to this equation that most people gloss over: the value of design. All of the above considerations are brutal cost comparisons.. But how do you measure the value-add of design? Luckily, there is a way. The Design Value Index or DVI measures just that.

Design Value Index (DVI), based on a portfolio of 16 publicly traded stocks from companies considered to be “design-centric” contingent on a set of criteria that reflects best practices in design management, shows a 211% return over the S&P 500.

Credit to Design Management Institute
Credit to Design Management Institute

These companies put design at the forefront of what they build. And through a collection of factors (adoption, user preferences, retention, etc.) you see a huge amount of success that can be attributed directly to design.

Conclusion

Pragmatically, early design work can save you money, allow you to fail faster, and over time, pay dividends to your success over your competition. Instead of saying, “Design is so important—but we don’t have the time/money to do it”; maybe say, “Design is so important—we don’t have the time/money to NOT do it.”

This article was written in collaboration with Kleeen Studio.

Cover Image by Alvaro Reyes on Unsplash
Additional Photo by Med Badr Chemmaoui on Unsplash
Additional Photo by Luca Bravo on Unsplash
Additional Photo by Marvin Meyer on Unsplash
Additional Photo by Maarten van den Heuvel on Unsplash
Additional Photo by Artem Beliaikin on Unsplash

remoteTeams

A Kleeen Culture | Building a Connected Team

I was recently talking to another CEO at a VC mixer event, who was lamenting the forthcoming challenges she will be facing with a startup that will soon span multiple countries; in particular, the company culture test. How do you create the feeling of a team, and a shared mission, when you don’t even share the same country let alone the same office? (Our entire team actually work from home, much like InVision, so there is no main office).

As I reflected on her pointed question, my thoughts coalesced into three key pillars we have used at Kleeen Software to build a strong and well-connected team: Owning the Outcome, Team Transparency, and Wielding Your Superpower. These are the three facets of a concerted effort by our leadership team, not just myself, which have disseminated to every individual at Kleeen.

Owning the Outcome

Let me begin by addressing the most obvious aspect of this first: equity for everyone. Every FTE at Kleeen Software has equity in the company, with those who joined earlier having a larger equity grant than those who join(ed) later (we are roughly tying equity levels to funding rounds). This both rewards the risk inherent in joining a startup (with more reward for those took the greater risk of joining earlier) and gives everyone in the company the very concrete feeling of it being THEIR company, and therefore their success if we have a great exit.

But the concept of Owning the Outcome goes beyond the explicitness and simplicity of equity. This mantra is inspired by one of my PhD committee members, Dr. Jiawei Han, who always tells his research lab that, “the success of the individual is the success of the team; and the success of the team is the success of the individual.” This is an eminently pragmatic creed that we live every day at Kleeen Software. Mario ( VP of Engineering), Amy (VP of Design) and I all make it very clear for each team member that identifying the problem, stress-testing all foreseeable use cases, and scaling the implementation are all of equal importance to individually implementing a solution. The successful outcome of every particular solution is guaranteed to require the input and effort of others on the team. And every better quality solution improves the quality of the company offering. In a very practical sense, we all own the outcome of this company.

A corollary to this mantra is the rejection of the notion of rewarding “major” contributors over “minor” ones. Who is a minor contributor? Someone whose role is small, or who is not succeeding in their role. Why would you allow there to be any minor contributors on your team? If someone is adding minimal value, taking a long time to accomplish their goals, and requiring extensive management that takes major contributors’ attention away from their own work, they don’t belong at your (startup with limited resources) company. Therefore, we consider that we do not hire, or keep on, “minor” contributors. Documentation, QA, DevOps, Analytics, Design – these roles all provide a major impact to our team, and are treated as such. Currently, as an early startup with a relatively small team, all Kleeen Software team members are creators. We are sure to require more maintenance, communication, and support roles as we grow. But we will not view the people who are maintaining the quality of our product, ensuring the satisfaction of our customers, and facilitating our new exploits as any less valuable.

We all share in the company’s success. Everyone took a pay cut to join early, to work on something big and exciting. Everyone will get a raise at the next company milestone (securing our next funding round). Everyone’s critical value to the company will continue to be explicitly called out. Everyone will have no doubt as to the importance of their role and that the collective effort is what propels the company forward, and in turn, their professional/reputation and financial success.

Team Transparency

We strive for full team transparency at Kleeen Software. What is the company doing? What are we telling our customers and investors? How is pay calculated? What is our funding roadmap? All these topics are discussed openly with the full team. We also try to be clear about why we pay what we pay. As I have told everyone, my goal is to pay you enough that you aren’t going to leave Kleeen Software due to a paycheck – but you will not stay for the money either, at least not in the short term. You will stay because the work is exciting, challenging, and a valuable experience. By explicitly setting role expectations and explaining the company’s value propositions we ensure that you stay at the company with your eyes open, and leave because you have truly found a better opportunity for yourself (which we will all be excited for you to have found, though disappointed to loose a skilled team member).

As a personal point of pride, we are open about promotion. As team members demonstrate their growing knowledge, execution, and ownership of their work, we promote them. We are clear about the largely quantitative requirements, responsibilities, and rewards of promotion, because we want our team members to get better (remember, as individuals get better, the quality of the company goes up.)  

Another aspect of team transparency is the explicit support of anyone asking any question of anyone else. Motivated by my previous time at Google (as an intern) and Niara (as an FTE), we hold all-hands meetings where everyone is invited and encouraged to speak up. I personally work on facilitating conversations, check-ins, and clarifications, especially across teams.

There is once again a pragmatic motivation for myself and the leadership team to actively work on team transparency, and that is to cut down on rumors, worry, and doubt. When team members know where the company is headed, as well as what they can do as individuals to grow their skill sets and careers, they are truly able to focus on their work, and therefore the success of the company. 

It’s true that this approach is completely predicated on trust in your team members, in your leadership team, and in your direct (and indirect) reports. Not everyone thrives, or is even able to work in an environment with this heavy requirement. However, the longer a particular culture (toxic or otherwise) persists, the harder it is to change or upset it. So: start as you mean to go on. Institute the company culture you want through explicit policy and smart early hires, even though it will mean some concrete effort at the outset, and your future team members will find that the path of least resistance is to contribute to, rather than push against the establishment.

Wielding Your Superpower

The result is that the employees of Kleeen Software truly do “own” different elements of the company decision making process. In practice, this means a two-step decision-making process. First is the team perspective: most decisions get reviewed by someone else, anyone can question a decision, and as differing viewpoints develop, a decision can and should get escalated. This seeks to minimize top-down decision making, and reinforce the Own the Outcome aspect of the approach. Team members are responsible for contributing their opinions and speaking up on entire solutions, not just their own “component” of the pipeline. Engineers give feedback on design directions, designers give feedback on engineering choices, and better solutions are discovered along the way

However, this does not work in practice without the second half: someone must put their foot down in the name of timely progress. This is the superpower perspective: the team member leading each component does get the final call on the decision (e.g., the lead database architect will make the final decision on the data storage stack.) This is necessarily hierarchical, without descending into micromanagement. As CEO, I will not force my engineers to use a particular technology against their better judgment. I am too far removed from using individual technologies to have their superpowers of delving into the intricacies of all the available options. But, as CEO, my own superpowers lie in the direction of determining and defining the problems we are solving. I may place constraints on the viability of technological choices for exogenous reasons. I may say, “we have to ship this feature in 1 week so you must make a decision and move on,” (though I have always promised to revisit when addressing our technical debt backlog). I may even ask if my team has heard of a particular technology- and my engineers should respond by wielding their superpower and educating me on why the suggestion is, or is not, something reasonable for us to consider using (frequently the latter, of course!) 

And all of this process returns to Team Transparency, as we try to make these decision points explicitly clear. And when someone “uses their super power,” we ask them to make that explicit – and justify it. Decision making should be able to be justified; time, money, features, etc. This minimizes perception that decision making is arbitrary, ensures that no one can abdicate their own role in the decision making process, which results in a higher quality of decisions and outcomes.

Final Thoughts

I will not claim with certainty that these approaches can scale to a large company, or be fully achievable at a company spanning multiple countries. Even though Kleeen Software is comprised primarily of remote teams, we are still all within at most a couple time zones of each other. The cultural alignments across these teams have undoubtedly contributed to our success. However, we also took the time at the onset of the company to discuss and develop the three pillars (Owning the Outcome, Team Transparency, Wielding Your Superpower). We stress the “ownership” of the company to each team member because we have seen how it makes them stronger contributors, who work harder to push Kleeen Software to realize its full potential. We put team morale and collaboration on the weekly staff meeting agenda to make sure that we are following these approaches to keep our staff motivated and dedicated to the product roadmap. In short, we, the Kleeen Software leadership team, have made these decisions and put forth this effort to consider and actively pursue every possible angle that will make our company more successful.

Cover Image by KAL VISUALS on Unsplash

Load More