With the rapid rise of technological innovation, it’s no surprise that entrepreneurs and tech experts around the world are rushing to create startups.

There are presently around 1.35 million tech-related startups internationally. While millions of people hope to establish a business ‘with legs’, not all startups are able to fare well — 90% are destined to fail within their first year, while 30% fail in their second year, and 50% by their third year.

The most common reasons startups find themselves on a downward spiral include an unsustainable business model, development issues, lack of investors, and cash flow problems. This might not be a secret to those who have business experience, but for aspiring entrepreneurs who need some guidance, here are a few mistakes to steer clear of:

A lack of goals

1. No clear business plan or SMART goals

Some ideas seem so promising that entrepreneurs rush into them with excitement — however, enthusiasm alone won’t necessarily translate to a thriving business. Rushing headlong into ventures with little planning might cause success to be either elusive or very short-lived.

Not only do good business plans include short- and long-term plans, they also provide businesses with guiding goals that are SMART: Specific, Measurable, Attainable, Realistic, and Time-bound. A thoroughly prepared business plan is essential to help startups navigate the rocky road to success.

2. Hasty efforts to raise money without a clear plan

Not having a concrete plan can be a turnoff for investors. Who would want to invest in something rushed and not thought through thoroughly? Creating a comprehensive business plan should also include being able to draw up projected finances and anticipate which areas of the business you’re planning to allocate funds to.

This will not only show investors that you’ve got a realistic grasp of how you’re going to run your business, but will also give you a better idea of how much you need to earn or acquire in order to successfully grow and stay in operation.

3. No Plan B, C, D, E, F…

It’s a simple fact of life: not everything will go the way that you’ve planned it. Instead of faltering and losing momentum the first time that things don’t go your way, you can instead take a second to breathe and refer to the next plan, or the one after that, or the one after that!

From economic downturns to daily operational mishaps, it’s better to be safe than sorry. Having not just one, but several backup plans can help you prepare for any emergency that your business might have to make it through. 

No awareness of competition or customers

4. No consideration for competition

Conceptualizing a good product or service often stems from real-life problems that entrepreneurs and innovators see in their daily lives. When you see something broken that you can’t fix, why not just create something entirely new that can address or even eliminate the problem?

While a lot of our best ideas can come from wanting to create solutions, part of creating a good, sustainable solution is being able to look at what’s already being done about it. What are your competitors doing that you need to do better?

What kind of edge can you offer that others can’t? You’ll need to learn how to measure up against others and develop your product or service after observing how things are already playing out in your industry and community.

5. No consideration of people’s changing needs

Customer needs are always changing — what someone might need now might not be what they need tomorrow, which is something that only gets truer as time goes on, as technology continues to evolve and influence how we live our daily lives.

Development of your products and services doesn’t stop after you complete your business plan, but rather is a continuous effort throughout the span of your operations, in order to provide the best possible quality of offerings. Businesses that fail to listen to what their consumers need and want put themselves at risk of becoming irrelevant to their target market.

Mishandling finances

6. Not properly keeping track of expenses

Mismanaged funds are a fast track to the road of failure. Whether intentional or unintentional, not keeping track of even “the small purchases” you make can lead your business not only towards closure but into peril for potential illegal activity. Depending on how many people are involved in the mishandling of funds, things can quickly turn fraudulent if expenses aren’t properly recorded and kept track of.

7. Poor budgeting

Budgeting issues are also a major problem: when entrepreneurs put too much into one area and leave next to nothing for another, it can be hard for a business to achieve dynamic development. Particularly in the early years, money doesn’t always come easy for startups, so each budgeting plan should be thoroughly planned and realistic. Being able to evaluate which areas need a certain amount of funding can help a business grow exponentially.

Bad marketing

8. Not investing in marketing

One of the biggest possible mistakes that an entrepreneur can make is underestimating the power of marketing. Having a good product or service can be worth very little when people don’t actually know about it! Depending on your target market, you and your marketing team should know how to best capture the attention and develop a relationship with the people you want your product or service to benefit.

Whether it’s curating social media profiles, creating ad campaigns online, or drawing out a traditional marketing series of print ads and commercials, you should know when and how to speak to your customers.

True enough, the world of business can feel intimidating — it’s certainly difficult to get it right on the first try. Entrepreneurs can feel tempted to throw in the towel when the going gets tough, but keeping yourself well-informed and in tune with the needs of your business and target market can help you stay on top of your game.

A little preparation can take you far!

