No one really knows… until they have some real customers and real users.
Friends reach out for help when joining a new early stage startup, or looking for ideas on what it would take to build a UI for a startup they are thinking about starting. This is some of the info I give them, so I figured this might help others to. Is this “best practices”, or “industry standards”? No, but might lead you to the path for the right answer.
From a UI Developer’s perspective, let’s separate what parts the UI is normally responsible for. Asinthecity’s blog post diagram, shown below helps illustrates this.
As you see, the UI is the glue that connects all the work that everyone in the team has contributed. From the back end team, which usually gets very little credit but gets all the blame when something is not working, to the stakeholders that have pushed this from an idea to a product.
Startups go through many stages, that’s a reality. Below are some typical stages startups go through:
What does this mean for UI Development?
- START – An idea, from thought or paper, to something people can interact with using the core product
- SEE WHAT STICKS – Enhancements to help sales close the deal (will not go into details, but a lot of throw away development)
- CLOSE DEAL – The first couple of customers have say on additional product features (probably will not have anything to do with your core product)
- STABILIZE – Go back, clean up code, and implement some backlog features
- FUTURE PROOF – Start transitioning to long term plans for better maintenance and enhancements
Developers want to build a successful UI for their startup. They want potential customers to “want” to use the product, not “have” to use it. With that in mind, I am going to walk you through some scenarios and possible solutions to help make this happen.
Let’s put our UI Development hat on and work on a project from start to end.
If you have a UX Designer on your team, good for you. Skip this section since it’s their responsibility. If not, then be mindful in this stage. These are the fundamentals that could cause a domino effect delaying rollout and transitions to the different product stages. How? At times, startups get desperate, shift quickly and forget about the companies core product or offering.
Before you even start talking colors, layout, etc., take a step back and make sure you have at least these questions answered.
Will we be building a Public or Enterprise type of app (there are others, but sticking to these 2 examples for now).
So we join a startup that is revolutionizing the way products are sold and delivered. Additionally, they get a ton of information and claim they can analyze and help with reports. At the moment, all this will be displayed on a website.
- Core Product = Custom software that makes it easier to sell, everything from Amazon, eBay, and their own online stores.
- What problem does it solve = Greater Sales, easier to maintain, robust tracking and analytics
- Target Audience = Large Retail Companies (ENTERPRISE)
It is your first day on the job and they say “We are doing a pitch to Toys’ R Us at the end of the month, do you think you can have something done by then?” That’s less than 2 weeks away. Welcome to the Startup world!
Here is some additional information that was gathered:
- They have been presenting power point slides with mockups
- There is a lot of interest on the Core Product
- Some potential customers like the widgets but prefer they be organized differently
- Some widgets have not even been finalized because backend is still working on them
Not perfect, but you can work with this.
Based on the information gathered some of the requirements consists of:
- Get a fundamental UI to display data decently
- Many widgets (tables, charts, etc.) that will be used throughout the UI, just not sure where they will be in each view
- Need the ability to rollout new features quickly (widgets) and add them to the different views
- There is an existing API that can provide all the information needed
Thought only back end dealt with technology stacks? Guess again. Below are some front end frameworks and tools used to help with development.
Chances are you will end up using 3 or more of the above for your development.
Choose wisely. All these tools are great, but each have their pros and cons.
Some friendly advice.
- Choose tools that you either know or can pick up quickly
- Make sure you have sources to get help
- If you need to bring in outside help or hire new team members, there are nearby sources. (User groups are a great source)
For the purpose of this exercise we are going with:
- Angular, a HTML5/JS framework, for its modularity but specifically for us, directives (widgets), services (api calls) and user forums
- Bootstrap, a CSS framework, because of my experience and comfort level
- Sass to set variables like company colors and re-use them in the different files
- Grunt as the build tool, local web server and misc. tasks (deploy, build, concat)
- Bower for dependency management
In the next blog post, we will start to write some code and create some views leveraging the tools we have chosen to go with.