Entering the world of business doesn’t have to feel intimidating at all. If you’re in need of inspiration, look no further: take a page from the book of startups set to become the biggest tech companies in New York City and see what you can do to up your game!

Is your business suffering from low productivity? Poor processes and a lack of suitable technology may be huge contributing factors that, in turn, cause your company to deal with low-performance indicators.

An antiquated legacy application may not provide the visibility you need. If you’re refusing to switch to a sustainable ERP system, then that is likely a part of your problem. Many companies have an attitude of “if it’s not broke, don’t fix it,” but that mentality will only hold your company back from success.

76% of managers agree that companies need to radically reengineer the experiences, bringing people and technology together in a more human-centric way. (Accenture)

The hallmark of any thriving business is to assess its current state and have a better plan to grow profits and optimally operate. The conservative approach of not revamping your existing business applications and moving to a newer ERP system may be holding your company back from its true growth potential. You need to reassess your legacy processes based on different attributes, such as:

1. Productivity 
2. Employee engagement
3. Overall cost savings
4. Operational efficiency
5. Process management
6. People management
7. Overall performance

We will touch upon these points in a later article. For this article, let’s look at different aspects that will help handle your ERP conversion in a better way.

What are some preparatory steps for an ERP implementation?

Creating a budget for the ERP implementation – It’s essential to know your budget before you spend. Knowing what features you need and the spending associated with them, helps you choose the right solution for your company.

Identification of the right ERP system – Budgeting is one thing. Identifying an ERP system that fulfills your company’s short-term and long-term goals is another. There is always a delicate balance between price and growth prospects on a technology platform. That is where the ROI calculation comes in handy. You can be more aware of the spending involved with the right tools, even if it means more short-term investments that yield long-term gains. To understand the right ERP system, make a matrix of competing systems with different attributes, such as increased productivity, higher visibility, streamlined operations, etc. 

Identification of a systems specialist with ERP transformation expertise – Shop for systems integrators, who have done this many times and know the pitfalls and methods of handling an ERP transformation. Try not to do the transformation yourself unless you have a team that has always done ERP transformations as a living. To use an analogy, you let a qualified builder build your house unless you have a lot of time and money to spend on making mistakes trying to do it yourself.

Choosing an internal champion to spearhead the transformation – If you want the ERP deployment to go well, you need an internal champion, who will be part of the transformation. The role of an internal champion is to understand the future state, make those necessary negotiations with the users on the solution, and be part of the process from start to finish. This individual then takes over the management of the application moving forward.

The right superuser group – The superuser group contributes toward requirements, design, and user acceptance testing. The right people know their respective functions well enough to participate in the required gathering and design. They also will be those who use the system as it is being built and once the final solution is ready for testing.

Some key elements involved in building an ERP system

The project team

The project team comprises sponsors, internal IT/ business relationship managers, superusers, and systems integrators. This team will be responsible for the transformation and involved in all phases of the project. The internal champions, who take on the role of change agents, influence the company users to move toward new solutions and must not get in the old ways of working. These champions not only understand the solutions but also bridge the gap between the present (as-is state) and the future (to-be state).

Methodology

Businesses that do not leverage a proper approach to an ERP conversion, hinder project completion. An ERP system conversion requires a structured deployment procedure to ensure the project stays on track. Without a structured methodology, you may spend more on an ERP implementation than expected. Without structure, if the process breaks down, cost tracking can become a challenge and the use cases that surface can turn into customizations. A reliable transformation procedure includes tracking risks related to people, processes, or regulations, and it allows a delicate balance between accommodating must-have vs. nice-to-have requirements.

Requirements

It sounds simple, but it is essential to freeze the project scope and capture the project requirements accurately when producing a solution. When the project team cannot capture high-level and detailed requirements, the project scope is not concrete. Every conference room pilot will surface delta requirements and use cases to analyze. Have deep-dive sessions to go over the different user scenarios in each functional area early on.

System Design and Build

When it comes to system design, it’s essential to have a clear starting point. I call it the starter pack by industry, which provides you with a starting point to run your first conference room pilot (CRP), where the project team can showcase the base system. During the CRP, you get the opportunity to dive into additional details of a scenario, where those oddball situations start surfacing. 

The implementation team often works toward the to-be state while the user groups fixate on the current system. Those little flexibilities that your current system may have could be eliminated in the new system due to industry best practices for managing data integrity in the system. As you run through multiple rounds of CRPs, you will understand how to progress to the future state and what processes to re-engineer as part of the design. 

Training

Once the project team has designed and built the system, sufficient training is required to ensure that users can confidently use the system and follow the process per the agreed design. The more the end-users train, the better they become at handling the system.

“…an average of 53 percent of employees have been trained in new digital and analytics capabilities since their transformations…”

You will notice that, initially, your end users may have difficulty using the system and feel frustrated that they need someone’s help in order to move forward. To help combat this, split your training plan to accommodate two levels of comfort in using new systems: a basic level 2 user group, which have difficulty using newer systems, and an advanced level 1 group, who is nimble with newer and more sophisticated applications. Encourage the level 1 group to show more optimism about using the new system, which may help the level 2 group adapt to the new ERP system more readily.

Final Thoughts 

As you get ready to move forward, here are some questions to ask yourself:

• Are there significant reasons for the persistent problems in operations?  
• What are the substantial issues that slow you down from operating at full speed? 
• Did you notice a downward curve in your company’s growth rate? 
• Have your competitors made rapid changes to move forward?

In the past couple of years, it’s no secret that our design tools have exponentially evolved. With many having great component management and prototyping, you may be wondering what big leap could possibly be next?

Let’s look at a typical dilemma:

Let’s say that you’re a designer for the design systems team where you are creating components, variants and spending many hours to document all the use cases and properties that may or may not be changed. You finally finish a large complex component and deliver it to the developers.

How do we know the code is the same UI? Do we really need to audit every single component? How do we bridge this gap between what is designed over what is developed without the overhead of constantly doing reviews?

All of this and you have to help teach people the different ways to use components, proper spacings and design for responsive web, and of course, the component will need to be updated for future use cases.

There are so many touchpoints, people involved. It almost feels like the farther we go into design systems, the more overhead there is for everyone! Now, it appears that a light at the end of the tunnel is glistening, and the next big thing is on its way.

A Hidden Gem In All The Chaos

I recently had the opportunity to revisit a tool I haven’t used in quite some time — a tool that is aiming to bridge this gap and minimize all that overhead: UXPin. A new feature called “Merge” has been launched to help break through the chasms of design and development, all while improving the agility and quality our teams expect. This new technology may cause some to rethink how entire design and engineering teams collaborate and work through use cases and building components.

Out With The Old Process

If we look at the current process most companies employ today, it can be pretty tedious with some obvious flaws. When we create a new component from scratch, we will design the base level of the component, add variants, write documentation, publish to the library and deliver it to the developers. Listing the process out is long-winded, but luckily it only needs to be done once (we hope):

Now, what happens when we need to update a component? A new use case has come in, or perhaps we decided to change our borders from rounded to razor-sharp? We now need to add the variants to the library, (possibly) update the documentation again, publish and deliver it to our developers. Phew! Let’s hope nothing broke along the way for our designers with all that reorganization of the component.

I almost forgot, we still need to publish the updates to the development library! Let’s hope that they can finish before the product teams go their own way to meet deadlines.

In With The New Process

So, you may be wondering, how does UXPin Merge’s technology help with this over-the-top process we all employ today? Well, take a look at the diagram below. You may notice the creation of a component and variants are not needed (in most cases). This new process reduces the amount of fiddling with auto-layout tools, because of our now synergized relationship with developers:

We only need to design the detail level required for documentation and implementation. Simple components such as a button or other atomic-level components may not need to be designed. Why waste your time doing double the work when the development can begin immediately with little overhead? In a way, we’ve come full circle; we are returning to the old ways when static components displayed only a few interactions in the documentation.

Notice that publishing to the library is now at the tail end of the process. That’s because, once the developer finishes with the component, it can now utilize Merge to make it available to designers in UXPin, and of course, all your product developers have it at the same time!

When updating components, it’s essentially the same as a new, except it may even be possible to skip the first step depending on the scenario. For example, let’s say that you want to add an option to add an icon to buttons; this is not something that needs designing, but instead, it needs to be communicated with your new best friends in development.

While this new relationship forms with your developers, the new way to officially launch components to designers may be only upon release by developers. Gone are the days of product designers asking if a component is available to their product developers. If it’s in the library, then it’s available in development and ready for designers to work on right away.

But enough about the process. Let’s take a gander at how UXPin Merge works.

Managing Libraries

The best part is that libraries can be imported directly from your code repository such as GitHub, Bitbucket, GitLab, (works only for React components), or even from Storybook. Once a library is created, you will have options to name the library.

When importing with Storybook, the process is quite straightforward. Simply grab the library URL, and UXPin will do the rest for you. With React components, using the CLI, you have control over the components that are published by specifying the UXPin library’s unique token.

Version Control And Testing

One of the biggest concerns amongst designers and design systems teams is version control. Most concerns can be resolved with this UXPin’s Merge feature. Let’s paint a quick picture:

Today, when we set out to upgrade a component, there is always the fear of breaking a component or layers that may get renamed and cleaned up. A total re-structure of the component could even occur which often leads to anxiety (on the designer’s side) on whether they should upgrade a component or stick with the old one.

When a component is developed, however, as long as the properties are remaining the same, it doesn’t matter how the component layout changes or the actual markup of the component. This, in turn, allows designers to upgrade their components to the latest versions with confidence.

Of course, in the hopefully rare instant that a component gets totally screwed up, just like with any coding project, it can easily be rolled back and republish the old version of the component.

Testing Updates

When testing new components or updates, today it’s not so easy. We obviously can’t edit the existing design library to test as this may accidentally be published, and block any other updates that are ready to go. It’s also very cumbersome to create a component in a new file, test it, and then try to handle the merging back to the current library without breaking layers.

Luckily for us, developers have figured out this issue long ago, and it fits right into UXPin’s Merge technology. When testing new components, it’s already best practice to fork or branch the code, and this new branch may be published into a test environment within UXPin. Your team may test it or you may grant access to a small group of beta testers in your company. Once the component has been tested and tried, the component can be quickly introduced and published to the primary design library without a stitch.

Designing With Code

So, how do our team members on the ground design, and what does this technology mean for them? Well, I’m glad you asked! From a product designer’s perspective — there isn’t much difference. When a designer uses a component from the development library utilizing Merge, they will be marked with an orange hexagon for each component. Anything new will keep behaving exactly the same as the developer’s library.

Components from the developers can have restrictions defined, but in a good way. A common issue often is using icons as links rather than wrapping the icon in a button component. If we were to use just an icon from the library, it’s locked and the user may not add interactions:

Alternatively, the icon button below allows for interactions. This allows us to really refine and control what components should be interacted with, and which should not; both from a standards point of view as well as accessibility.

With these types of restrictions, it puts an ease to the Design Systems team that components will have to be used in their proper ways, and if it’s over-ridden it will be obvious from the layer panel that something has been custom made.

Hand-Off

When you are ready to hand off to the developers, the finished prototype can display each component and their configuration to copy and paste to the developer’s tools and quickly build out the project. If your team doesn’t have a component library yet, UXPin comes with a default library or you can easily import some of the public libraries available directly in UXPin.

Accessibility

Speaking of accessibility, oftentimes it is overlooked or there isn’t enough time to create documentation on all the meta labels, aria tags, and so on. Designers don’t know what tags they need to input and developers don’t want to go through the hassle.

With UXPin, we can expose multiple properties even meta-level data that may never be visible to the interface, such as the ARIA labels. Designers may then enter all the information required (or a copywriter if you are lucky enough to have one on your team), and there will be little to no overhead for the product developers to implement.

Layouts, Templates And Grids

Just by reading the title, you know what’s coming, and I’m sure you’re bouncing in your chair right about now — I know I am. Grids, layouts and even page templates can be pulled into the library as a ‘component’ which allows users to bring components into the active area of a page and allow for all the spacing to be handled by the development library.

Common templates (e.g. login screens, completion pages, forms, profile pages, and so on) can all be utilized as a drag-and-drop component as well. Talk about speeding up the process and reducing human error in design!

In Closing

If you are ready to take the leap, it’s never too late to try out new software and new processes to improve your workflow. After all, we all want to be agile and as adoptive as possible. Let’s build stronger relationships across our teams, reduce our workload and work more efficiently. With tools like UXPin Merge, we get closer to a much more seamless work environment.

Why would a company promote a native app over their perfectly usable website?

We’d have to ask them, I suppose. But it’s hard not to see this push to native as a matter of priorities: that these companies consider native applications worthy of their limited time, resources, and money. They’re a worthy investment, to hear these banners tell it.

—Ethan Marcotte, “Locus.”

Ethan shows off that the web is absolutely covered in amazingly obtrusive “get the app” banners, often covering up perfectly usable websites.

What I always think of when I see banners like this is a comment I remember Tim Holman making one time that was something like, What would it feel like to work on the web team at a company like this? There are a bunch of people in the world that work on websites that only exist behind big stupid banners telling people not to use the thing they work on all day.

Sure would be nice to get to a point where companies didn’t really care which method you used, because it’s probably all built with one technology anyway and is fully capable of anything the device can do.

The post Those “Get The App” Banners appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.